Most multi-agent systems today are good at exchanging messages.
But sharing context is still surprisingly awkward.
Agent A learns something useful.
Agent B needs that information later.
Agent C may need to contribute to it.
Very quickly, we end up building custom infrastructure around:
- shared databases
- vector stores
- prompt injection
- synchronization logic
- message buses
- application-specific memory layers
I’ve been working on a different model in Priostack.
It is called the Agent Context Network.
The core idea is simple:
«Context should be a resource that agents can own, discover, share, and contribute to.»
From message passing to shared context
Imagine three independent agents.
Agent A
|
| creates
v
Project Context Space
^
| read
Agent B
Agent C
|
| write
v
Project Context Space
Agent A creates a persistent context space.
Agent B asks for read access.
Agent C receives write access.
Now the agents do not need to repeatedly send the entire project state to each other.
They can interact with the same shared context.
Why permissions matter
This is the part I find particularly important.
In many multi-agent designs, shared memory effectively means:
everyone can see everything
That becomes problematic once agents start representing different:
- users
- organizations
- teams
- services
- responsibilities
- levels of trust
An agent should not automatically inherit everything another agent knows.
So context spaces in the Agent Context Network have explicit access control.
Conceptually:
Agent A owns Space X
Agent B -> request READ
Agent A -> grant READ
Agent C -> request WRITE
Agent A -> grant WRITE
Read and write access are separate capabilities.
This turns agent memory into something closer to a network resource rather than an internal implementation detail.
Persistent context outside the agent
Another important property is that the context does not have to live inside the agent itself.
An agent can disappear.
A different agent can connect later.
The shared context remains available according to its permissions.
That makes it possible to build longer-lived systems where knowledge outlives individual agent executions.
For example, a space could represent:
/customer/acme
/project/payment-migration
/research/quantum-computing
/company/compliance
/team/backend
Multiple agents could progressively enrich those spaces.
Agents can negotiate access themselves
I also wanted the interaction to be agent-driven.
An agent can encounter a context space it needs and request access.
The owning agent can decide whether to grant it.
That opens interesting possibilities.
Instead of developers manually wiring every relationship:
Agent A knows Agent B
Agent B knows Agent C
Agent C uses database D
you can start thinking about agents participating in a context network.
discover
↓
request access
↓
grant permission
↓
read / contribute
Why I think this matters
I increasingly think multi-agent architecture has two distinct layers.
The first is communication:
Agent A -> message -> Agent B
The second is shared state:
Agent A
Agent B -> Context
Agent C
We have spent a lot of time building the first layer.
The second one is still often implemented independently inside every application.
My hypothesis is that shared context will eventually become infrastructure of its own.
Just like agents can call APIs, tools, or MCP servers, they should be able to access persistent context with explicit ownership and permissions.
I built this in Priostack
I’ve implemented an initial version of this model as the Priostack Agent Context Network.
Agents can register, create context spaces, request access to spaces owned by other agents, grant permissions, and collaboratively work with persistent context.
You can find it here:
https://priostack.com/agent-context-network
I’m still exploring the model, so I’m particularly interested in architectural feedback.
How are you handling this today?
Do your agents share a database?
A vector store?
Do they exchange summaries?
Or do you think context itself should become a first-class network resource?
Top comments (0)