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 operatio