Most architecture diagrams answer a single question: what exists, and how is it wired together. They are maps of boxes and arrows. Read one and you know which component calls which, where the data flows, and what talks to the outside world. What you cannot read from it is the thing that actually keeps a system coherent over years rather than weeks: what each component is forbidden to do.
The layer model of Synedrix OS, the governed operating layer for agentic business systems, is built the other way around. It defines 12 layers, and for each one it states two things with equal weight: what the layer owns, and what it must not own. The exclusions are not footnotes to the design. They are the load-bearing part of it. A layer doing something it was never meant to own is not an edge case to be argued over in review. It is a fault, and because the boundary was written down, it is a fault you can see.
That distinction matters more here than in ordinary software, because the components are not only code. They are agents with authority, memory they may read, tools they may call, and policies that bind them. This is a multi-agent system, meaning many specialised agents collaborate under orchestration rather than one program running top to bottom. When responsibilities blur between layers in a system like that, the cost is not just a tangled codebase. It is an agent acting with authority that belongs to a different layer entirely. The 12-layer architecture is how the OS makes that blurring structurally hard instead of merely discouraged.
The twelve layers fall into four horizontal slices. Reading them as slices is the fastest way to hold the whole model in your head.
Intent capture: layers 1 and 2
The Human Interface Layer captures human intent, approvals, and operational review through dashboards, admin panels, and approval surfaces. It must not own domain logic or reach into memory internals; it is where people meet the system, nothing more.
The Goal & Intent Layer translates business objectives into structured intents the rest of the platform can act on. It holds goal schemas, playbooks, and KPI targets. It must not execute domain logic or call tools directly. Its job is to state what is wanted, not to do it.
Execution: layers 3, 4, and 5
The Orchestration Layer routes work, decomposes goals into tasks, sequences them, manages retries and timeouts, and inserts approval checkpoints. It must not own domain-specific heuristics or long-lived memory. This is Principle 2 (Orchestration is the center of gravity) expressed as a layer: the coordination logic lives here and stays stable while the agents and models above it change.
Giampiero Bonifazi
The Agent Runtime Layer executes agents within their bounded scope and manages the lifecycle of each invocation. It must not own UI concerns or decide business-specific routing. It runs agents; it does not decide which agent should run.
The Agent Registry Layer defines which agents exist, what each is permitted to do, and what lifecycle stage it is in. It must not run workflows or execute anything itself. It is the catalogue the orchestrator consults, not a participant in the work.
State and governance: layers 6 through 10
The Tool Abstraction Layer mediates every call an agent makes to an external system through a uniform adapter. Agents reach the outside world only through this layer, never directly. It must not own business decision logic, human interface concerns, or domain policies.
The Memory & Data Layer persists business state and contextual knowledge across the platform’s stores. It must not sequence workflows or hold UI logic. Treated as one box here, it is in fact several specialised stores, which is the subject of the next post.
The Event Layer standardises how events are produced, transported, and consumed. An event is a fact about something that happened, carried in a common envelope with correlation identity so its place in a larger journey is never lost. This layer must not own domain policy.
The Governance & Controls Layer enforces policy, approvals, authority checks, and risk thresholds before actions proceed, with the Policy Guard Agent as its runtime enforcer. It must not own domain execution logic. Governance here is infrastructure on the execution path, not a review step bolted on afterward.
The Observability Layer makes execution measurable and explainable through logs, traces, metrics, and decision lineage. It must not own business decisions or domain state. It records what happened; it never decides what happens.
Domain and configuration: layers 11 and 12
The Domain Pack Layer injects everything specific to one business domain: its entities, events, specialist agents, workflows, tool mappings, and policies. It must not redefine the shared OS primitives it runs on.
The Business Instance Layer configures one concrete deployment with its credentials, thresholds, enabled packs, and environment settings. It must not own shared platform abstractions. It tunes the system for a tenant; it does not change the system.
Why the exclusions carry the weight
The inclusions tell you where to build something. The exclusions tell you when you have built it in the wrong place, and that is the harder and more valuable signal. An Orchestration Layer that starts encoding domain-specific heuristics has quietly become a monolith with better marketing. A Tool Abstraction Layer that starts making business decisions has coupled the platform to logic that should have lived in a domain pack. A Domain Pack Layer that redefines core orchestration primitives has broken the one property the whole model exists to protect.
That property is Principle 9 (One substrate, many domains). The reason the domain pack and business instance layers are separated from the ten below them is so the OS core stays domain-agnostic, governing Trading, Commerce, and Ops with the same orchestration, the same governance, and the same observability. Collapse that boundary and you lose the substrate. Keep it, and a new domain inherits the operating layer instead of rebuilding it. The exclusions are how that boundary is enforced rather than merely intended.
Giampiero Bonifazi
The model is not abstract
Each layer maps to real infrastructure, which is what keeps this a mental model rather than a wall poster. Orchestration runs on n8n; complex stateful and multi-agent reasoning runs in LangGraph, which n8n invokes as a governed step. The Memory & Data layer is not one database but a set of specialised stores: Redis, Supabase, QuestDB, Neo4j, and Qdrant, each answering a different kind of question. Governance runs on a policy engine in Supabase, enforced at runtime by the Policy Guard Agent. Observability runs on Langfuse, PostHog, and the Grafana stack. Events enter through Hookdeck and leave through Hookdeck Outpost, so the orchestration layer never exposes a raw webhook to the public internet. The layers are where responsibilities live; the platforms are how they are met.
How to actually use it
The model earns its keep as a decision tool. When a new capability arrives and you are unsure where it belongs, ask two questions. Which layer owns this? And which layer’s exclusions would it violate? If the answer to the first is clean, build it there. If the capability seems to want a home in two layers at once, it is straddling a boundary, and that straddle is the design decision to resolve before any code is written. The layer that a thing tries to violate is usually the layer telling you the thing is two things wearing one name.
The Memory & Data layer was a single box in this map, and it should not have been. The next post opens that box and shows why a system that conflates seven kinds of truth into one store has made a governance mistake long before it has made a performance one.
Synedrix OS is in active development. If you are interested in co-founding or investing, the door is open.
Related reading
Orchestration as the center of gravity — the Orchestration Layer is Principle 2 expressed structurally; that post is why it owns coordination and nothing else.
Why specialized agents beat mega-agents every time — the Agent Runtime and Agent Registry layers are where those specialised agents actually live, run, and are governed.
Next in the series: Memory isn’t a bucket — Post 10 opens the Memory & Data layer into its seven specialised stores and shows why the separation is a governance requirement.
Synedrix OS — 12-layer architecture
