## Sources

1. [Not an Ontology](https://jessicatalisman.substack.com/p/not-an-ontology)
2. [The Weekly SEO Brief Every Online Writer Should Build](https://aimaker.substack.com/p/google-search-console-substack)
3. [Why the Frontier Ecosystem must be Open — Matei Zaharia and Reynold Xin, Databricks](https://www.latent.space/p/databricks)
4. [Red-Teaming after Mythos — Zico Kolter & Matt Fredrikson, Gray Swan](https://www.latent.space/p/gray-swan)

---

The sources provided offer diverse perspectives on the evolving landscape of artificial intelligence in 2026, ranging from practical workflows for individual writers to deep architectural critiques of enterprise data platforms and the security risks inherent in autonomous agents.

### **Google Search Console for Substack: Claude Cowork Briefs — Wyndo and Ilia Karelin**

This source describes a practical system for online writers to leverage **Google Search Console (GSC)** data through **Claude Cowork** to eliminate guesswork in content strategy [1, 2].

*   **Main Arguments:**
    *   Despite the rise of AI-driven search, **Google remains a critical source of discovery**, accounting for approximately 60% of traffic and 30% of subscription revenue for some successful newsletters [3, 4].
    *   Raw data dashboards show "what" happened (numbers and arrows) but fail to explain the **"so what"** (the interpretation required for decision-making) [5, 6].
    *   Writers should stop guessing and instead focus on keywords and topics that are already successfully leading strangers to their work [7, 8].

*   **Key Takeaways:**
    *   **The Analyst Stack:** A three-part system consisting of a data connection (GSC CSV exports), a standing brief (defining the AI's role and logic), and a scheduled task (running every Monday) [9, 10].
    *   **The Weekly Brief:** Claude generates a report with three sections: what changed, why it matters, and a **content recommendation** for what to write next based on traction and archive gaps [10].
    *   **Actionable Data:** GSC provides the only place to see the gap between what a writer thinks people search for and what they actually type into Google [8].

*   **Important Details:**
    *   The setup uses the **Claude Data plugin**, utilizing slash commands like `/data-exploration` to profile datasets and `/data-validation` to ensure analytical accuracy [11].
    *   Users must manually export CSVs (Queries and Pages) from GSC and drop them into a local folder for Claude Cowork to access, as there is no live connection [12, 13].
    *   The system can be adapted for any data source, including sales reports or email analytics [14].

***

### **Not an Ontology — Jessica Talisman, MLS**

This source provides a critical evaluation of five major data platforms claiming to offer "ontologies" in 2026, arguing that they lack the fundamental **reasoning and inference** capabilities that define a true ontology [15, 16].

*   **Main Arguments:**
    *   An ontology is not merely a file format but a **conceptualization explicit in logic** that allows a machine to derive new facts through inference [15, 17].
    *   Current industry leaders (Databricks, Palantir, Microsoft, and Snowflake) are using the word "ontology" as a marketing term for systems that primarily perform **ranking, traversal, or materialized lookups** [16, 18].
    *   True data sovereignty requires open standards (RDF, OWL, SPARQL) that allow an enterprise to export the **meaning** of their data with semantics intact, rather than being locked into a vendor's proprietary runtime [19, 20].

*   **Key Takeaways:**
    *   **The Three Trends:** Enterprises are currently demanding **data sovereignty**, **knowledge infrastructure** (memory for AI agents), and **computable meaning** [15, 17, 21].
    *   **Portability Crisis:** Proprietary models like Palantir Foundry’s object model or Databricks Genie’s self-assembled graph solidify **vendor lock-in** because the meaning cannot be exported in a form that other tools can reason over [20].
    *   **OSI and OKF:** Snowflake’s **Open Semantic Interchange (OSI)** and Google’s **Open Knowledge Format (OKF)** are noted for being more open and honest; OSI standardizes definitions while accurately refraining (initially) from calling itself an ontology [22-25].

*   **Important Details:**
    *   **Inference** is the missing capability in all five reviewed products; it is what turns recorded knowledge into active infrastructure [25, 26].
    *   Microsoft Fabric IQ claims to offer inference, but documentation reveals it is actually **graph traversal and event-condition-action rules** [27].
    *   The **EU AI Act** and other regulations are driving the need for systems that can account for how they reached an output, making symbolic, explainable structures more valuable [17, 28].

***

### **Red-Teaming after Mythos — Zico Kolter & Matt Fredrikson, Gray Swan**

This podcast transcript features experts discussing the unique security challenges posed by AI agents and the necessity of specialized **adversarial red teaming** [29-31].

*   **Main Arguments:**
    *   **AI security is fundamentally different from traditional cybersecurity**; models have inherent vulnerabilities and can be tricked in ways humans can, requiring a new security mindset [29, 32].
    *   As AI scales, it does **not** automatically become more robust or safe; safety must be explicitly trained into the model [33, 34].
    *   The shift from chatbots to **autonomous agents** that use tools and read untrusted web content creates a "lethal trifecta" of risks [35-37].

*   **Key Takeaways:**
    *   **The Lethal Trifecta:** A critical risk exists when an agent can **ingest untrusted data**, access **private internal information**, and has the ability to **exfiltrate** that data [36, 38].
    *   **Automated Red Teaming:** Gray Swan's **"Shade"** model is designed to break other AI systems and can now outperform human red teamers in finding vulnerabilities [39].
    *   **Guardrail Solutions:** **"Cygnal"** is a specialized filter model that sits between the user and the LLM to look for policy violations in tool calls and incoming data [40, 41].

*   **Important Details:**
    *   **Indirect Prompt Injection (IPI)** is a primary concern for coding agents that read third-party code or websites [30, 42].
    *   In a "Human Browser Agent Robustness Challenge," humans actually ranked fourth in robustness behind top AI models, though models fall for "alien" traps humans never would [43].
    *   A **"Gray Swan"** event is a major AI incident that everyone can see coming, such as a massive data breach via prompt injection, which the experts believe is inevitable [44].

***

### **Why the Frontier Ecosystem must be Open — Matei Zaharia and Reynold Xin, Databricks**

The leaders of Databricks discuss their vision for an **"Agent Cloud"** and new architectural developments designed to support enterprise-grade AI agents [45-47].

*   **Main Arguments:**
    *   Databricks aims to become the **operating system for enterprise agents**, providing the necessary context, permissions, and memory [47, 48].
    *   The durable advantage in AI will not be general model performance (which is becoming commoditized) but **company-specific context** and proprietary data [48].
    *   Traditional software will likely be rewritten in a new paradigm: "get the data there, slap some agent on top" [49, 50].

*   **Key Takeaways:**
    *   **Omnigent:** An open-source **meta-harness** that sits above various agent frameworks (like Claude Code or Codex) to provide a common API, session persistence, and security controls [46, 47, 51].
    *   **LTAP (Lake Transactional/Analytical Processing):** A strategy to unify storage by writing transactional data directly into **column-oriented Parquet formats** in the data lake, making it immediately available for AI reasoning without brittle pipelines [52-54].
    *   **Contextual Security:** Agents need stateful policies; for example, an agent might be allowed to read docs OR post to a website, but not both in the same session to prevent data leaks [55].

*   **Important Details:**
    *   Databricks operates at massive scale, launching **50–60 million virtual machines a day** and processing exabytes of data [56, 57].
    *   The **"Lakebase"** architecture allows Postgres databases to write directly to object stores in Parquet, utilizing idle CPUs for the transcoding [49, 58, 59].
    *   Zaharia argues that **vector databases** should never have been a separate category and should instead be a feature of the general query engine [60].