A useful result is only part of the evidence a business needs before letting an agent act. The organisation also needs to know what the agent was permitted to do, which information it used, who approved the consequential decision, and what happened if the action failed. A successful demonstration can leave each of those questions open.
The 12 core principles of Synedrix OS, the governed operating layer for agentic business systems, set requirements for answering them. They cover safety, architecture, human control, accountability, and the common platform. Their purpose is to make the conditions around execution explicit enough to implement, test, and examine afterwards.
The principles describe what the system must establish; stating them does not prove the controls work. Synedrix OS is in active development. The explanations below describe the architecture and the evidence an implementation needs, including the limits of the claims it can make.
Safety: what an agent may do and see
Principle 1 (Bounded autonomy)
An agent needs explicit limits on its actions, access, and responsibility. It may be allowed to recommend a purchase while another part of the process owns approval and execution. The permitted actions must be checked by the system, rather than left only in instructions asking the agent to behave carefully.
For an illustrative purchase, a sensible recommendation does not establish permission to place the order. The implementation must identify the agent and proposed action, apply the relevant limits, and provide a route for work beyond them.
A useful test asks what happens when the agent requests a tool outside its permitted set. The control must refuse that request even if the surrounding recommendation is persuasive. This distinguishes a functioning limit from a description that the agent is merely expected to remember. A declared permission must have an enforcement point.
Principle 4 (Governance before execution)
The relevant policies and approvals must be checked before an action proceeds. Reviewing a purchase after submission can identify a problem, but it cannot provide the control that was required before the business committed to it.
An approval also needs to apply to the actual proposal. If the amount or supplier changes, the system must establish whether the earlier answer still permits the action. This makes approval part of the execution process, with a defined effect on what can happen next.
Principle 5 (Shared context with scoped access)
Agents need information relevant to their tasks, with access restricted to what they are permitted to use. Sharing context should let the next participant understand the work without opening every record to every agent.
A purchasing task might need an order and its approval history. That does not establish a need for unrelated customer or employee information. The access check must happen when information is retrieved, so excluded records do not enter the agent's context and rely on later instructions to remain unused.
Architecture: how the work remains manageable
Principle 2 (Orchestration is the center of gravity)
The system needs an explicit owner for coordination: assigning work, managing dependencies, handling failures, and locating the next decision. Models and individual agents can change while these responsibilities remain part of the business process.
For the purchase, a completed comparison needs to reach the correct approval task with usable evidence. Someone must also own a missing response or a failed submission. Keeping that coordination separate from the comparison makes the whole path easier to understand and maintain. A better model can improve the assessment without becoming responsible for every later step.
Principle 3 (Specialised agents over mega-agents)
A narrow role makes it clearer what an agent should receive, return, and be allowed to change. The agent assessing a purchase can be tested against that responsibility. It need not also interpret every approval rule, submit the order, and investigate its own mistakes.
This separation helps locate a failure, but it does not guarantee isolation on its own. Shared tools and excessive permissions can still spread the effect of a mistake. The surrounding controls must preserve the limits declared for each role, and the tasks must be connected through clear inputs and results.
Principle 12 (Deterministic idempotency, explicit state)
Repeating a step must not blindly repeat its effect. An idempotency key identifies the same intended operation so that a target system supporting it can recognise a repeated request. The system also needs recoverable records of the work, rather than depending on information held only in a running process.
If an order submission times out, the outcome may be unknown. Where the tool cannot safely recognise a repeat, the architecture requires reconciliation against the target's record or human escalation, rather than automatic resubmission. This requirement concerns effects and recorded state, not repeatable model answers. A model may phrase or assess something differently on another call.
The key must identify the same intended operation. A new purchase cannot simply reuse an earlier purchase's identity because its contents look similar. Equally, attaching a key to a request provides no guarantee if the external system ignores it. The implementation needs to establish which tools support safe repetition and preserve the actual result, including an unresolved outcome, before deciding what to do next.
Human control: where responsibility remains
Principle 6 (Humans stay above the automation layer)
People define the goals, constraints, policies, and escalation thresholds. They retain responsibility for consequential judgments and decisions outside the system's permitted scope. Agents can carry out work within those limits while the process makes the required human decision reachable.
The useful question is whether the responsible person receives enough information to decide and whether their answer affects execution correctly. A nominal approval screen provides little protection if the action has already happened or the decision is detached from the proposal it was meant to authorise.
Principle 8 (Event-driven execution)
A relevant signal, approval, failure, or callback can start the next work when it arrives. For the purchase, the recorded approval can move the request forward without waiting for someone to discover it in an inbox or manually restart the process.
The system still needs to establish what the signal means and which work it belongs to. Receiving an approval message is not equivalent to authorising any pending order. Duplicate signals also need safe handling, connecting this principle to the requirement that repeated delivery must not create repeated business effects.
Accountability: what the evidence can explain
Principle 7 (Explainability and audit by design)
An outcome must remain connected to the work that produced it: the relevant inputs, agent results, policy decisions, approvals, and external actions. The records should allow a reviewer to establish what happened and under whose authority it happened.
If a purchase is wrong, that connection helps distinguish an inaccurate recommendation from an incorrect submission or a missing approval. Each failure needs a different correction. An explanation must be supported by the recorded process. A model's stated reason is evidence to examine alongside the other records, not a complete account of its internal reasoning. Where records are missing, the review must preserve that uncertainty.
Platform: what is shared and what trust requires
Principle 9 (One substrate, many domains)
Different business capabilities should use common coordination, controls, information services, and execution records. A domain pack contributes the business-specific tasks and rules, while company settings belong to a business instance. The common platform must remain usable without taking ownership of those business rules.
For the purchase, the shared mechanism can route an approval without deciding what makes a supplier acceptable. Keeping that decision with the relevant business capability supports reuse while leaving ownership clear. It also creates shared dependencies that must be tested when the platform changes.
Principle 10 (Trust is the real product)
Trust is the aim the other eleven principles serve. A business needs useful performance together with reliable execution, effective controls, evidence, and retained human responsibility. The result must be good enough to use, and the surrounding process must support the decision to delegate work.
This gives the principles a practical test. If the purchase is completed quickly but the organisation cannot establish who authorised it, speed has not answered the accountability question. If every request stops for unnecessary manual reconstruction, the controls may exist while the coordination still needs improvement.
Principle 11 (Open by default, sovereign by design)
The organisation needs to understand and examine the components it depends on and the infrastructure involved in processing its work. Deployment choices affect those boundaries, including whether model processing uses external services or local infrastructure.
The architecture has a specific qualification: the inbound Hookdeck Event Gateway is a proprietary managed cloud service required in every deployment mode. Incoming event payloads pass through it before delivery. Even the mode named air-gapped retains that declared external dependency. Local model processing must therefore not be presented as proof of a fully disconnected system. The actual dependency and data path need to be part of the deployment assessment.
Code that can be inspected gives the organisation a way to examine the relevant controls. That inspection should be connected to the configuration and data paths used in the deployment. A component's source availability and the location of its processing answer different questions. The system description needs to preserve both, including any managed service on the path.
Evaluate a complete path, including an exception
The principles become useful when applied to one connected piece of work. Follow the purchase from its initial request through recommendation, approval, and submission. Establish what each task could access, which checks occurred, and whether the records identify the version of the proposal that was authorised.
Then examine a failure. A missing approval, an unavailable external system, or an unknown submission result should have a defined response. The aim is to establish that control, recovery, and evidence remain connected when the expected path stops working. A normal successful run alone cannot demonstrate that.
The evidence should also show what remains unresolved. If an external system has not confirmed the order, the outcome must not become successful simply because the agent completed its response. The business needs a record it can use to reconcile the action and decide whether further work is required.
The previous post, One substrate, many domains: the domain pack model, explains where shared and business-specific responsibilities belong. The next post, Orchestration as the center of gravity, examines how coordination connects those responsibilities into work whose progress and outcome can be followed.
Related reading
- One substrate, many domains: the domain pack model — explains how platform constraints are shared without moving business rules into the core.
- Next in the series: Orchestration as the center of gravity — develops the coordination responsibilities behind Principle 2.
Documentation
- Core Principles: the canonical names, groupings, and requirements of all 12 principles.
- Taxonomy & Platform Spec: the definitions and boundaries those principles govern.
Synedrix OS — trust is the real product
