Multi-agent coordination with shared context

When several agents work on the same problem, they need to share what they know. A research agent gathers information, a drafting agent turns it into something, a review agent checks the result, and each one depends on what the others produced. The hard part isn't the individual agents; it's the ground truth between them, the shared context they all read from and write to, kept consistent as they work.

Exabase Bases give you that shared context as a primitive. A Base is a common environment, its own memory, files, and search, that multiple agents can read and write. One agent writes; another reads what it wrote. This page is about using a Base as the shared state for a multi-agent system, so coordination doesn't turn into a state-management project of its own.

It's worth noting this is the same Base primitive used the other way around. For multi-tenant SaaS and per-user products, a Base isolates one tenant from another. Here, the same isolation that seals tenants apart is used to seal a team of agents together: everything inside the Base is shared among them, and sealed off from everything outside. One primitive, two uses, depending on who you put inside it.

The problem

Coordinating multiple agents is mostly a problem of shared state, and shared state is famously where things go wrong. Each agent produces output the next one needs, so somewhere there has to be a common place they all agree is the truth. Build that yourself and you're into the territory of passing context between processes, keeping it consistent when more than one agent touches it, and making sure an agent reads the current version rather than a stale copy.

The naive approaches each have a failure mode. Passing everything through the prompt chain, agent A's output becomes agent B's input, breaks down as the context grows past the context window and gives you no shared store, just a relay. Wiring agents to a database you manage means building the schema, the access patterns, and the consistency handling, and then keeping memory, files, and search coordinated across it. And without a single source of truth, agents drift out of sync: the drafting agent works from what the research agent found an hour ago, not what it just corrected, and the review agent checks a version that's already moved on.

What you actually want is a shared environment the agents treat as common ground, where what one writes is what the others read, without you building the plumbing that keeps it coherent.

What Exabase unlocks

With a Base as shared context, a multi-agent system gets a common source of truth without you building one.

Agents read and write the same environment. The research agent writes its findings into the Base as memory and resources; the drafting agent reads them and writes its draft back; the review agent reads the draft and the findings and writes its assessment. Each agent works from what the others actually produced, in one shared store, rather than from copies relayed through a chain.

The shared context stays coherent. Because memory in the Base resolves contradictions, when one agent updates something the others see the current state rather than the old and new versions side by side. The drafting agent works from the research agent's corrected findings, not its first draft of them, because the Base holds one current truth rather than an accumulating pile.

And the coordination comes without the state management. You're not building inter-process context passing, a consistency layer, or a shared schema. The Base is the shared state, and reading and writing it is the coordination, so the system's complexity stays in the agents' logic rather than spilling into infrastructure you maintain.

How it works

Three primitives, with the Base as the shared environment and Memory and Resources as what the agents exchange through it.

Bases

A Base is the shared context. Rather than one Base per user, you put a team of agents on one Base, and it becomes their common ground: its memory, files, and search are shared among every agent working in it. Everything inside is available to all of them and sealed off from anything outside, so the Base is both the thing they share and the boundary around the collaboration. Creating it is a single API call, and the same snapshotting that versions any Base lets you checkpoint the shared state before a stage that might go wrong.

Memory

Exabase Memory in a shared Base is how agents pass along what they've learned rather than just what they've filed. An agent writes findings, conclusions, and context to memory, and another retrieves them as a coherent picture. The contradiction handling matters more here than usual, because multiple agents are writing: when two agents contribute conflicting information, or one updates what another wrote, entity resolution keeps the shared memory current rather than letting it fill with contradictions. The agents share one evolving truth, not a log of everything any of them ever said.

Resources

Resources are the artefacts agents hand off: documents, gathered material, drafts, outputs. One agent writes a Resource, another reads it, and because Resources are indexed for Deep Search, an agent can find what it needs in the shared store by meaning rather than needing to be handed an exact reference. The shared workspace is searchable, so agents locate each other's output rather than depending on a rigid pipeline order.

Example architecture

The pattern is a shared Base that agents take turns reading from and writing to.

Create one shared Base for the collaboration. Every agent in the system operates against it.

Each agent reads, works, and writes back. The research agent gathers and writes findings to Memory and source material to Resources. The drafting agent retrieves those findings and searches the material, produces a draft, and writes it back as a Resource. The review agent reads the draft and the findings and writes its assessment.

Coordinate through the shared state, not through a brittle relay. Because all agents read and write the same Base, the order can be flexible and an agent always sees the current shared truth. Use snapshots to checkpoint before a risky stage if you want to be able to roll the shared state back.

One Base holds the shared context, every agent reads and writes it, and contradiction-resolved memory keeps it coherent as they do. The coordination is the shared store, not a state-management layer you built.

What compounds over time

The value here is less about a single system accumulating over months and more about what becomes feasible to build, though there's a compounding angle too.

A shared, coherent context store makes more ambitious multi-agent systems practical. The harder coordination gets, the more the shared-state problem dominates, and having it solved as a primitive is what lets you add agents and stages without each one multiplying the plumbing. As a system runs, the shared Base also accumulates a record of what the agents produced and decided, which becomes its own searchable resource, and because the shared memory self-organises, it stays coherent rather than turning into a tangle as more agents contribute to it.

Building the shared-state layer yourself is the kind of infrastructure that gets more fragile as the system grows, more agents, more writes, more chances for two of them to step on each other. A Base as the shared primitive doesn't get more fragile as you add agents, because consistency is a property of the store rather than something each new agent has to coordinate. The complexity stays in the agents, where it belongs, instead of in the glue between them.

Who's building this

Teams building multi-agent systems, agent pipelines, and orchestrated workflows where several agents collaborate on one task and need a common context, research-and-drafting systems, multi-stage processing, any setup where one agent's output is another's input.

The shared-Base idea is the inverse of the isolation in multi-tenant memory for SaaS, worth reading for how the same primitive serves both. Version control for agent context covers snapshotting the shared state, and for the individual agents in your system, the long-term memory and per-agent patterns in long-term memory for any agent apply.

Get started

Start with the getting started guide, then about Bases and creating Bases for the shared environment, plus creating memories and retrieving memories for how agents exchange context. There's a free tier to build against.

FAQs

How do multiple agents share context?

They work against one shared Base. Its memory, files, and search are common to every agent in it, so what one agent writes, another reads. The Base is the shared state, and reading and writing it is how the agents coordinate.

What stops agents overwriting or contradicting each other?

For memory, entity resolution keeps the shared store current when agents contribute conflicting information or one updates another's work, so the picture stays coherent rather than filling with contradictions. The agents read one current truth rather than every version ever written.

Isn't this the opposite of what Bases are for?

It's the same primitive used the other way. A Base isolates everything inside it from everything outside. For multi-tenant SaaS you put one tenant in each Base to keep them apart; here you put a team of agents in one Base to bring them together. The isolation boundary is identical; what differs is who's inside it.

Do the agents have to run in a fixed order?

No. Because all agents read and write the same shared store and search it by meaning, an agent can find what it needs without being handed an exact reference in a rigid sequence. A fixed pipeline order is one option, not a requirement.

Can I roll back the shared state if a stage goes wrong?

Yes. The Base supports filesystem snapshotting, so you can checkpoint the shared context before a risky stage and revert if needed. Version control for agent context covers this.

Does each agent also get its own private memory?

That's your design choice. You can keep everything in the shared Base, or give individual agents their own Bases for private working memory alongside the shared one. The long-term memory use case covers per-agent memory.