Note: body below is original English text from the Substack post. Do not treat this file as a translation.
sohit kumar · Sep 11, 2026 · https://sohit.substack.com/p/the-coordination-backbone-architecting
An agentic system is not just a collection of agents that can call tools and talk to one another. The difficult part is deciding what happens after an agent finishes.
An agent receives an intent, context, and a set of input artifacts. It performs work, uses tools, and produces output artifacts and evidence. It also signals what it believes should happen next.
Intent + context + artifacts → Agent work → Artifacts + evidence + proposed next action
That proposed next action might be correct, but proposing a transition and performing a transition are different responsibilities.
The platform must decide how each transition should behave. Some transitions can proceed immediately. Some must satisfy deterministic checks. Some require a human decision. These rules belong to the orchestration system—not to whatever an agent invents while it is running.
This is the foundation of reliable multi-agent orchestration.
Begin with the work unit
Before choosing agents or drawing an execution graph, define the unit of work. From first principles, every work unit should answer:
- What intent is being served?
- What inputs and artifact revisions does the work consume?
- Which agent or capability owns the work?
- Which tools may be used, and with what permissions?
- What outputs and evidence should be produced?
- What outcomes can the agent report?
- What next action can the agent propose?
- What must be true before that transition is allowed?
Without this contract, the platform is only passing messages between models. With it, each piece of work becomes observable, testable, resumable, and safe to connect to other work.
Agents produce more than text
The useful output of an agent is a structured result, not simply a response in a conversation. A result can contain:
- output artifacts and their revisions;
- evidence showing what the agent did;
- a typed outcome such as completed, blocked, waiting for input, recoverable failure, or terminal failure;
- the intent of the proposed next task;
- a requested capability or suggested next agent;
- any gate or recovery action that is needed.
This lets the agent use judgment without giving an unstructured response control over the execution state.
The agent catalog makes routing intelligent
A multi-agent system needs an agent catalog or registry. It describes which agents exist, what capabilities they provide, what tasks they can own, which tools they can use, and any constraints that affect their eligibility.
The next owner can still be deterministic. If a configured rule says that an approved product artifact always goes to an architecture agent, the assignment is already known.
But the platform can also use the current intent and context to determine what capability is needed next, query the agent catalog for eligible agents, and select the best match. For example, an implementation agent might discover that the next task needs security review rather than ordinary code review. It proposes that intent; the platform resolves it against the catalog and transition rules.
The key is to route by capability and eligibility, not by a growing collection of hard-coded agent-to-agent mappings.
Treat the next state as a proposal
When an agent finishes, it emits an outcome and proposes what should happen next. The orchestration engine then applies the transition policy for that proposed edge.
The policy may allow the handoff to proceed directly. It may require a valid output schema, an artifact at the correct revision, resolved dependencies, permission checks, an approved review, or a human answer. Different transitions can have different requirements inside the same platform.
Agent proposes next action → Read transition policy → validate or proceed → commit transition and dispatch, or preserve state and return recovery action.
This keeps the system flexible. The model can reason about the next useful step, while the platform controls whether that step is currently admissible.
Model every meaningful outcome
Success is only one possible result. A dependable orchestration system should model at least these outcomes explicitly:
- Completed: the work produced the required output. The transition can proceed once its configured checks pass.
- Waiting for human input: the work cannot continue until a person answers a material question or approves a specific artifact revision. The gate should be durable and tied to the affected work.
- Recoverable failure: something is missing or fixable. Preserve the current work and evidence, then expose a bounded action such as retry, repair, publish a missing artifact, answer a gate, or defer.
- Terminal failure: the work cannot safely continue. Stop it deliberately and retain enough evidence to understand why.
- Transient system failure: the platform could not determine or commit the transition because a service or transport boundary failed. Retry the same idempotent command; do not pretend the run advanced.
Reliable orchestration means these states cannot be confused with one another. A missing outcome must not look like success. An unanswered gate must not look like failure. A timeout must not create a duplicate dispatch.
Keep execution state durable
Conversation history is useful context, but it is not a reliable state store. Persist the facts required to resume and audit the work:
- run and work-node state;
- attempts and immutable attempt revisions;
- input and output artifact references;
- agent ownership and dispatch identity;
- gates, blockers, and human answers;
- tool and transition evidence;
- retry, defer, interrupt, and terminal outcomes;
- events used to rebuild user-facing projections.
Every state mutation should have one authoritative write boundary. Use idempotency keys for dispatch and transition commands, bind outcomes to the exact attempt that produced them, and reject stale or ambiguous completions. These details are what make transitions reliable under retries, crashes, delayed callbacks, and concurrent agents.
The orchestration engine is the coordination backbone
The orchestration engine is the platform component that turns intent, current state, and agent proposals into running work. It does not require the entire graph to be defined in advance. It should not make the specialist’s product, design, architecture, or implementation decisions. Its responsibility is to coordinate those decisions reliably.
The engine should:
- read the current intent and durable run state;
- determine which tasks and transitions are currently eligible;
- resolve the required capability through the agent catalog;
- create a bounded work packet containing context, inputs, artifacts, and tool policy;
- dispatch the selected agent with a unique attempt identity;
- receive its artifacts, evidence, typed outcome, and proposed next action;
- apply the transition policy, including any configured validation or human gate;
- commit the result exactly once and prevent duplicate dispatch;
- preserve blocked and failed work with a clear retry, repair, defer, or stop path;
- publish events and projections so people and other systems can see what happened.
This creates a clean boundary: agents own judgment; the orchestration engine owns coordination, state integrity, and execution continuity.
The platform should make new agents additive
The orchestration engine should support a growing multi-agent system without requiring a new hard-coded route every time an agent is added. To register an agent, the platform should let you define what the agent does, which responsibilities it owns, what inputs it accepts, what outputs it produces, which tools it may use, and which policies constrain it.
Once that contract exists in the agent catalog, the engine can discover the agent when its capability matches the current task and intent. An agent can propose one next task or many, and the engine can create those nodes, connect their dependencies, resolve their owners, and dispatch them. A run may therefore begin with one node and grow to ten as new work is discovered. Adding a security reviewer, research specialist, or deployment agent becomes primarily an agent-catalog change—not a rewrite of the orchestration core.
Predefined execution paths can still be used when the sequence is known, but they are optional constraints rather than a requirement. That is what makes the system evolvable: agents, tools, and execution graphs can change around a stable coordination backbone.
Support multiple coordination patterns
The orchestration engine should not hard-code one way for agents to work together. An agent’s standard next-work proposal should describe the tasks to create, their dependencies, the capabilities they need, any results that must be joined, and any review or transition checks.
In a sequence, an agent proposes one next task.
- With a coordinator, the coordinator proposes several tasks and the engine assigns them.
- In a planner-executor pattern, a planner proposes a larger task graph.
- In fan-out, one result creates several parallel tasks; fan-in waits for their combined result.
- In peer-to-peer coordination, an agent proposes a direct handoff to another capability.
- With a reviewer, completion creates a review task before the result is accepted.
Sequence, fan-out, and fan-in are scheduling behaviors derived by the orchestration engine from that proposal. Coordinator, planner, and reviewer are agent roles resolved through the agent catalog. The engine supports all of them through the same primitives: create work nodes, connect dependencies, resolve agents, dispatch attempts, record outcomes, and apply transition policy.
For example, a software request may begin with one product agent. That agent proposes frontend and backend tasks, which run in parallel. When both finish, the engine creates a review task. If the reviewer discovers a security concern, it proposes a security-review task. One run has now combined fan-out, fan-in, review, and dynamic task creation without changing the orchestration engine.
A practical architecture
The agent catalog answers who can do the work. Durable state answers what is true now. The agent proposes what work should exist next. The engine turns that proposal into sequence, parallel work, or joins; creates the required nodes; resolves coordinator, planner, reviewer, or specialist agents when needed; and dispatches the next ready task. The graph emerges as the work progresses.
This architecture keeps agent reasoning flexible while making transitions reliable.
At Prinevo.ai, we are building this coordination layer for software delivery - a platform where a team of self-learning agents works together across product thinking, architecture, implementation, review, and verification to ship verified, production-ready software.