An operational incident can involve several kinds of work. Someone describes the problem, a process assigns an investigation, an agent assesses the evidence, and an approved action reaches the affected system. Afterwards, the organisation needs a record that connects those steps. Each responsibility needs an owner, even when several share the same infrastructure.
The 12-layer architecture of Synedrix OS, the governed operating layer for agentic business systems, provides that ownership map. Each layer has a purpose, responsibilities, interfaces with other layers, and explicit exclusions. The model helps a team decide where a capability belongs and identify a boundary that a design may cross.
The boundaries become useful when applied to real work and checked in the implementation. Writing down an exclusion does not automatically detect or prevent every violation. The platform is in active development; the layers below describe the architecture and the responsibilities an implementation must preserve.
The layers are grouped into five slices to make the map easier to read. These groups do not add layers or require a separate service for each box. The useful test concerns ownership and interfaces: which part defines a responsibility, which parts use it, and how their boundaries are maintained when the underlying components are deployed together.
Human and intent surface: Layers 1 and 2
Layer 1: Human Interface Layer
This layer captures requests, approvals, and operational review through interfaces such as dashboards, operator APIs, and command surfaces. In an illustrative incident, it gives a person a way to describe the problem or review a proposed response.
The interface must not become the owner of domain execution, tool adapters, or memory internals. A button can express a person's decision while the controlled execution path still applies the checks needed to carry it out. Putting a repair directly behind a screen does not settle those responsibilities.
Layer 2: Goal & Intent Layer
This layer translates the objective into a structured intent. The incident request needs a clear desired outcome and constraints, rather than an instruction so broad that every participant must invent its meaning. Goal definitions, playbooks, and targets belong here.
Domain-specific execution and raw tool calls belong elsewhere. Defining a goal to investigate a service problem should not quietly authorise every repair an agent might suggest. The objective needs to remain connected to the limits and completion conditions that make the work acceptable.
Orchestration core: Layers 3 to 5
Layer 3: Orchestration Layer
The orchestration layer coordinates the work: decomposing goals, assigning tasks, sequencing dependencies, managing retries, and routing approvals or escalations. It owns the process for moving an incident from investigation to the next appropriate decision.
Its exclusions include domain-specific heuristics and long-lived memory management. The coordination mechanism can request an assessment without owning the business reasoning that makes one repair preferable. It must also retain a defined response to failed or uncertain work rather than assume that every completed invocation resolves the goal.
Layer 4: Agent Runtime Layer
The runtime executes an agent's assignment within its declared scope. It manages invocation context, execution state, lifecycle, and communication patterns. The investigator can perform the reasoning needed for its task while the surrounding workflow retains the business sequence.
The runtime does not own interface concerns or business-specific workflow routing. The architecture maps agent reasoning that carries evolving state across repeated steps to LangGraph, invoked as a governed step by the workflow. Execution of that reasoning and ownership of the wider incident process remain distinguishable.
Layer 5: Agent Registry Layer
The registry defines discoverable capabilities and their boundaries. Agent metadata, permissions, contracts, status, and versions make it possible to identify an eligible role for a task. For the investigation, the process needs to establish which capability is being invoked and under which definition.
The registry does not execute the agent or own domain workflows. A declared permission must still be enforced when the role is used. The distinction lets a reviewer compare the definition with the actual invocation instead of treating registration as proof of compliant behaviour.
Infrastructure services: Layers 6 to 8
Layer 6: Tool Abstraction Layer
This layer normalises access to external systems through adapters and tool contracts. It carries the connection between a permitted operation and the system that receives it, including scopes and retry handling.
Domain decision logic and policies remain outside the adapter. A tool that can restart a service should not decide whether that restart is the right response to the incident. It also needs a declared recovery behaviour: an unknown external result cannot safely be treated as a failed operation that may always be repeated.
Layer 7: Memory & Data Layer
This layer persists business state and contextual knowledge and governs how memory is formed, recalled, maintained, and erased. It includes authoritative records, temporary state, retrieval stores, and the controls that connect them to their sources and permitted uses.
The boundaries matter across several layers. Workflow sequencing stays with coordination. The company's configured business instance supplies retention values, while the runtime assembles the context for a particular invocation. The shared memory layer must preserve the controls on obtaining that context rather than making every stored record available to every agent.
Layer 8: Event Layer
The event layer standardises production, transport, and consumption of events. A common format, the event envelope, carries the information needed to connect a signal to the relevant work and its causes. An incident report, approval, or completed action can then participate in a traceable sequence.
The layer does not own domain-specific policy decisions. Receiving a message that says an action was approved is not sufficient to authorise a different proposal. The process must establish which work the event concerns and apply the relevant checks before using it to move forward.
Governance and observability: Layers 9 and 10
Layer 9: Governance & Controls Layer
This layer enforces policies, permissions, approvals, and authority checks. For the incident, it determines whether the proposed action satisfies the applicable controls and whether a further human decision is required. The action itself belongs to the role and tool path permitted to execute it.
Keeping these responsibilities separate supports Principle 4 (Governance before execution). A control that appears only in a retrospective report cannot provide the required pre-action check. The execution path must establish that the actual proposal has passed the relevant controls before allowing its effects.
Layer 10: Observability Layer
This layer makes execution measurable, explainable, and reviewable through logs, traces, metrics, run health, lineage, and alerts. It supports an account of the incident that connects the evidence, recommendation, decision, and external action.
Observability does not take ownership of business decisions or authoritative domain state. A trace, the execution record describing a submitted repair, is not a replacement for the target system's record of what happened. A useful review compares the connected evidence and identifies gaps instead of inventing an explanation for missing information.
Domain and runtime config: Layers 11 and 12
Layer 11: Domain Pack Layer
The pack supplies the business-specific entities, tasks, agents, events, rules, measures, and tool mappings. In the incident example, operational knowledge determines what the affected service means and which response is appropriate to assess.
The pack uses shared platform services through their contracts. It must not redefine common coordination or bypass governance and observability. That boundary keeps a business-specific method separate from the common mechanisms used to control and record its execution.
Layer 12: Business Instance Layer
The business instance configures a concrete runtime with the platform and selected packs. Credentials, thresholds, approver assignments, environment settings, deployment mode, and pinned pack versions belong here. These values determine how this organisation uses the available capabilities.
The instance must not redefine shared platform abstractions. A company-specific requirement needs to fit declared configuration or an appropriate governed extension; it cannot silently create a second approval or execution model. Likewise, adopting a different pack version requires an explicit choice rather than an implicit update from its publisher.
Map the tools without confusing them with the layers
A layer defines a responsibility. A named product is one component assigned to help implement it. The architecture maps n8n to orchestration and LangGraph to the agent runtime. The split keeps workflow sequencing separate from stateful agent reasoning while preserving the controls around the invocation.
Layer 7 uses Redis for temporary state, Supabase Postgres for authoritative relational records, QuestDB for time-series data, Neo4j for graph relationships, and Qdrant for retrieval indexes. These are distinct storage roles within one layer, rather than five extra architectural layers.
Hookdeck and Hookdeck Outpost map to event ingress and egress. Langfuse, PostHog, and Grafana LGTM map to model-related evidence, behavioural analytics, and operational monitoring in Layer 10. Selecting those tools does not itself demonstrate that permissions, records, or handoffs are correct. Those properties still need implementation and verification.
Use a boundary question on the next change
Suppose the incident process needs a new rule for selecting a repair. The domain pack owns the business reasoning. If it needs a company-specific threshold, the instance supplies the permitted value. The shared governance mechanism applies the relevant control, while the tool adapter carries the allowed action to its destination.
The relationship between Layers 3 and 11 illustrates this distinction. A pack contributes the domain workflow and its business requirements. The common coordination mechanism sequences and gates that workflow without taking over its domain reasoning. Changing the method used to investigate one kind of incident should not require putting that incident-specific knowledge into the shared engine. Both layers participate, while the ownership of each responsibility remains explicit.
This also helps during review. The team can examine the business method, company setting, common control, and tool operation separately, then check how their results fit together. A failure at a handoff still needs investigation even if each individual component satisfies its local contract.
One capability can use several layers without giving any layer all of its responsibilities. A proposal that cannot identify those owners needs further design. The map makes that uncertainty easier to locate; it does not remove the need for judgment about the appropriate boundary.
The previous post, Why specialized agents beat mega-agents every time, explains why the actors need clear roles. The next post, Memory isn't a bucket: how Synedrix OS separates kinds of truth, examines Layer 7's information and memory controls in greater depth.
Related reading
- Why specialized agents beat mega-agents every time — explains the bounded roles the runtime and registry need to support.
- Next in the series: Memory isn't a bucket: how Synedrix OS separates kinds of truth — develops Layer 7's records, retrieval, and memory controls.
Documentation
- Layer Taxonomy Table: the authoritative responsibilities, interfaces, exclusions, five slices, and platform mappings.
- Taxonomy & Platform Spec: the shared platform, business packages, and configured instances.
- Responsibility Matrix: ownership of common mechanisms and business-specific values.
Synedrix OS — 12-layer architecture
