Context Graph vs Agent Orchestration: Coordinating Work vs Governing Decisions

Q: What is the difference between agent orchestration and a context graph?

Agent orchestration coordinates work across agents: which agent runs, in what order, with which inputs, handoffs, and retries. A context graph governs decisions: whether each specific action an orchestrated agent proposes is applicable, scoped, current, policy-compliant, and traceable before it reaches a real system.

Q: Does a multi-agent orchestration framework govern agent actions?

No. Orchestration frameworks decide the flow of work, not the validity of actions. A perfectly orchestrated pipeline can still issue an invalid refund or write to the wrong tenant, because every step ran in the right order while no layer judged whether the composed action should happen. Flow correctness and decision validity are different properties.

Q: Do orchestrated agents need a decision boundary?

Yes, and more than single agents do. Multi-agent systems multiply the number of runtime-composed actions and pass context between agents, where it degrades. A decision boundary evaluates each proposed action against current, structured context before execution, regardless of which agent in the workflow composed it.

Q: Is workflow state the same as decision context?

No. Workflow state tracks where the process is: which steps completed, what outputs were produced, what comes next. Decision context is the governing business state: which policy version is in force, which entitlement applies, which exception overrides the default, and whether the facts are current. An orchestrator can hold perfect workflow state and zero decision context.

Patrick Joubert; Patrick Joubert

Context Graph vs Agent Orchestration

Coordinating Work Is Not Governing Decisions

Agent orchestration is how multi-agent systems get built: frameworks that decompose goals into tasks, route work to specialized agents, manage handoffs and retries, and keep long-running workflows progressing.

That layer matters. It is also easy to mistake for decision authority.

An orchestrator answers which agent should act next and what happens when a step fails. A context graph answers whether the action an agent proposes is applicable, scoped, current, policy-compliant, and traceable before it changes a system. A workflow can be perfectly coordinated and still execute a decision that should never have happened.

The Core Distinction

Orchestration operates on the flow of work. Its unit is the step: who runs, in what order, with which inputs, under what retry policy. Its correctness criterion is that the workflow completes as designed.

A decision context graph operates on the validity of actions. Its unit is the proposed action: the refund about to be issued, the record about to be updated, the email about to be sent. Its correctness criterion is that the action is governed: applicable to this case, inside this scope, valid at this moment, compliant with the policy version actually in force, and replayable as a causal decision trace.

Multi-agent systems widen the gap between the two. Every handoff is a place where context degrades, and every added agent multiplies the runtime-composed actions no workflow author reviewed. The more sophisticated the orchestration, the more decisions execute without judgment.

Side-by-Side Comparison

Dimension	Agent Orchestration	Context Graph
Core question	Which agent should act next, with which inputs, and what happens on failure?	Should this specific proposed action happen at all, here, now?
Control point	Workflow graph: task routing, handoffs, retries, parallelism	Per-action decision boundary before execution
State held	Workflow state: step status, intermediate outputs, queue position	Decision context: policy versions, entitlements, exceptions, scope, provenance
Primary artifact	Completed workflow run with per-step logs	Applicability result, allow, escalate, or block decision, causal decision trace
Failure caught	Timeouts, crashed steps, failed handoffs, infinite loops	Valid-looking actions that are wrong for this case: stale entitlement, superseded policy, out-of-scope write

What Orchestration Does Well

Orchestration control	Good at	Does not prove
Task decomposition	Splitting a goal into steps agents can execute	Whether each resulting action is valid for the business case behind it
Agent handoff	Passing work and context between specialized agents	Whether the context survived the handoff current and complete
Retry and fallback	Recovering from failed steps automatically	Whether retrying the action is still applicable after state moved
Parallel execution	Running independent branches concurrently	Whether concurrent writes stay inside each branch's decision scope
Workflow state	Tracking progress across long-running processes	Which policy, contract, or exception governs the action at each step

Why Workflow State Is Not Decision Context

An orchestrator holds workflow state: which steps completed, what each produced, what comes next. That state answers process questions. It does not answer governing questions: which policy version is in force for this entity, which exception overrides the default, whether the entitlement is still current, whether this record set is inside the case’s scope.

The distinction bites at handoffs. Context passed from agent to agent is a copy, and copies go stale. A decision made against context assembled three steps ago can be invalid by the time the execution agent acts on it. Only a layer that re-evaluates the action against live, structured state at the moment of execution closes that gap.

That layer is the decision boundary, and the structure that makes its judgment computable is the decision context graph: policy nodes, entitlement facts, contract terms, and approval history as connected, queryable state, evaluated per action through pre-execution enforcement.

Production Scenarios

Refund pipeline

Orchestration: A triage agent classifies the ticket, a policy agent drafts the resolution, an execution agent calls the refund tool. Every handoff succeeds and the workflow completes.

Context graph: Between drafting and execution, the return window closed and the policy version was superseded. The decision context graph re-evaluates the proposed refund at the moment of the write and escalates it, with the trace showing which fact changed.

Multi-agent research and outreach

Orchestration: A research agent gathers account data, a writer agent drafts the email, a sender agent dispatches it. The orchestrator routes each step correctly.

Context graph: The context graph validates consent, suppression lists, account ownership, and permitted offer terms at the send action, regardless of which upstream agent assembled the draft or how stale its inputs were.

Data migration swarm

Orchestration: Ten agents process record batches in parallel, with retries on failure. The workflow engine keeps all branches progressing.

Context graph: The context graph enforces scope isolation per write: each batch may only touch records inside its assigned tenant and migration window, and a retried write is re-judged against current state instead of replaying a decision that expired.

Where This Fits in the Agent Stack

Orchestration is necessary for multi-agent systems. Someone has to decompose the goal, route the work, survive failures, and keep state across long-running processes. Frameworks do this well and keep improving.

Decision context graphs are necessary for accountable agents. They judge the actions that orchestrated workflows produce, at the only point where judgment is reliable: the moment of the action, against current state, with a causal decision trace as evidence.

The strongest architecture uses both: orchestration to coordinate the work, and a decision boundary in front of every write, so that flow correctness and decision validity are enforced by the layers actually built for each.