Agents fail at the seams.

I spent June 14–15 at MCP Dev Summit Mumbai — 16 sessions across two days, run under the Linux Foundation's Agentic AI Foundation (AAIF). These are my field notes: what I actually heard in the room, plus where I landed on it as someone who builds agentic platforms for a living. I've kept the vendor numbers loose on purpose — several are from speakers' own experiments, and I flag those as directional.

Most of what gets written about agents is about the model — which one, how big, how well it reasons. Two days of practitioners who actually run these systems in production said something almost the opposite: the model is rarely the problem. The same models, wired into a different topology, fail or hold. What breaks is the plumbing between the pieces — and it breaks in ways that are nameable, repeatable, and fixable with a contract rather than a smarter model.

01The one mental model to keep

The cleanest framing came from the context-engine session, and it recurred all weekend. Treat the agent like an operating system:

• Context window = RAM — fast, tiny, expensive. The system prompt, tool schemas, memory, message buffer.
• Context graph = disk — large, durable, cheap. Entities, relationships, facts, and decision traces that survive across sessions.
• MCP = the system call between them — it pages context in, and writes results back out.
• The gateway = the kernel's security layer — auth, audit, isolation, rate limits, versioning.

Once you see it that way, the two halves of the problem fall out cleanly. Security is the floor — centralize it so individual MCP servers stay dumb. Durable context is the ceiling — give agents real memory, not just retrieval. And there's a third thread that Day 1 kept circling: even with both, you still have to design how the model consumes tool output. A tool response is a prompt surface. Structure it or the model will hallucinate over it.

02The through-line: failures at the seams

Here's the line that held the whole summit together, said almost word-for-word in the "100 Agents in 100 Days" talk and echoed everywhere else:

“Most agent failures don't happen inside protocols. They happen between protocols.”

Between agents. Between tools. Between MCP and A2A. And in every case the root cause was the same shape: a contract nobody wrote down. When does the loop stop? Who has authority to act? How does an error propagate upstream? How fresh is this data, and is it complete? Naming the failure mode turned out to be half the fix — because once it's named, the fix is usually thirty lines of JSON in a server card, not a new framework.

The Coordination Tax talk put the sharpest edge on it: past roughly four agents, every agent you add makes the system worse — not flat, worse. They measured a negative coefficient and named it. It isn't the model or the prompts. It's the orchestration topology having no rules. As one slide put it: "a contract nobody wrote down is just a hope."

03The six spines

The 16 sessions clustered into six parallel concerns. This is the map I'll be using to organize my own work coming out of the event.

04The pattern, made concrete: failures → contracts

Strip out the vendor logos and the same table assembles itself across the talks. Each failure mode maps to a missing contract and a fix you can ship today.

What I like about this table is that none of the fixes need a frontier model. They're discipline: a stop condition, a quality field, a voting rule, a token you down-scope at each hop. The summit's quietly radical claim is that most of "agent reliability" is contract hygiene, not capability.

05Security is the floor — and authorization is the hard part

The auth thread was the one I came in most opinionated about, and it held up. Today every MCP server re-implements the same boring, dangerous things: token refresh, secret storage, audit logging, content filtering, access control. The gateway pattern moves all of that into one centralized control plane, so servers go back to exposing just tools, resources, and prompts. Same lesson the API-gateway era taught us — except we briefly forgot it and shipped one MCP server per microservice, which is hundreds of front doors all over again.

But the deeper point landed in the confused-deputy session. OAuth is becoming the default, and authentication is largely solved. Authorization across agent boundaries is not. An orchestrator delegates to a sub-agent using the user's authority; an untrusted input — a prompt injection, a poisoned tool manifest — steers that sub-agent to act beyond what the user ever intended. It has valid credentials the whole time. The reframe that stuck with me: stop asking "can this action happen?" and start asking "should this action happen?"

The reference pattern is three layers: preserve intent (bind the user's original intent at the source so a hop can't exceed it), reduce authority (down-scope the token per hop with STS session policies), and validate the action (a policy check before execution via OPA/Cedar). Live demo, same pipeline run twice: default delegation leaked data via prompt injection; with all three controls, the attack was blocked, logged, and auditable. If you're building multi-agent MCP, that's the floor.

06Context is the ceiling — and the event clock is empty

The context-engine session was the one I keep replaying. The first-principles framing: an LLM is not a pure function — output = f(context), behavior steered by the window, not the weights. So the window is a budget, not a bucket: target under ~40% utilization on long-running work, and move through research → plan → implement, compacting at each hand-off.

RAG gives you text chunks similar to a query. Agents need to reason over identity (who is this, across tools?), relationships (who owns what?), temporal state (what was true, and when?), and the why behind decisions. The distinction that reframed it for me:

“Agents don't just need the rulebook. They need the case law.”

Rules say what should happen in general. Decision traces say what happened in this case — "used X under policy v3.2, with a VP exception, based on precedent Z." That's the operational-context foundation most teams skip, and it's where MCP closes the loop: most MCP servers are read-only vector wrappers, but a bidirectional, graph-backed server lets agents write their own state back — decision traces compound into long-term memory for the whole ecosystem. The "state clock" (what's true right now) is a trillion-dollar solved problem. The event clock — what happened, in what order, with what reasoning — barely exists. That's the opportunity.

07The tool surface is the product

Day 2's loudest convergence: agents don't fail because your server is buggy — they fail because the tool descriptions are too vague for the model to pick the right tool. The consumer of your tool is a model, not a developer. It can't read your docs, doesn't hold your service map, and gets measurably worse the more tools you throw at it. So the design move is to expose tasks, not endpoints — one search_knowledge(query, scope?) that fans out, applies ACLs, and dedupes, instead of five tools that mirror your plumbing.

Figures are summit-sourced from the TDQS and testing talks; treat the magnitudes as directional, the direction as solid.

Two ideas I'm taking home from this thread. First, "descriptions are not documentation, they are contracts" — review them like you review code, and test them: trigger a failure and assert the error is explicit and actionable, not buried in an unhelpful body. Second, TDQS — a Tool Definition Quality Score that grades the definition a client actually receives from tools/list across six dimensions, with hard gates (a tautological description that just echoes the tool name caps your score). It's cheap, reproducible, and the obvious thing to wire into CI. The closing line of that session is the right altitude: "agents are not clients of your services. They are customers of your product."

08The seam: where MCP ends and A2A begins

The industry likes to frame A2A versus MCP as a fight. They specify different things. A2A owns task lifecycle, agent cards, message parts, streaming. MCP owns tool invocation, schemas, resources, prompts. The seam is everything that falls between the two specs — and right now it's owned by no one. Four failure modes, four fixes:

• Trace severance — the trace breaks at the protocol boundary. Fix: propagate trace context through MCP _meta.
• Schema drift — types diverge across the boundary. Fix: shared schema with versioning at the bridge.
• Auth leakage — the delegation chain breaks. Fix: explicit delegation (RFC 8693), least privilege per hop. (Same pattern as the confused-deputy talk.)
• Orphan tasks — lifecycle ownership is unclear across A2A↔MCP. Fix: a task-lifecycle bridge plus an agent registry.

The proposed answer is a Protocol Bridge that owns Context, Identity, Validation, and Lifecycle between the orchestrator and the MCP server. Nobody has shipped the general version. That's a genuine greenfield, and it's near the top of my list to spike.

09The gaps worth building

If the contracts are the lesson, the gaps are the opportunity. The ones I think are most real:

10What I'm taking forward

My honest read, as someone who builds this stuff rather than sells it:

Auth-first is the right instinct, and the precise problem is authorization, not authentication. Abstract auth and guardrails into the gateway/SDK layer so individual agents stay simple. Pair it with audit, isolation, and revocation, and that's the strongest credibility lever for anything enterprise-facing.

Start the context layer now, and stop theorizing. Retrieval isn't enough — agents need durable, temporal, write-back memory, including the why behind decisions. The way to learn it is to ship a real agent against real data and a real decision-trace store, thinking out loud as you go.

Get good at operating open models and routing. Frontier models for everything won't pencil out. Frontier for hard reasoning, smaller/open models for high-volume, cost-sensitive, and data-residency work — that's an operating skill to build, not a tool to buy. (I've been measuring exactly how far open models scale on one machine in the MLX dashboard.)

Adopt the contracts as standards. TDQS-style description scoring, termination/dissent/propagation contracts, structured tool responses. None of it is exotic; all of it compounds.

The biggest takeaway isn't any single agent. It's that the durable layer is the framework and the standards — the contracts, the bridges, the quality gates that everyone else builds on. That layer doesn't really exist yet. Whoever builds it well sets the default for how agents get built. That's the prize, and the summit made me more sure it's worth chasing.

11Ecosystem notes, verified

A few things I checked against primary sources afterward, because conference slides age fast:

• agentgateway is real and shipped — an open-source Rust gateway (originated at Solo.io, now an AAIF project) that routes HTTP + gRPC with first-class LLM, MCP, and A2A support. v1.0 landed in March 2026; it joined AAIF in April. Worth evaluating directly against Obot for gateway needs.
• "MCP v2" isn't a thing. MCP is date-versioned — current stable is the 2025-11-25 spec, with the next release candidate dated around 2026-07-28. The 2026 roadmap is scalable stateless transport, Server Cards, enterprise auth and gateway authorization, and governance. Notably, no new official transports this cycle — so gRPC is a custom/experimental transport, not core.
• AAIF membership is organizational (vendors like SAP are members); individuals contribute via GitHub's Contributor Ladder, the working groups, SEPs, or the Ambassador Program (a June 2026 intake was open, next window January 2027).

That's the summit. The models were almost a footnote — the engineering was all in the seams. If there's one sentence to leave with, it's the one four different speakers arrived at independently: name the contract, and you've fixed half the failure.