The Idea
AgentFlow started with a small annoyance. Bringing a second model in for a different opinion meant copying context across by hand, and the second model started cold: no idea what my codebase looked like, what I had decided, or why.
Inside one tool, I have since built most of what I wanted (From Copy-Paste to Context Engineering covers how that workflow grew). Every repository has a CLAUDE.md, a docs/ directory holds learnings that outlive a session, and the team platform I own keeps a memory store that the next session reads first. Those pieces help much less once a different tool or model is involved. They are files and conventions that one tool knows how to load, not a layer any agent can query and write back to.
AgentFlow is the idea of that layer: one shared, persistent context store that any agent can read from and write to, whichever model is behind it. The core idea has not changed since I first wrote it down. Almost everything around it has.
What Changed My Mind
The first version of this page framed AgentFlow as a streaming problem, borrowed from EventHorizon: ingest context, apply rules about what matters, serve it to consumers in near real time. It also put an orchestrator in the middle to route tasks between models.
What changed my mind was working on several of the pieces that idea would sit on, for other reasons. I built a tenant-scoped MCP server with a fail-closed security boundary, did most of the building on that team Claude Code platform (forty-seven skills, nineteen agents, and an explicit context budget), and ran a standing agent team with a hard rotation rule. None of them was limited by throughput. Each one ran into a question about context: what an agent should see, how much of it, where it came from, or who was allowed to see it at all.
What MCP Changes
The original concept needed its own protocol so agents on different models could reach a shared store. MCP makes most of that unnecessary. If the context layer is an MCP server, any agent whose host speaks MCP can reach it, either as resources the host pulls into context or as tools the agent calls to search and write, and I do not have to write a client per vendor. The integration problem becomes a server design problem, and server design is the part I have practice at.
What MCP does not do is decide anything about the context itself. Its authorization spec tells a server who is calling; it says nothing about what that caller should see. Nor does it say which context belongs in a response, how much of it an agent should load, or who wrote a given entry. Those are the hard parts, and each one maps to something I have already run into.
The Hard Parts
Budget, not storage. Storing context is cheap. Loading it is where the cost is. The team platform started from an 815-line agent file that loaded in full for every session; lazily loading skills on demand cut it to 216 lines (about 277 today). Its memory store keeps the five most recent retrospectives per layer, promotes a pattern only after it recurs three or more times, and forgets the rest on purpose. A context layer that every agent can write to will fill faster than any one session can read it, so reads have to be scoped to the task and capped, and forgetting has to be a feature. An unbounded shared log would be a landfill with more contributors.
Rotation and handoff. On the agent team, a teammate was replaced once its context dropped below 25% remaining, because below that line its quality dropped before anything visibly failed. The outgoing agent wrote a handoff message at that line: files in flight, recent decisions, the open task. Below 15%, replacement happened without waiting for one. That handoff is the most useful shared context I have seen actually work. It is small, structured, and written by the agent that knew the state, at the point the rule says it can still be trusted to write it. I would model writes to AgentFlow on it rather than on transcripts, and I would record how much context the writing agent had left, because the same rule says a note written well past that line deserves less trust.
Provenance. The platform’s memory store earns trust the same way: every retrospective is dated and filed by layer, and a pattern has to recur before it becomes reference material. Across agents and models that matters more, not less. Every entry needs to say who wrote it (which agent, on which model, in which session), when, and from what: a commit, a failing test, a reviewed decision record, or a guess. Without that, the next agent cannot tell a decision from a rumor, and a shared layer spreads whichever one it read last.
A security boundary first. The MCP server I built never accepts a tenant as a tool argument. Scope comes from the token before a tool body runs, and a trusted-host check runs before any token is evaluated. The most dangerous line in its first configuration was a default that let everything work by accident. A shared context layer holds exactly the material that should not cross boundaries: architecture decisions, internal conventions, notes about systems that are not public. Its scope has to come from the caller’s identity, never from an argument the caller controls, and a missing or ambiguous identity has to fail closed. Writes need the same care in the other direction. Whatever one agent writes, the next agent reads as context, so the write path is also a path for bad instructions into every session that follows.
What I Would Build Now
The MCP bridge settled how I would sequence it: build everything that does not depend on a moving framework first, and wire the framework last. That puts the security boundary in the data plane, not in the MCP layer, so it gets built first.
- A context API that enforces scope itself. The store’s own read and write API derives scope from the caller’s identity and stamps every write with its provenance. Nothing in it takes a project or tenant argument, and a missing identity configuration stops the service instead of quietly trusting the wrong issuer. It gets built and tested before any MCP code exists.
- A typed store behind it. Entries carry author, model, session, time, source, and scope. Reads take a task and a budget and return a capped slice, not everything that matches.
- Handoffs as a first-class write. The agent team’s handoff (files in flight, decisions, open task) becomes the default shape of a write.
- Staged writes, promoted on evidence. New entries land in a staging tier. They reach the shared tier when they recur, the way the platform promotes a pattern after three sightings, or when a person reviews them.
- A thin MCP adapter, wired last. It maps resources and tools onto that API and passes the caller’s token through. It holds no scope logic of its own, so the boundary is the same whether a request arrives over MCP or anything else.
What I would leave out of the first version is the orchestrator. On the agent team, deciding who did what was never the hard part: the roles were named and fixed. Getting the right context into each new teammate was. Routing work between models can wait until the layer underneath it is worth routing through.
Where It Stands
Concept. There is no AgentFlow product code. What exists are pieces I built for other reasons: an MCP server with a fail-closed boundary, a budgeted memory loop inside a team’s Claude Code platform, and a rotation discipline for agent teams. None of them is AgentFlow, and I am not going to present them as if they were. They are why I now think the hard part of shared context is judgment about what to share, with whom, and how much, and not the plumbing that moves it. Shared context is a trust problem before it is a transport problem.