How context travels in a multi-agent world

Engineering teams building with AI agents have largely solved the single-agent problem. The harder challenge arrives when capabilities get split across multiple independently deployed agents — each owned by a different team, each running on its own release cadence. Keeping a coherent conversation alive across those boundaries turns out to be one of the messier architectural questions in production agent systems today, and one that Tessl's own work on context engineering and skill sprawl has been circling from a different angle.

Microsoft's Industry Solutions Engineering (ISE) team, which embeds with clients on complex technical engagements, has published a detailed account of how they tackled that context problem in a recent engagement.

Working with Agent2Agent (A2A) — an open agent communication protocol originally developed by Google and now maintained by a cross-vendor technical steering committee at the Linux Foundation — they needed coordinator agents to hand off conversational history to domain agents that held no shared infrastructure and no persistent memory. Where the Model Context Protocol (MCP) standardises how agents connect to tools and data, A2A operates at a different level: it defines how agents communicate with each other as peers, passing tasks and messages across service boundaries.

Shared storage creates dependencies agents shouldn't have

Microsoft says it evaluated three core approaches before settling on the one that worked best.

The first option entailed domain agents reading from a shared storage layer, using a common identifier to retrieve conversation history. The appeal with this is minimal message size and a single source of truth, but it requires every domain agent to have credentials and connectivity to storage owned by another team — a dependency that becomes unwieldy fast when agents cross organisational lines. A second option makes each domain agent stateful, maintaining its own record of the conversation. However, the operational overhead of running per-agent storage, handling state migration during deployments, and avoiding divergence between agents ruled this out early.

The third approach, and the one Microsoft ultimately adopted, sends summarised conversation history directly inside each message payload. Domain agents receive everything they need to respond coherently without touching any external store. After every ten conversational turns, the history gets summarised to keep payload sizes manageable — a deliberate trade-off between fidelity and performance that the team acknowledges.

"Summarisation is not without risk," they write. “Every summarisation step can lose important details or introduce inaccuracies, potentially degrading the quality of downstream responses.”

The counter, though, is that passing full conversation history unchecked creates its own problems — models fed too much context can lose coherence, prioritising volume over relevance. The 10-turn threshold is the team's answer to that, and one they say can be tuned against observed output quality. They also note that summarisation creates a natural security boundary, giving the coordinator fine-grained control over what each agent sees — something that storage-level access controls, applied uniformly, cannot easily replicate.

“The coordinator controls exactly what context each domain agent receives,” the company writes. “Sensitive information from one part of the conversation can be excluded from the context sent to a specific agent."

Context architecture is a governance decision with engineering consequences

Microsoft makes the case that keeping domain agents stateless pays dividends well beyond the immediate context problem. Agents that carry no state of their own are easier to reason about — their behaviour is determined entirely by what arrives in the message, making failures straightforward to diagnose.

"Debugging reduces to inspecting the input message rather than reconstructing an agent's internal state history," Microsoft writes. "This also simplifies deployments — any agent instance can be replaced or rolled back without state migration."

Those properties matter most when agents operate across team or organisational boundaries, where auditability and predictability carry real weight.

For engineering teams in that position, the choice of context pattern has consequences well beyond message size. It determines who owns the conversational record, who can audit what any given agent was told, and how safely the system can grow when new agents are added or team boundaries change.