I put orchestration at the centre because several agents need to work together to achieve a goal. Someone needs to coordinate that work and delegate the tasks. When one agent does too much, it becomes unclear what it is responsible for. If something goes wrong, I want to understand what happened and why.
In a multi-agent system, several agents contribute to the same piece of work. Giving each agent a useful capability is only part of the design. The system also needs to assign tasks, decide when they can run, handle their results, and keep a record of the decisions along the way. Orchestration is the part responsible for coordinating that work.
This is why Synedrix OS, the governed operating layer for agentic business systems, puts orchestration at the centre of its architecture. Principle 2 (Orchestration is the center of gravity) describes coordination as the lasting investment while models, tools, and agents change. The platform is in active development; the responsibilities described here are architectural requirements, rather than a claim that the complete system is already running.
Start with the goal and divide the work
Consider an illustrative purchasing request. A team needs equipment within an agreed budget. Reaching that goal may involve checking what is available, comparing suitable options, obtaining approval, and placing an order. Completing one of those tasks does not mean the purchase is complete.
The goal needs to be specific enough for the system to recognise success. In this example, finding a suitable product is insufficient if the purchase exceeds the budget or lacks the required approval. Those conditions belong to the definition of the requested outcome. They give the process something to check at completion, instead of treating the last successful tool call as proof that the job is done.
An agent assigned to compare options needs the relevant requirements and a clear description of its expected result. It should return a comparison that the next step can use. The approval task needs a different responsibility: deciding whether a proposed purchase meets the applicable conditions. Placing the order is another task, with permission to make a change in an external system.
The orchestration layer connects these tasks to the goal. It determines which work can proceed, which work depends on an earlier result, and where approval is needed. If the comparison is incomplete, the process needs a defined response. If approval is required, the ordering task must wait. If a task fails, the system needs to decide whether to retry, stop, or ask for help.
The sequence also needs to reflect which tasks depend on others. Availability and product suitability could be checked independently if both have the information they need. An approval decision, however, may depend on the selected option and its total cost. The ordering step depends on the approval. Running everything at once would ignore those relationships; running everything in sequence could introduce unnecessary waiting.
A task graph records those relationships: the tasks, their dependencies and the conditions under which each can proceed. It gives the orchestration layer an explicit plan to execute. It also gives a later reviewer a way to compare the intended sequence with what actually ran.
The orchestration layer also has to determine whether the result meets the goal. Even a successful order submission does not prove that the requested quantity, budget and approval conditions were satisfied. The goal model requires evidence of those conditions before the goal can be marked complete.
Give each agent a clear responsibility
In Synedrix OS, the Orchestrator Agent (os-agt-001) routes and sequences work. It does not make the domain decisions or write directly to external business systems. Those actions are delegated through controlled invocations to agents with the appropriate responsibilities and permissions.
This boundary matters in the purchasing example. Coordinating the approval step and deciding whether a purchase is acceptable are separate jobs. Combining them makes it harder to tell whether a problem came from the routing, the approval decision or the action taken afterwards.
The design uses a few related terms to describe the work. An agent's mission is its continuing purpose. A goal is an outcome to achieve in a particular situation. A task is a defined piece of work assigned to an agent, and an action is a step that agent takes to carry it out. Comparing equipment options could be a task; calling an authorised tool to retrieve those options could be an action.
These definitions help separate what belongs to the process from what belongs to one agent. The agent receives the task and the context it is permitted to use. The orchestration layer remains responsible for how that task fits into the wider goal. An agent can reason through its assigned work without taking over the business process around it.
Decide what happens when a task fails
A purchasing process needs a response to uncertainty as well as success. Suppose the ordering agent submits a request and the supplier connection times out. The timeout tells the system that it did not receive an answer. It does not establish whether the supplier accepted the order.
Repeating the request immediately could place the order twice. A safe retry requires a way to recognise the same operation, such as an idempotency key: a stable identifier used to prevent a repeated request from producing the same effect again. Where the action cannot be made safe to repeat, the architecture requires reconciliation or escalation instead of automatic replay.
That response belongs in the execution rules before the failure occurs. The agent assigned to order equipment should not have to invent a recovery policy while it is unsure whether it already spent money. The process needs to preserve the request and its outcome, including an unresolved outcome, so the next step has evidence to work from.
Waiting for approval is a different situation. The work has reached a checkpoint and needs a decision before it can continue. Treating that wait as a failed task could trigger an inappropriate retry. Recording the state explicitly allows the system to distinguish a pending decision from a failed call and handle each according to its contract.
These cases show why coordinating agents involves more than choosing the next one to call. The process must account for dependencies, permission and what is known about each result. A useful failure record explains where work stopped and what remains uncertain, so someone can decide how to proceed without guessing what already happened.
Keep enough evidence to explain the result
Clear responsibilities give a review a starting point. The records of execution need to show what actually happened.
Suppose the equipment ordered does not meet the request. A useful investigation follows the request through the comparison, approval, and order. It checks the inputs each agent received, the result it returned, the permissions involved and the action that followed. That makes it possible to distinguish a poor recommendation from a correct recommendation that was handled incorrectly later.
Synedrix OS requires the records across that path to remain connected. A correlation identifier links work belonging to the same process, while causation records connect an event or action to what triggered it. The Audit & Lineage Agent (os-agt-008) uses execution records, policy decisions, and tool-call logs to reconstruct the sequence. It has a read-only role, so investigating an outcome does not give it permission to change that outcome.
The distinction becomes practical when reviewing an incorrect purchase. If the comparison returned the wrong product, the investigation starts with its inputs and result. If the approved product was correct but the ordering task submitted a different identifier, the problem is at that later step. If an order proceeded without its required approval, the investigation concerns the execution controls. Each case calls for a different correction.
The explanation must be supported by the recorded work. This does not mean a reviewer can explain every part of a model's internal reasoning. Its stated reason must be examined alongside the task input, policy decision and tool results. Where evidence is missing, the review should make that gap visible. Coordination gives the work a structure to follow, and the audit requirements specify what must be retained to examine it afterwards.
Improve an agent without redesigning the process
Once a task has a defined input, output, and responsibility, its implementation can change while the surrounding process remains understandable. The comparison agent might use a different model, for example, while still returning the information the approval task expects.
That replacement still needs testing. A model can produce a correctly shaped answer that is inaccurate or unsuitable for the task. Keeping the contract stable helps contain the change; it does not remove the need to check behaviour, permissions and downstream effects.
This is the practical meaning of investing in coordination. The organisation keeps its understanding of how work is assigned, approved and recorded as individual components improve. It does not need to rediscover the whole process every time an agent changes.
Changing a component can also reveal a weakness in the contract. If the approval task depends on an assumption the comparison never records, swapping models may expose that missing information. The answer is to make the dependency explicit and test it, rather than adding more instructions that every agent must remember. A stable coordination pattern still needs maintenance when business requirements change.
There is a cost to maintaining those contracts and handling failures between tasks. The benefit is clearer ownership of that work. In Synedrix OS, the orchestration layer carries that responsibility so each agent can stay focused on its task. The next post, Why specialized agents beat mega-agents every time, examines what that means for the agents themselves: how narrowly to define their responsibilities and what specialisation makes easier to test and explain.
Related reading
- The 12 principles that make agentic systems trustworthy — places coordination alongside the requirements for control and accountability.
- From static workflows to agentic operating systems — explains how a goal guides work across several agents.
- Next in the series: Why specialized agents beat mega-agents every time — examines how focused responsibilities support coordination.
Documentation
- Orchestration: what the orchestration layer owns and how it coordinates work.
- Goal Model Spec: how goals are defined and what evidence is needed to mark them complete.
- Agent Registry: each agent's responsibilities, permissions, and escalation path.
Synedrix OS — orchestration as the center of gravity
