You've got three agents running at the same time. One pulls customer data. Another generates a response. The third decides whether to escalate. Then agent one runs again—and it pulls the same data it already fetched five seconds ago. Agent two doesn't know what agent three decided. Everyone's working blind.
This is the shared context problem. And if you're building multi-agent systems past a certain scale, you'll hit it.
What Are Shared Context Patterns?
Shared context patterns are ways agents access and update information that other agents need to see in real time. Think of it like a whiteboard in a room. One agent writes something. All the others can read it immediately. The pattern is the system that keeps that whiteboard clean, current, and safe.
Without it, agents repeat work, make stale decisions, or conflict with each other. With it, they move like a team.
Why Agents Need Shared Context
Single-agent systems are simple. One bot. One brain. It sees everything it needs. But the moment you add a second agent, things get messy.
Agent A might decide to fetch user history. Agent B might be doing the same thing at the same time. Both hit your database. Both get the same answer. Both store it separately. Then agent C runs and doesn't know which answer to trust—or uses information neither A nor B has yet processed.
It gets worse with orchestration. If agent A needs to hand off work to agent B, how does B know what A already tried? If A failed for a specific reason, B needs to see that immediately, not guess.
Shared context solves this: agents write to one source. All agents read from one source. No duplication. No confusion.
Three Patterns That Actually Work
Single Source of Truth
One central state store. All agents query it. All agents update it. Usually a database or cache.
Pros: Simple to reason about. No conflicts over who's right. Cons: Can bottleneck under load. State must be carefully structured so agents don't step on each other.
Event-Driven Context
Agents broadcast what they did or learned. Other agents subscribe to those events and update their local understanding.
Agent A: "I fetched user history. Here's what I found." Agent B watches that channel and incorporates it into decisions. Agent C does the same. Each agent has local context, but they stay in sync through events.
Pros: Scalable. Agents can work independently. Cons: Takes a moment for all agents to see the same picture. Harder to debug if events are dropped or delayed.
Hybrid: Local Cache + Central Sync
Agents keep a local copy of context for speed. A central sync mechanism keeps copies aligned. Works well when you can tolerate temporary staleness but need eventual consistency.
Each agent has fast access to data it needs now. A background process ensures all copies converge to the same state within seconds.
How to Pick the Right Pattern
If your agents need to make decisions in the same instant—like a coordinated API response—go central. Latency matters more than perfect scale.
If your agents work on longer timelines and can handle a few seconds of async updates, event-driven is cleaner. Add a local cache if you need sub-millisecond reads.
For most teams, hybrid works. Fast enough for real-time. Scalable enough for growth.
Where DNotifier Fits
Real-time pub/sub is built for this exact use case. Agents publish context updates. Other agents subscribe to channels. You define what each agent needs to see. DNotifier handles the routing so every agent stays current without polling or rebuilding your own event system.
Monitoring and traceability matter too. If agents are sharing context, you need visibility: Who updated what? When? What was the value before and after? DNotifier gives you that trace so debugging is actually possible when something goes wrong.
Common Gotchas
Stale reads: Agent reads context, makes a decision, then context changes before decision executes. Mitigate by timestamping context and checking freshness before acting.
Conflict resolution: Two agents update the same field at the same time. Decide upfront: last write wins? Merge? Reject both? Don't improvise this.
Over-sharing: Not every agent needs every piece of context. Too much data slows reads. Design channels and context types so agents only see what they need.
FAQ
Should every agent see all context?
No. Filter by role and need. A routing agent doesn't need the full customer conversation history. A response-generation agent does. Share granularly.
What if context updates fail?
Use a queue. Agent writes to a queue. Central system processes the queue and updates state. If update fails, retry. Agents don't wait for acknowledgment.
How fresh does context need to be?
Depends on the decision. Milliseconds for real-time routing. Seconds for research-phase agents. Define your requirement and build to it, not to "as fresh as possible."
Can agents have conflicting local contexts?
Yes. That's why you need reconciliation. Set a rule: central state is source of truth, or merge rules are explicit. Check conflicts on key decisions.
Top comments (0)