They represent different kinds of truth
| Execution graph | Context graph | |
|---|---|---|
| Primary question | What should run next? | What is now true and why? |
| Nodes | Agents, tools, functions, gates, waits and recovery actions | Evidence, requirements, risks, decisions, plans and deliverables |
| Edges | Control flow, branching, joins, retries and loops | Supports, governs, authorizes, contains, supersedes and derives from |
| Lifetime | The current run and its checkpoint history | Durable organizational state across runs |
What breaks when only one graph exists
Execution history without durable context
A later Agent must reconstruct the current decision from logs, prompts or chat. The team can see that a node ran, but not which result is authoritative or which evidence survived review.
Context without execution provenance
Objects appear in a knowledge graph without a reliable account of the policy, quality gate, tool call or human decision that promoted them. The organization cannot explain why a draft became confirmed context.
The projection boundary connects them
A Pack declares a context projector. It runs only after the workflow reaches an approved state and converts selected run state into typed, versioned objects and relations. Every projected object keeps the producing run, node, actor, timestamp and source identifiers.
- Temporary implementation state stays in the execution layer.
- Rejected or incomplete work does not silently become organizational truth.
- Durable context remains domain-oriented rather than tied to one handler or storage engine.
- Later runs can query confirmed context through a read-only runtime interface.
The connection is not an analytics add-on. It is the mechanism that turns a disposable Agent run into governed organizational work.
A concrete software-delivery example
Run A verifies a change, records code-owner and release-manager decisions, and projects a Release object after approval. Run B observes deployment health, queries that exact approved Release, records its object ID, version and source run, then links a new Deployment observation back to it.
Read the canonical architecture explanation on GitHub →