Mechanistic interpretability is the science of “reading an AI’s mind”.

Large language models are “grown, not built”. Researchers run training data through a neural network. Eventually this creates a working AI; nobody really knows how.

But a neural network is just a set of simulated neurons on a computer. The person with the computer can see the neurons, the connections between them, and which ones activate when the AI answers questions. So it seems like it should be possible to “reverse engineer” the AI.  … Unfortunately this is very hard.  — Read More

There’s so much talk about new ways of working with agent engineering supported workflows. New models are independently creating new metrics and transformations, finding gaps in the business data, reviewing the SQL they write, and verifying everything works with your data platform.

All of it is autonomous, so one might say, what then is left for us humans to do in the data work context? Many are defaulting to adding or curating context, ergo the rise of a context layer. I see even more talks about added Ontologies. Maybe you ask yourself, what is that even? Do we need all of it?

This article is a primer about the context layer, the difference between a classical semantic layer contained in every BI tool, and an external semantic layer. — Read More

We’ve built an AI agent that acts as a secondary expert for a given domain, making deep specialist knowledge readily available and preserved for anyone in an organization to access, share, and build upon.

This is not a typical domain-specific agent. Its novelty comes from integrating two layers:

— A structured, auditable knowledge architecture separates what the agent knows from how it reasons.
— A self-improvement loop then compiles expert feedback into verified, regression-tested updates without model retraining. 

Together, these two layers turn one-off expert corrections into permanent, compounding institutional memory, and the pattern is designed to generalize to other domains governed by retrievable text rather than model weights. — Read More

Today, we’re sharing Solaris: the first model in a new family of AI systems we call Interface World Models. Solaris starts with a question: what happens when an operating system generates apps and websites as you use them?

Every operating system, from early terminals to Linux and macOS, has dictated what’s rendered on screen and what happens when a person or program acts on it. Applications get built on top, and stay fixed until someone pushes an update. Solaris instead renders that layer directly. It’s a real-time interactive model that generates the interface itself, frame by frame. Every frame is synthesized as you interact, allowing the interface to respond continuously to your actions. — Read More

LLMs have evolved from language generators to autonomous agents capable of complex, long-horizon tasks. This evolution has produced paradigms including Prompt Engineering to elicit model capabilities, Context Engineering to manage information access, Harness Engineering to organize external tools and resources, and Loop Engineering to support continual reflection and self-improvement. Yet as tasks grow more complex, individual intelligence faces a fundamental limit: many tasks require heterogeneous expertise, interdependent subtasks, parallel execution, independent verification, and persistent state, exceeding any single agent’s organizational capacity. Augmenting one agent’s capabilities or context cannot resolve this architectural mismatch; intelligence must instead be distributed across specialized agents and organized at the system level. We call this System Intelligence: an agent system’s ability to organize and coordinate multiple intelligent components into a coherent, adaptive whole pursuing a shared objective. Achieving it requires more than adding agents; it demands explicit structures to organize work, coordinate heterogeneous agents, and maintain evolving execution states. We introduce Graph Engineering, an emerging paradigm for next-generation agent systems. Unlike prior paradigms that mainly optimize individual interactions or agent-level behavior, Graph Engineering constructs explicit, dynamic, evolving graph structures representing tasks, agents, and system states. These abstractions provide a unified foundation for organizing complex objectives, orchestrating heterogeneous agents, modeling system dynamics, and enabling scalable agent evolution. We systematically review the principles, methodologies, and applications of Graph Engineering for LLM agents. Related papers, open-source data, and projects are collected at this https URL. — Read More

Sometime around Christmas 2025, AI engineers noticed a change in agents. They started to work! It’s hard to pin down exactly why. Maybe we finally had holiday downtime to try the newest agents with the newest models. Maybe the models had crossed some capability threshold. Maybe the wrappers around the models had matured.

What I’ll argue in this post is that it was the confluence of the last two. The model and the harness improving together and then their curves of improvement crossing at the right moment. And that dynamic helps to explain what comes next: models keep absorbing the harness into their weights, engineers keep deleting what got absorbed, and what remains is a harness for human attention rather than for the model. — Read More

I have had some version of the same conversation with a CIO almost every day this year. It usually starts the same way. Their team has read about context layers, or seen the term in a Gartner note. They know it matters. They know it sits somewhere underneath the agents they are trying to put into production.

… So here’s the question I actually want to answer, when you strip away the branding, what is a context layer made of, and how do you tell a real one from a catalog with a new coat of paint? — Read More

Large language model (LLM) agents are evolving from conversational assistants into autonomous systems that execute long-horizon tasks through reasoning, tool use, code generation, and workspace manipulation. As agents increasingly operate over persistent environments and multi-step workflows, they face challenges analogous to those addressed by transactional database systems: reliable execution, consistent outcomes, safe concurrency, and durable state management. We introduce the concept of an agentic transaction and propose an ACID-compliant agent system framework that reinterprets the classical ACID properties for agent execution through four semantic guarantees: Semantic Atomicity, Semantic Consistency, Semantic Isolation, and Semantic Durability. Together, these properties provide a principled foundation for building reliable agent systems despite model uncertainty and dynamic execution environments. To instantiate this framework, we develop an ACID-compliant data agent that realizes these guarantees through transactional exploration-execution-validation cycles, transactional skill hubs, confidence divergence-based validation, semantic dependency-aware isolation, and transaction-aware semantic state management. Experimental results on widely used benchmarks show that our system achieves a 10.6% improvement over state-of-the-art agents, including Claude Code. This work opens a broader research agenda on extending transactional principles and system architectures toward building trustworthy, scalable, and self-evolving AI agent systems. — Read More

#architecture

The Model Context Protocol (MCP), introduced by Anthropic in November 2024, defines a standardized interface for connecting large language models (LLMs) to external tools, data sources, and services. Within months of release, hundreds of community-built MCP servers appeared on GitHub, but no software-maintenance literature has yet described how the ecosystem is being structured in production. This industry experience paper catalogues five recurring MCP server architectural patterns observed across an enumerated corpus of fifteen independently developed servers (five production servers from the ANSYR voice AI platform plus ten public servers from the official MCP registry): Resource Gateway, Tool Orchestrator, Stateful Session Server, Proxy Aggregator, and Domain-Specific Adapter. Each pattern is described in the structured form established by Gamma et al. [1]: context, problem, solution, and consequences. We also document four anti-patterns and a set of cross-cutting concerns around authentication, versioning, and observability. Quantitative evaluation contributes three measurements: inter-rater reliability of the taxonomy across two independent LLM raters on 54 held-out servers (Cohen’s $\kappa =0.76$), which also localizes three pattern-boundary ambiguities; transport overhead measured end-to-end on loopback (stdio: 0.01 ms $p_{50}$; streamable-http: 0.39 ms $p_{50}$) and modeled for cross-host paths from same-region network baselines ($\approx$30 ms $p_{50}$ baseline plus protocol overhead); and a tool-count study showing accuracy drops below 90% between 10 and 15 tools per context for Claude Haiku 4.5 and between 20 and 30 tools for Sonnet 4. Code, corpus, and prompts are released at https://github.com/rodriguescarson/mcp-patterns-icsme2026. — Read More

#architecture

You ask your coding agent to find every caller of a function before you touch it. Ask again tomorrow, same repo, same question. It starts from zero and does the whole crawl again.

[Karpathy’s] argument: stop treating LLMs as search engines that re-read the same documents on every question. Compile the knowledge into a structure once. Query the structure instead. His point was never about wikis. It was about not making an LLM redo work it already did. Read More