An agent investigating a failed service may need to read operational information, assess possible causes, and recommend a response. Giving that same agent permission to approve a repair, apply it, and judge whether its own actions were acceptable adds several different responsibilities to the assignment.
Those responsibilities matter when the result is wrong. An incorrect diagnosis needs a different investigation from an unauthorised repair or an inaccurate account of what happened. Keeping them distinct gives the team a clearer way to examine the failure and decide which part needs to change.
A specialised agent has a defined mission, permitted actions, inputs, outputs, and a route for work it cannot resolve. Synedrix OS, the governed operating layer for agentic business systems, uses these roles within coordinated workflows. The argument for specialisation is about responsibilities that can be tested and controlled. It is not a claim that adding more agents automatically improves every task. The platform is in active development; this article explains its design requirements.
Define the responsibility before writing the instructions
Consider an illustrative incident investigation. One agent's mission might be to assess the available evidence and recommend a recovery action. That can involve several reasoning steps. A narrow role does not require a trivial task or a separate agent for every operation.
The useful limit is what the agent owns. Its result should identify the relevant evidence, recommendation, and unresolved questions. The surrounding process should know whether it is receiving an assessment or permission to change a service. Those are different results, even when both can be expressed as convincing text.
A one-sentence mission helps reveal the intended responsibility, but the sentence alone is insufficient. “Manage the incident” fits in one sentence and can still conceal diagnosis, approval, execution, and review. The definition needs to make those responsibilities and permitted actions inspectable.
In Synedrix OS, the agent registry records the agent's identity, version, capabilities, permissions, and contracts. A contract specifies the information an agent receives and the result it must return. The runtime executes the assignment within its declared limits. The declaration and its enforcement are separate parts of making the role work.
Several roles may use the same underlying model. The separation concerns the task, available information, tools, and authority. A model's broad capability does not require each use of it to carry broad permission.
Keep recommendation, approval, and action distinguishable
The investigation agent may recommend restarting a service. That recommendation does not establish that the restart is allowed or that the agent may perform it. The process needs to evaluate the applicable rules and obtain any required human decision before the action proceeds.
Decision scope describes the kind of authority an agent has. A recommend-scoped agent proposes an action. An approve-scoped agent validates or blocks a proposal. An execute-scoped agent may trigger permitted effects under the required controls. The specific tools, systems, and actions still need to be declared; the scope label alone is insufficient.
For the incident, the recommendation can therefore become an input to the control process. An authorised execution role receives the action that may proceed, tied to the actual proposal and its conditions. A later change to the proposed repair requires establishing whether the earlier decision still applies.
This division gives the implementation something concrete to check. An investigation role that requests a write tool should be refused if that tool is outside its permitted set. A prompt telling the agent to limit itself to analysis cannot provide that protection on its own.
A narrow role makes the intended permission easier to state and verify. The result still depends on the runtime and tool path applying the limits correctly. A diagram showing separate agents does not demonstrate that enforcement.
Test the role and the handoff
A focused investigation can be assessed against a specific responsibility. Does it use the relevant operational evidence? Does its recommendation follow from that evidence? Does it identify uncertainty rather than present an unsupported conclusion as established fact?
The next task also needs a usable result. A recommendation without the affected service, supporting observations, or relevant conditions may be well written and still be unsuitable for approval. Testing therefore needs to cover the handoff as well as the agent's isolated answer.
Specialisation can help locate a failure. If the recommendation is wrong, the team can examine the assessment. If the approved action is correct but a different operation is submitted, the review moves to execution. If the action proceeds without its required approval, the control path needs investigation.
It also supports more focused changes. A revised model or prompt for the investigation role can be evaluated without deliberately redesigning the approval mechanism. Its contract may remain stable, while its behaviour still needs checks for accuracy, permission use, and downstream effects.
Useful evaluation cases should include incomplete evidence and requests outside the role's scope, as well as straightforward incidents. Comparing an old and new version on those cases helps reveal a change in behaviour that an unchanged output format would miss. The team still needs to assess whether the result supports the next decision, not simply whether it can be parsed.
Fault isolation has conditions. Two agents with excessive access to the same records or tools can still affect one another. A mistaken result can also travel through a valid contract. Separation makes failures easier to investigate; it does not make connected tasks independent of one another.
Understand the different classifications
The registry specification describes six archetypes, broad categories of work. Control covers coordination, routing, and policy gates. Execution covers domain actions with effects in external systems. Intelligence covers analysis, forecasting, and anomaly detection without direct business side effects.
Interface covers interaction with people or customers. Interop covers connections between agents and tools or external agent systems. Audit covers trace synthesis, lineage, and compliance review. These descriptions help identify the kind of work a role performs; they do not replace its actual permission declaration.
The current OS catalog uses a separate family classification and lists 12 agent definitions across control, intelligence, and observability. Family, archetype, home layer, and decision scope answer different questions. Combining them into one list of agent types would lose important distinctions.
For example, the Orchestrator Agent (os-agt-001) and Policy Guard Agent (os-agt-002) both belong to the control family. The Orchestrator Agent (os-agt-001) has execute scope for coordinating and delegating work; the Policy Guard Agent (os-agt-002) has approve scope for validating or blocking proposals. Their common family does not give them identical authority.
The six archetypes are also not a prescription to create six agents for every process. A workflow may need several analysis roles and no outward-facing interface role. The work should determine the responsibilities required. Classification makes those responsibilities easier to describe after the boundaries have been established.
The Analytics Agent (os-agt-005) belongs to intelligence and recommends. The Audit & Lineage Agent (os-agt-008) belongs to observability and is strictly read-only. Investigating an outcome does not give the audit role permission to repair it. These are registry definitions in the architecture, not evidence that every listed agent is deployed.
Put coordination somewhere explicit
Focused agents need a process that connects them. For the incident, something must assign the investigation, recognise a completed result, route the decision, and handle a missing response. Several capable agents do not supply that coordination merely by existing together.
The orchestration layer owns that work in Synedrix OS: it decomposes goals, routes tasks, manages sequencing, and coordinates approvals and recovery. Agents return structured outcomes from their assignments, allowing the surrounding process to decide the next step.
The division also matters when the investigation cannot reach a supported recommendation. The agent needs to report that result, with the evidence and uncertainty preserved. The workflow can then route the unresolved issue to an appropriate person instead of interpreting a completed response as a completed incident.
There is a cost to maintaining these handoffs. Contracts need versioning, tasks may wait on dependencies, and failures between invocations need a defined response. More calls can also add time and expense.
Suppose the investigation completes, but the repair tool cannot confirm its result. The successful assessment and the uncertain action need different records and different next steps. Preserving that distinction allows the process to investigate the external result without asking the investigation agent to reconstruct and repeat the entire incident response. The design needs to justify those boundaries through clearer control, testing, or ownership.
The previous post, Orchestration as the center of gravity, explains why this coordination has an explicit owner. Keeping it there helps prevent every agent from accumulating its own assumptions about the whole process.
Choose boundaries that the work can justify
A single agent can be suitable for one bounded task. An investigation role with a clear output and restricted tools is already specialised, even if it performs several internal steps. Splitting it further only helps when there is a meaningful difference in responsibility, permission, testing, or change ownership.
The problem with a mega-agent is that these differences become difficult to distinguish within one broad assignment. The case for narrower roles is strongest when consequential actions, independent checks, or separate owners are involved. It should be assessed through the actual process rather than treated as a universal performance benchmark.
For the incident, follow the proposed repair from evidence to recommendation, control, execution, and review. Check whether each transition preserves the facts and conditions the next role needs. That gives the team a practical basis for deciding whether the boundaries are useful.
The next post, The 12 layers of Synedrix OS: a complete mental model, places those responsibilities in the wider architecture, including the services that define, run, govern, and observe the agents.
Related reading
- Orchestration as the center of gravity — explains where the coordination between focused roles belongs.
- Next in the series: The 12 layers of Synedrix OS: a complete mental model — locates role definition, runtime execution, control, and evidence in the wider architecture.
Documentation
- Agent Spec: the agent mission, contracts, permissions, and role in a workflow.
- Agent Registry Spec: the registry design and six functional archetypes.
- Agent Registry: the current OS agent definitions, families, permissions, and decision scopes.
Synedrix OS — specialised agent
