The second European AgentCon, held in Amsterdam in September 2026, was not really about agents. It was about the infrastructure of agency: the protocols, harnesses, authorization layers, observability systems, and governance models that must exist before an agent can be trusted with production work. The schedule made the shift visible before the first speaker took the stage. Sessions like "Distributed Mess: A Production Guide To Multi-Agent Failures," "MCP Borrowed LSP's Design. It Skipped LSP's Lesson," "ID-JAG: Solving OAuth Sprawl for Enterprise AI Agents," and "Six Months of Proof: Independently-Verifiable Records for Agent Actions Under the EU AI Act" are not titles from a hype cycle. They are the vocabulary of a field cleaning up its first generation of production deployments.
The most valuable signal from the two days was not any single product or paper. It was the consensus among builders that the model is the least interesting part of a production agent. The interesting parts are the harness that constrains it, the protocols that connect it, the identity layer that authorizes it, the observability that proves what it did, and the evaluation discipline that tells you whether it is getting better or worse. Businesses that internalize that ordering will build durable systems. The ones that do not will spend 2027 rewriting what they shipped in 2026.
The Schedule as a Maturity Signal
Before anyone spoke, the schedule made the argument. The tracks were not "AI Strategy" or "The Future of Work." They were Agentic Engineering, Building Reliable Agent Systems, Evals and Testing, Human-Agent Collaboration, Interoperability and Standards, and Multi-Agent and Distributed Systems. That is the vocabulary of a discipline that has moved past the demo and is now debugging its own assumptions.
The sponsor wall matched it: AWS, Google Cloud, Solo.io, Obot, Auth0, Cockroach Labs, Elastic, Neo4j, Oracle AI Database, WSO2. Infrastructure vendors show up where production spend is already concentrated and failure modes are expensive enough to justify databases, identity, search, and security. The event is run by the Agentic AI Foundation, and the seams they are trying to standardize are MCP, A2A, AGENTS.md, agentgateway, and goose. The standards have to catch a moving train because vendors are already shipping.
Protocol Politics: MCP, A2A, and the Standardization Gap
MCP has become the default tool boundary for agents, but the conference exposed where the specification is still thin. "What a Year of Breaking MCP Tells Builders" mapped protocol gaps and incompatible implementer behavior. "Stateless: The Future of MCP Transports" argued that stateful transports do not scale across distributed agents. "MCP Borrowed LSP's Design. It Skipped LSP's Lesson" made the sharper architectural point: Language Server Protocol succeeded because it standardized the language server interface, not because it standardized every editor's internals. MCP risks the same failure if implementers confuse the seam with the internals.
A2A is the complementary seam for agent-to-agent delegation. The "A2A Goes Stable" session clarified what changed and why: stable identity, task delegation, and message contracts between independent agents. The SAP session, "From API Catalogs To Agent Catalogs: Solving MCP Server Discovery With Open Resource Discovery," showed that discovery is becoming as important as the protocol itself. Without a discovery layer, every integration reverts to a bespoke handshake. I wrote about this resource-discovery shift in Google Just Made the Agentic Internet Official; AgentCon showed the same pressure happening in real time across the floor.
The strategic bet for a business is not to pick a winner. It is to adopt interfaces that let you swap models, harnesses, and vendors without rewriting workflows. Protocols matter because they are the insurance policy against vendor lock-in. The companies that treat MCP and A2A as seams, not products, will preserve optionality. The ones that bet on a single vendor's closed harness will discover, usually after a pricing change or a model deprecation, that their agents are not portable.
Identity, Authorization, and the Compliance Layer
The identity sessions were the most sobering part of the program. "ID-JAG: Solving OAuth Sprawl for Enterprise AI Agents" named a problem that every large client I work with is already feeling: agents now hold or request credentials for dozens of services, and the OAuth consent surface has become unmanageable. Delegated authorization is not a feature. It is a precondition for putting an agent anywhere near production data. "Delegated Authorization for AI Agents: How to Build an Agent with Fine-Grained Permissions" made the same point from the implementation side: an agent should receive only the permissions the task requires, for only as long as the task runs, with an auditable grant path.
The compliance conversation was just as concrete. "Six Months of Proof: Independently-Verifiable Records for Agent Actions Under the EU AI Act" argued that high-risk AI systems will need records that regulators can inspect without trusting the vendor's logs. "CHAP, an Open Protocol for Auditable Human-Agent Collaboration" proposed a standard for capturing who approved what, when, and under what context. These are not abstract governance concerns. They are the mechanisms that determine whether an agent can legally operate in healthcare, finance, or any regulated workflow under the EU AI Act.
Walking the expo floor, the Obot booth stood out because it was selling exactly this layer: open-source security and governance for AI agents across MCP, CLI, Skill, API, and Tools, covering Claude Code, Codex, Cursor, custom agents, and platform deployments. The product I expect to become mandatory is not the agent that writes the code. It is the system that proves the agent had permission to write it, that it ran in the right sandbox, and that every action is auditable.
From Vibes to Data: Observability and Evaluation
The evaluation track was the strongest signal that the field is growing up. "From Opaque To Observable: Tracing Multi-Agent OpenClaw Workflows With OpenTelemetry" treated agent execution as a distributed system problem and applied the same tracing standards that backend engineers have used for years. "From Vibes To Data: Evaluating Agents on Your Real Work" argued that the only evaluation that matters is the one run against your own tasks, not against a leaderboard. "Testing Agents and Their Tools: Offline Evaluation, Synthetic Tasks, and A/B Experiments" broke the work into three regimes: offline benchmarks before deployment, synthetic tasks for regression testing, and live A/B experiments for production validation.
The deeper point is that evaluation is not a monitoring add-on. It is how you define the goal. If you cannot write a test that tells you whether the agent succeeded, you do not have a specification. You have a wish. The sessions on observability made the same point from the other side: telemetry is not debugging output. It is the evidence trail that lets you prove the agent did what it was supposed to do, or catch the moment it stopped. The planning discipline I use for any automation project, which I laid out in How I Iterate and Plan for Successful Outcomes, is the same discipline these sessions were asking builders to apply to agents: define success in a testable form before any code is written.
Multi-Agent Systems and the Distributed Mess
Multi-agent architecture was the other dominant theme, and it was treated with unusual honesty. "Distributed Mess: A Production Guide To Multi-Agent Failures" was not a success story. It was a catalog of failure modes: shared state corruption, routing loops, conflicting ownership assumptions, and agents that step on each other's work because no one defined the coordination contract. "No Central Brain" and "Agents Talking To Agents: MCP, A2A, and the Reality of Multi-Agent Orchestration in Production" both pushed back on the assumption that a single orchestrator can scale. The more agents you have, the more you need explicit contracts, not a bigger conductor.
"I Was the Bottleneck, Not the Agent" named the human-side problem. The agent is fast; the human review loop is slow. If every agent action waits for a person to approve it, you have not automated the workflow. You have created a new inbox. The same pattern appears inside teams. The first agent changes the team structure whether you plan for it or not. I wrote about that downstream effect in How AI Agents Are Changing the Structure of Business Teams. AgentCon made clear that the technical architecture and the organizational architecture have to be designed together, because the multi-agent system will fail on whichever side is weaker.
Harness Engineering: Router, Callbacks, and the Durable Office
Most conversations about agents start with the model. Which one, how big, how smart. That is the wrong opening. The keynote slide that stuck with me broke an agent into four parts: the model, the harness, the protocols, and the tools. The model reasons. The harness decides what the model sees, what it can touch, and when it stops. The harness is where production agents live or die.
The harness includes loop and control flow, tool routing, context compaction, memory and state, sandbox and execution, permissions and credentials, observability and replay, errors and retries. Same weights, different harness, different agent. If you are evaluating an agent platform, stop asking which model it uses. Start asking which harness it ships with. That is what determines whether it can be trusted around real data and real money.
One architecture session laid out a router pattern I am adopting as a baseline. A routing layer, rules plus embeddings plus a lightweight confidence model, sits in front of every query and sends it down one of three lanes: retrieval and search for grounded answers, LLM reasoning for generated responses, or tools and API actions for executed outcomes. Most agent builds skip this discipline because it is easier to route everything through one model and hope. That hope is what produces slow, expensive, and wrong answers. The cost argument is the same one I made in Tokens. The Double-Edged Sword.: when every call is billed by the token, treating every input as a reasoning problem is a tax you chose to pay.
The same session paired the router with callbacks as the immune system. Four specific guardrails, not abstractions: a tool cache with a 600-second TTL on repeat searches, a PII sanitizer that redacts before the model sees the data, date injection so the model actually knows what today is, and lifecycle telemetry logged as JSON to stdout with zero added infrastructure. None are novel. Seeing them named as a single required layer, not optional hardening, is the part worth taking home.
A session on dynamic skill discovery changed how I think about agent memory. The idea is that an agent should not ship with a fixed tool list. Every turn it reassembles context from a semantic catalog, a skillbox manifest, workflow recipes, and a context card holding working memory. The assemble_context function runs every turn. A newly learned skill shows up automatically on the next turn without a redeploy. Most demos treat memory as remembering what the user said ten minutes ago. Dynamic skill discovery treats memory as a living index of capabilities the agent consults before it decides what it can do. That is much closer to how I want client agent systems to work: a persistent memory layer that stores facts and surfaces the right capability for the current task. The closest thing I have running is the hop.db enrichment pipeline I described in Running Local LLMs on iGPU and the Real Cost vs Cloud AI, where 51,000 rows of factual memory get semantic summaries so retrieval can surface the right capability without a cloud bill.
Steve Yegge's talk "Seats and Sunsets" added a second frame. Every builder hits the same wall defined by three costs: Fuel, Fences, and Seats. Fuel is inference and infrastructure. Fences are safety, permissions, and guardrails. Seats are the context windows and sessions you pay for. The model is the occupant. The seat is the office. A durable office carries purpose and scope, authority and limits, history and evidence, obligations and lessons across sessions. When a new model occupant sits down, it inherits the office. That is exactly the context-persistence problem most businesses ignore until their agent forgets everything every morning.
When Not to Build and the Staged Adoption Model
The most useful session was not about how to build agents. It was Rishabh Misra and Jigyasa Grover on when not to. The subtitle said it plainly: lessons from systems that did not want autonomy. In a room full of talks about what agentic architecture makes possible, this was the honest counterweight. Adding autonomy made some systems worse, not better, and there are signs that show up before you find that out the expensive way.
That is the conversation I have with clients before any build starts. Most systems do not need an agent. They need the process fixed first. The point is not that agents are overhyped. It is that autonomy is an architectural choice, not a default upgrade. Hearing engineers who build this for a living say the same thing from the stage of an agent conference is the kind of validation that does not show up in a vendor pitch deck. It also gives me a clearer way to push back when a client asks for an agent that is really just a broken workflow wearing AI makeup.
The staged adoption model that emerged across several sessions is the framework I am bringing back. Stage one is advisory: the agent recommends, the human decides, every recommendation is logged. Stage two is supervised action: the agent executes within narrow guardrails, with human approval on exceptions. Stage three is autonomous execution: the agent runs within defined boundaries, with audit trails and rollback paths. The mistake most enterprises make is trying to start at stage three because the demo looked good. The ones that get it right spend longer in stage one than their executives want to, because that is where the goal, the directives, and the observability get defined.
Implications for Client Work
The second European AgentCon made one thing clear: 2026 is the year the agent conversation stopped being about demos and started being about discipline. The businesses I work with are not going to build a router pattern or a callback layer themselves, and they should not have to. What this weekend confirmed is that the gap between a demo agent and a production one is not the model. It is the harness around the model, the durable office that preserves context, the identity layer that authorizes action, the observability that proves what happened, and the discipline to define goals before writing code.
For my client work, this means a tighter intake. Before any agent gets scoped, we answer four questions. What is the measurable impact? What are the hard boundaries? Who owns the approval points? How do we observe whether it worked? If we cannot answer those, we do not build. We fix the process first. That is the filter I am using now, and it is the filter I should have been using more aggressively all along.
The work does not stop at deployment. Models drift, tools change, vendors update APIs on their own timeline, and the business context moves. The systems that last are the ones with a governance loop built in, not bolted on later. That is the argument for a managed AI retainer: someone owns the harness after the launch, not just the launch itself. I made the same point about process before automation in AI Won't Fix a Broken Process. It Just Runs It Faster. AgentCon simply confirmed that the same rule applies, at higher stakes, to the agent layer.
30 Minutes. Honest Assessment. No Pitch.
You describe what is eating your time. I tell you honestly whether I can fix it, what it takes, and what it costs.