ContextGraph — agents read and write to the same graph, or hand off serialized state via save() and load(), with no message broker required. Use this pattern when splitting work across ingestion, enrichment, reasoning, and reporting roles that must share a single evidence base.
This guide covers multi-agent coordination. For the memory layer each agent uses internally, see Agent Memory. For graph traversal and entity linking, see Context Graphs. For decision recording and precedent matching, see Decision Intelligence.
The Three Coordination Patterns
Before writing any code, choose the right coordination pattern for your pipeline. Shared graph works when all agents run in the same process. They hold references to the sameContextGraph object — thread-safe by default — so every store() from one agent is immediately visible to every retrieve() from another. This is the lowest-latency option and the right default for in-process pipelines.
Save / load handoff works when agents run in different processes, on different machines, or at different times. Agent A finishes its work, calls context.save(path), and Agent B calls context.load(path) to pick up exactly where A left off — full memory, full graph, full vector index. This is how you implement shift handoffs, async pipelines, and cross-service orchestration.
Namespaced memories works when you have a single AgentContext instance serving multiple logical agents, each scoping its reads and writes with a conversation_id. Agents are isolated by tag, not by instance — useful for lightweight role separation without the overhead of multiple contexts.
The pipeline in this guide uses all three.
Pattern 1 — Shared Graph for Concurrent Ingestion
The OSINT collector and the enrichment agent run concurrently. They share a singleContextGraph and a single VectorStore — the graph’s internal RLock makes concurrent writes safe.
Pattern 2 — Save / Load Handoff to a Reasoning Agent
The reasoning agent runs after ingestion completes. In a production pipeline this might be a separate process, a different container, or a scheduled job. The ingestion agents save their shared state; the reasoning agent loads it.load() merges into the existing context — it does not wipe it first. Always create a fresh AgentContext before calling load() if you want a clean restore from a handoff checkpoint.Pattern 3 — Namespaced Memories for Role Separation
The reporting agent does not need its own graph instance. It shares the reasoning agent’s context but scopes its writes to its own namespace — theconversation_id acts as an agent identifier.
conversation_id, or collectively by querying without a filter.
Domain Examples
- Defense — CTI/Threat
- Security — SOC/Incident
- Life Science — Clinical/Pharma
- Banking — Risk/Compliance
A three-agent intelligence fusion cell: an OSINT collector ingests public feeds, a HUMINT analyst loads classified summaries, and a fusion officer synthesizes both streams into a Priority Intelligence Requirement answer. The OSINT and HUMINT agents run concurrently on a shared graph; the fusion officer loads the combined state in a separate process on an air-gapped network segment.
Memory Isolation Reference
When multiple agents write to a shared context, useconversation_id to isolate their streams and retrieve them individually.
conversation_id with user_id:
Related Guides
- Agent Memory — memory storage, retrieval, persistence, and the working memory window each agent uses internally
- Context Graphs — build and traverse the shared
ContextGraphdirectly; temporal interval reasoning; entity deduplication before node insertion - Decision Intelligence — record and trace decisions across agent handoffs with causal chain analysis
- LLM Integrations — configure the LLM provider passed to
query_with_reasoning()in each agent
