When several teams introduce agents into business work, each team quickly meets similar questions. What may an agent change? Who approves the action? Which information may it read? If the work fails halfway through, who decides what happens next? Answering these questions separately in every project creates another coordination problem for the organisation.
Synedrix OS is the governed operating layer for agentic business systems. Here, agentic business systems means software in which agents carry out defined business tasks, using tools and information under rules the organisation sets. The platform architecture supplies common ways to coordinate that work, control actions, share context, and retain evidence of the result.
The business-specific work changes; the responsibilities for coordinating and controlling it remain explicit. Synedrix OS is in active development. The account below explains the architecture and what an implementation must establish. It does not claim that describing a control proves it is already enforced in a running system.
What the operating layer is responsible for
Consider an illustrative customer refund. An agent might examine the request and recommend an amount. Another task checks whether the proposal meets the applicable rules. The final action updates the order and initiates the refund only after the required conditions have been met.
The refund rules belong to the business capability. The system around those rules must organise the work, establish what each participant is allowed to do, and preserve the connection between the recommendation, decision, and action. These responsibilities also appear in very different work, such as reviewing a supplier or handling an operational incident.
Synedrix OS separates those common responsibilities from the logic of an individual business area. It defines how a goal becomes tasks, how agents are selected and run, how tools are accessed, and how progress and outcomes are recorded. It also defines where permissions and approvals must be checked.
This is the reason for calling it an operating layer. A team using a common platform should not need to invent a separate meaning of approved, failed, or complete for every agent project. The common design gives those projects a way to work together while retaining the details that make their business tasks different.
That separation needs to be maintained deliberately. A convenient shortcut that puts refund rules into a shared control would make that control harder to reuse elsewhere. A separate approval implementation hidden inside each refund agent would make consistent control harder to establish. The architecture assigns responsibility so these choices can be examined.
Give each agent a defined role
An agent in Synedrix OS is a software actor with a declared task and limits. Its definition identifies what it receives, what it returns, which tools and information it may use, and where it must send a problem it cannot resolve. Those declarations make its role available to the surrounding process.
For the refund example, assessing a request and committing a refund are different jobs. A recommendation can include the proposed amount and supporting evidence. The permission to produce that recommendation should not silently include permission to send money. The process needs to preserve the distinction when it selects and runs the agent.
The platform's agent registry holds these definitions, including their status and version. That makes it possible to identify which agent was selected for a task and what it was permitted to do. A registered definition still needs enforcement at the point of use; recording a permission is only part of providing a working control.
Clear responsibility makes an agent's result easier to test and a failure easier to locate. If the recommendation is wrong, its inputs and assessment can be reviewed. If the recommendation is right but the committed amount differs, the investigation needs to follow the later action. Giving one agent every responsibility would make those distinctions harder to maintain.
An agent can change as the system develops. A new model or revised implementation may produce better recommendations, but it still needs to satisfy the role's requirements. A compatible output format alone does not establish that its behaviour is suitable. The checks must include the quality of its decisions and their consequences for later work.
Check the action before it happens
The word governed describes a requirement about execution. Before an action proceeds, the system needs to establish whether it is allowed and whether further approval is required. A prompt asking an agent to be careful cannot replace a check on the action it is about to take.
In the refund example, the relevant checks may depend on the request, proposed amount, permissions, and business configuration. An approval must relate to that proposal. If the amount changes after approval, the process needs to establish whether the earlier decision still applies before proceeding.
The architecture separates applying those controls from carrying out the business task. Agents operate within declared permissions. Tool access is mediated, so the connection to an external system is part of the controlled process. Business-specific rules supply the relevant conditions without giving an individual agent permission to bypass the common checks.
People retain responsibility for setting the goals and limits and making decisions that require their judgment. A request beyond the system's permitted scope must reach an appropriate person with enough context to decide. This is a practical form of human control: the decision has an owner, a defined place in the process, and an effect on what may happen next.
The design must also account for failures. A refund request sent without a confirmation cannot simply be assumed to have failed. The implementation needs to check the external result and follow the defined recovery or escalation path. Repeating an uncertain action without that check can create a second effect instead of completing the first.
Share context with access limits
The refund assessment needs relevant order details and perhaps earlier customer interactions. The approval step needs the recommendation and evidence supporting it. The execution step needs an authorised instruction tied to the correct order and amount. Each task needs usable context, with access limited to what its role permits.
Synedrix OS treats shared information and its controls as a common responsibility. Business records, temporary work, and evidence of decisions have different purposes. An agent should be able to establish which record is authoritative and where a claim came from, rather than treating every piece of retrieved text as equally reliable.
Sharing does not mean giving every agent access to every customer. Restrictions must apply when the information is requested and returned. A broad conversation containing data outside the task's scope would already cross the boundary, even if the agent were later told to ignore those parts.
The result of one task also needs to be understandable by the next. A summary saying the refund was approved is insufficient if the approval applied to a different amount. Shared context needs to retain the proposal, decision, and conditions well enough for the next participant to use them correctly.
The implementation has to preserve those connections as information changes. A corrected order record should not erase the evidence needed to understand an earlier decision. Keeping a useful history is part of making later review possible, while access and retention rules still govern who may see that history.
Let business areas contribute their own logic
A domain pack is a package of business-specific capabilities that runs on the common platform. It supplies the relevant information model, events, agents, tools, rules, and workflows for its area. Commerce and Finance can therefore use shared controls while expressing different business work.
The domain pack does not get to redefine the platform's governance or bypass its records. Its business rules participate in the common execution process. That gives the organisation a consistent way to ask whether an action was authorised, while allowing the conditions for a refund to differ from those for an invoice or an operational change.
A business instance combines the platform and the selected packs for a particular company, team, or unit. Configuration such as approval thresholds and environment settings belongs there. This keeps a company's choices separate from the reusable business capability and from the common platform services.
The refund illustrates the split. The platform provides controlled execution and traceability. The relevant pack supplies the refund-related business rules and tasks. The company's configuration determines the applicable settings. Understanding which part owns a behaviour makes it easier to change the right thing and assess the effects of that change.
Shared infrastructure still creates dependencies. A revised common control needs testing across the business capabilities that use it. A new pack version needs review before a running instance adopts it. Reusability can reduce duplicate machinery, but it does not remove the obligation to manage changes deliberately.
Make trust something that can be examined
The final refund record should be connected to the request, recommendation, approval, and action that produced it. That evidence helps establish whether the right process was followed and where a correction belongs if the outcome is wrong.
This is the practical meaning of trust in the platform's design. A useful result matters, and so does the ability to establish how it was reached, what limits applied, and who authorised the consequential action. A model's explanation is one piece of evidence; the surrounding records must support the account.
Synedrix OS gives these requirements named responsibilities so teams can implement and test them. The architecture is a basis for that work, rather than evidence that every requirement has been met. A meaningful assessment must follow a real request through its checks, including failures and requests outside the permitted scope.
For a team considering this approach, the starting point is one business capability whose coordination is understood well enough to examine. Identify the common controls it needs and the business logic it must retain. The next post, One substrate, many domains: the domain pack model, develops that boundary: what belongs in the shared platform, what belongs in a pack, and what a company configures for its own use.
Related reading
- From static workflows to agentic operating systems — explains the category and the five broad capabilities the platform must connect.
- Next in the series: One substrate, many domains: the domain pack model — examines what the common platform, business package, and company configuration each own.
Documentation
- Taxonomy & Platform Spec: the definitions and responsibilities of the platform, domain pack, and business instance.
- Core Principles: the requirements for control, human oversight, shared context, and accountability.
Synedrix OS — governed operating layer
