Imagine a procurement workflow that reacts to a late delivery by ordering the same parts from a more expensive supplier. The order is sensible and the production line keeps running. Three weeks later, finance asks a plain question: which agent placed this order, under what authority, and was that authority ever formally granted? The team finds the tool call in a log. The agent's prompt has been rewritten twice since the order, and neither version mentions spending limits. Nobody can show what the agent was allowed to do on the day it acted. This scenario is illustrative, but the gap it describes is the usual result when permissions live in prompt text.
The decision may well have been right. The problem is that the permission was a sentence in a prompt, and prompts are edited, tuned and replaced as a matter of routine. An authority boundary is the limit on what an agent may do, declared in a versioned record that the platform reads, so the limit can be enforced and inspected later. An agent without one resembles an employee with no job description and unrestricted system access: the work may be good, and nobody can say whether it was theirs to do.
Synedrix OS is in active development. This article describes the authority model its agent definitions declare and what an implementation has to enforce, because a declared boundary only becomes a guarantee where the runtime checks it.
Why can't a prompt hold the boundary?
A prompt tells a model how to behave. It can say that the agent must never spend above a set amount, but that sentence is a request to the model, and the platform has nothing to compare an actual tool call against. It also cannot be queried. If a compliance officer asks which agents are able to trigger payments, the only way to answer from prompts is to read every one of them and interpret the wording.
Prompts also change for good reasons. Someone tightens the tone, adds an example, or adjusts the instructions after a poor answer, and the permission model shifts with the text without anyone intending it or recording it. Behaviour and authority have different owners and different review processes, so they should not share a text field.
This is the reasoning behind Principle 1 (Bounded autonomy). Every agent has an explicit authority envelope, and its boundaries are machine-readable and enforced by the platform, not implicit in prompt text. A structured definition can be validated before use, compared between versions and checked at the point where an action would take effect. A paragraph of instructions supports none of those.
What are the three decision scopes?
The first declaration in an agent's authority is its decision scope, the class of decision the agent is authorised to make. There are three: recommend, approve and execute. They describe what the agent may do in production, and they carry no stylistic meaning.
A recommend-scope agent may propose actions and nothing more. The Analytics Agent (os-agt-005) is the clearest example. It reads broadly and writes reports, and it does not act on what it finds. Writing to its own report records does not count as execution, because the registry counts execution only as a change of state in another system. A store that another agent reads as an input to a decision is not an agent's own output, since writing to it changes what that other agent decides. That reading stops an agent from reaching into a shared store and describing the write as a report.
An approve-scope agent sits between a proposal and its effects. The Policy Guard Agent (os-agt-002) evaluates a proposed action and returns a binding allow, block or escalate decision. It never carries out the business action, so the component that judges a proposal is never the one that benefits from approving it. It is also designed to fail closed: when its rule engine is unavailable, it blocks and escalates instead of allowing.
An execute-scope agent may trigger side effects, so its definition carries the most obligations. Even here the scope is narrower than the name suggests. The Orchestrator Agent (os-agt-001) can invoke agents, trigger workflows and move task states, yet it routes and sequences work and leaves domain side effects to specialist agents through governed invocation. The Memory Curator Agent (os-agt-010) is the only agent permitted to commit durable memory records, which names one specific effect and grants no general write access.
Across the twelve OS agents, seven have recommend scope, three have approve scope and two have execute scope. Most of the platform's own agents propose or judge, and only two can change state elsewhere.
What does an authority profile contain?
The scope is the headline, and the profile supplies the detail. The Agent Spec defines an authority section with five permission flags, can_recommend, can_draft, can_execute, can_approve and can_delegate, together with a risk tier, approval requirements and an escalation path. The registry adds a governance class. Each of these is a control the platform can read, which is what separates them from configuration preferences.
The flags say which kinds of act the agent may perform. Drafting is separate from executing, so an agent can prepare a purchase order without being able to submit it. Delegation is separate again, which is why the Orchestrator Agent (os-agt-001) carries can_delegate while the specialist that finally acts carries can_execute. The risk tier, one of low, medium, high or critical, sets how demanding the obligations around the agent are. The governance class says whether its tasks may run unattended (autonomous), need a policy check first (policy-gated) or need a human decision (hitl-required). The approval requirements and the escalation path say who must agree before the agent acts and who receives the case when it cannot proceed.
The definition of the Policy Guard Agent (os-agt-002) shows how this reads for a gate agent. Only can_approve is true, its risk tier is critical, and its escalation path runs to the HITL Gateway Agent (os-agt-004) and then to a human risk owner. A reviewer can see from the record alone that this agent can decide and cannot act, without opening its prompt.
How do the scopes work together on one task?
Return to the late delivery and suppose the workflow runs under these definitions. An agent with recommend scope establishes that the alternative supplier meets the delivery date and reports the price difference. The proposal to place the order goes to the Policy Guard Agent (os-agt-002), which checks it against the active rules and either allows it, blocks it or sends it to a person through the HITL Gateway Agent (os-agt-004). On an allow, the Orchestrator Agent (os-agt-001) delegates to a procurement specialist whose execute scope covers placing orders with approved suppliers within declared limits, and nothing beyond that. The recommending agent and the procurement specialist are hypothetical, while the Orchestrator Agent (os-agt-001), Policy Guard Agent (os-agt-002) and HITL Gateway Agent (os-agt-004) are OS agents. The previous post, Governance before execution: why policy is an OS primitive, follows the decision of the Policy Guard Agent (os-agt-002) in detail.
Three weeks later, the finance question becomes a lookup instead of an investigation. The order record names the specialist and the version of its definition that ran. That version has an authority profile showing what the agent could execute. The decision of the Policy Guard Agent (os-agt-002) shares a correlation ID with the proposal, so the permission and the action can be connected. Nobody has to interpret a prompt to learn what the agent was allowed to do. Whether a given implementation produces every one of those records is something to verify in its runtime, and it is the property the design is meant to make checkable.
Why does the boundary have to be versioned?
Authority changes. A risk tier is reassessed after an incident, an agent gains an execution scope because a workflow needs it, or a scope is withdrawn. Each change alters what the same agent is allowed to do, and an audit asks what applied at the time, not what applies now. Each agent definition in the registry carries a semantic version, the data model stores the authority profile against that version, and invocation records name the agent and the version that ran. Together these let a reviewer ask which agent, holding which authority, at which version, ran a given invocation.
The General Chat Agent (os-agt-009) shows why change control matters. It has recommend scope: it retrieves and answers, cites sources and writes to no system of record. Because it is invoked directly from its web interface into its own graph, its calls do not pass through the n8n layer that normally carries the governance bridge. That is compliant only while its scope remains recommend and no write-capable tool is bound to it. Adding such a tool would mean routing the agent through the Orchestrator Agent (os-agt-001), or building an equivalent policy and human-approval call into the graph before the tool is enabled. A change that looks like adding one tool is a change of authority, and the definition is where it has to be recorded and reviewed.
What does a declared boundary not guarantee?
A boundary in a definition is a design contract, and whether it holds depends on enforcement where effects occur. Tool bindings have to limit which tools an agent can call, policy gates have to sit on every route that can produce a side effect, and tests should attempt the actions an agent is not allowed to take and expect them to fail. Declaring a permission differs from enforcing it, and a recorded declaration only shows what was intended.
Two further limits apply. Scope bounds what an agent can do, and it cannot make a recommendation correct: a recommend-scope agent can still be wrong, and the boundary keeps that error from taking effect without a decision. The declarations for the twelve OS agents are also still being confirmed by their owners, so the published catalogue should be read as the current declared position, and not as a completed audit.
A team can apply the same model before adopting any platform. List the agents in a system, give each one a scope, write down the tools and systems it may touch, and then ask the three-week question about one real decision: which agent acted, under what authority, at which version? If answering means reading prompts, the boundary is not yet where it belongs.
Related reading
- Governance before execution: why policy is an OS primitive — the previous post, which follows a single proposal through the Policy Guard's allow, block and escalate decision.
- Why specialized agents beat mega-agents every time — explains why one mission and one set of permissions per agent makes each authority boundary short enough to review.
- The 12 principles that make agentic systems trustworthy — introduces Principle 1 (Bounded autonomy), the principle this post turns into declared fields.
Documentation
- Agent Spec: the authority section, with its worked example for the Policy Guard Agent.
- Agent Registry Spec: the registry fields, including decision scope, risk tier and governance class.
- Synedrix OS - Agent Registry: the current OS agent definitions, with each agent's decision scope and authority boundary.
Synedrix OS — authority boundary
