Posts

Everyone is talking about agents. This site is about the architecture underneath them. If you are new here, start with these six essays. They explore the infrastructure that connects agents to the real world: APIs, events, context, memory, tools, and other agents. They are not about finding the perfect model. It was about building systems that can make a capable model useful and safe to trust. They start from a simple observation: intelligence is only one part of an agentic system. An agent also needs timely information, well-designed capabilities, clear authority, a reliable record of what happened, and controls that continue to work when the path through a task is not known in advance. ...

I’m writing this a few days after the end of AGNTCon + MCPCon North America in San Jose. The Amsterdam edition ran a couple of weeks earlier, so this was the second stop of the first year. I spent two days in sessions, hallway conversations, and the Solo.io booth. I recorded a short recap video on the last day, and this post expands on it. One disclosure up front: I work at Solo.io. Several of the announcements below are ours. I have marked them in their own section so you can weigh them accordingly. ...

APIs made business capabilities reusable. A well-designed API has an owner, a contract, documentation, access controls, a lifecycle, and consumers who can depend on it. Events deserve the same treatment. Too often, event streams are treated as an internal plumbing detail: a collection of topics, schemas, credentials, and conventions understood only by the team that created them. That works until the stream becomes valuable to more than one application—or to an agent that needs timely context. ...

When an agent gets something wrong, teams often inspect its final answer and the context retrieved for the last model call. That can explain what the agent believed at the end. It rarely explains how it got there. For consequential systems, that distinction matters. An agent needs memory: relevant knowledge from past interactions, retrieved documents, and working state for the task at hand. But memory is not history. Memory answers, “What should I recall now?” History answers, “What happened, in what order, and why did the system reach this state?” ...

Multi-agent demos make it look as though agents are having a conversation: one delegate asks another for research, a specialist returns an answer, and an orchestrator turns it into action. That image is useful, but incomplete. Agents do not collaborate because they can exchange prose. They collaborate because one part of a system can make the right context available to another part at the right time. The architecture of that handoff determines whether a multi-agent workflow is reliable or merely entertaining. ...

Once an organization accepts that agents need governed, current context, the next question is unavoidable: what do we actually build? The answer is not an all-powerful agent platform that absorbs every system. It is a set of layers that make existing capabilities usable in a new way. The goal is to preserve domain ownership while giving agents a safe, observable path to information and action. Think of the context layer as connective tissue rather than a replacement for the systems that already hold the truth. ...

Integration platforms earned their place in the enterprise by solving a real problem: connect known systems through known flows. An order enters one application, a record is updated in another, and a workflow moves data from point A to point B according to rules someone designed. That model still matters. But it assumes the application knows the journey before it begins. Agents do not always have that luxury. An agent starts with an objective and has to assemble the information and capabilities required to pursue it. It may need a current customer record, an event that just arrived, a policy document, a specialist tool, or an approval from a person. Which of those it needs—and in what order—depends on the task. ...

There is a familiar pattern in enterprise AI projects. The team starts with a model. When the prototype disappoints, they change the prompt. Then they add retrieval. Then they try a larger model, a longer context window, or a new framework. Eventually someone asks the question that should have come first: why does the agent still fail when it leaves the demo? Often, the model is not the answer. The plumbing is. ...

There is a strange debate happening in the infrastructure world right now. As enterprises begin moving from AI experiments to production agentic systems, everyone wants to own the layer between agents, models, tools, data, and applications. Data platforms want to own it. Cloud providers want to own it. AI infrastructure vendors want to own it. And, increasingly, API infrastructure vendors are showing up with a surprisingly strong claim: We have already been here. ...

For decades, enterprise software has worked roughly the same way. You find the application. You find the right screen. You follow the workflow. You fill in the fields. You click the button. The software tells you what you can do, and you adapt yourself to it. For a long time, that was enough. But we are entering a very different era. If enterprise software was Pong, and modern applications evolved into something closer to Mario Bros, then generative AI is taking us into the Minecraft generation. ...