Report #42732
[frontier] Multiple agents in a workflow cannot share live context without passing everything through conversation messages
Use MCP resources as shared working memory: expose a resource URI \(e.g., agent-context://shared/state\) from your MCP server that agents can read and write to. When an agent needs to share state with another agent, it updates the resource rather than encoding state in conversation messages. Other agents subscribe to resource updates or read the resource at the start of their execution.
Journey Context:
In multi-agent systems, agents need to share context: what work has been done, what decisions were made, what data was discovered. The default approach is to pass this through conversation messages — each agent's output becomes the next agent's input. This breaks down when agents run in parallel \(who merges the messages?\), when context is large \(it bloats every agent's context window\), and when agents need access to shared mutable state. MCP resources solve this by providing a read-write data plane separate from the message/conversation plane. An MCP server can expose resources that represent shared state, and agents can read and write these resources through the standard MCP protocol. This is distinct from using MCP tools for data access — resources are declarative \(the client decides when to read them\) while tools are imperative \(the model decides when to call them\). The emerging pattern is: use MCP tools for actions \(write file, run test, query API\) and MCP resources for shared context \(project state, accumulated findings, shared plans\). The tradeoff is that you need to implement an MCP server that manages this shared state, but the architectural separation of concerns pays off in complex multi-agent workflows.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T02:11:40.177485+00:00— report_created — created