Purpose

Formalizes the canonical architecture layers of Synedrix OS and defines the owned responsibilities, interfaces, and exclusions for each layer.

Layer taxonomy

The 12 canonical layers of Synedrix OS, what each one owns, and the boundary it must not cross.

LayerPrimary purposeOwnsInterfaces withMust not own
Human Interface LayerCapture human intent, approvals, and operational reviewDashboards, admin panels, operator APIs, approval surfaces, command UIsOrchestration, observability, governanceDomain logic execution, tool adapters, memory internals
Goal & Intent LayerTranslate business objectives into structured intentsGoal schema, objective definitions, playbooks, KPI targetsHuman interface, orchestration, governanceDomain-specific execution logic, raw tool calls
Orchestration LayerRoute work, decompose goals, sequence tasks, manage retries and approvalsWorkflow router, execution planner, task graph, retry logic, escalation rulesAgent runtime, governance, observability, event busDomain-specific heuristics, long-lived memory management
Agent Runtime LayerExecute agents with bounded scope and lifecycle managementAgent lifecycle, invocation context, execution state, communication patternsOrchestration, memory, tools, observabilityUI concerns, business-specific workflow routing
Agent Registry LayerDefine discoverable capabilities and boundariesAgent metadata, permissions, contract references, lifecycle status, versioningOrchestration, governance, runtimeDomain workflows, runtime execution itself
Tool Abstraction LayerNormalize access to external systemsAdapters, tool contracts, permission scopes, retriesAgent runtime, governance, observabilityDomain decision logic, human interface concerns, Domain-specific policies
Memory & Data LayerPersist business state and contextual knowledge, and govern how it is formed, recalled and forgottenTransactional DBs, vector stores, graph stores, caches, audit state; the memory control plane — tier taxonomy, record lifecycle, recall mediation, promotion, decay and erasureAgent runtime, orchestration, governance, analyticsWorkflow sequencing, UI logic, retention policy (Layer 12 sets the values), context assembly for a specific run (Layer 4)
Event LayerStandardize event production, transport, and consumptionEvent envelope, routing metadata, correlation IDs, schemasOrchestration, memory, observability, domain packsDomain-specific policy logic
Governance & Controls LayerEnforce policy, permissions, approvals, complianceApproval engine, policy rules, authority checks, risk thresholds, audit controlsHuman interfaces, orchestration, registry, toolsDomain execution logic itself
Observability LayerMake execution measurable, explainable, reviewableLogs, traces, metrics, run health, decision lineage, alertsAll other layersBusiness decisions, domain state ownership
Domain Pack LayerInject domain-specific entities, workflows, agents, toolsDomain entities, events, specialist agents, policies, KPIs, tool mappingsOS layers through defined contractsShared OS primitives
Business Instance LayerConfigure a concrete runtimeTenant config, credentials, thresholds, pack selection, environment settings, deployment_mode, domain_pack_version pin, Capability Module entitlement flags, active Business Instance Extension (BIE) versionOS + selected domain packsShared platform abstractions

Layer principles

1. Shared before specific

If a concern can be reused across domains, it belongs in a shared OS layer rather than in a domain pack.

2. Controls before execution

Execution paths must pass through governance and observability instead of bypassing them for convenience.

3. Tools are adapters, not business logic

External systems must be accessed through normalized adapters so domain packs do not become tightly coupled to vendor APIs.

4. Memory is shared, access is scoped

Agents need shared context to collaborate effectively, but memory access must remain selective and policy-aware.

5. Memory moves only under governance

Persisting a fact and deciding it is worth remembering are different acts. A record crosses a memory tier, is recalled into an agent’s context, or is erased only through a governed path that leaves lineage behind. See Memory Fabric Spec.

Ownership guidance

  • If it changes how all domains orchestrate, govern, observe, or communicate → Synedrix OS.
  • If it changes how one business domain reasons or executes → domain pack.
  • If it changes thresholds, credentials, or instance-specific behavior → business instance.

Stack topology

SliceLayersDescription
Human and intent surface1, 2Human operators, goal capture, KPI targets
Orchestration core3, 4, 5Workflow routing, agent execution, registry
Infrastructure services6, 7, 8Tool adapters, memory, event bus
Governance and observability9, 10Policy, approvals, logs, traces, metrics
Domain and runtime config11, 12Domain-pack injection and tenant configuration

The twelve layers stacked in their five slices:

flowchart TB
    subgraph s1["Human and intent surface"]
        l1["1. Human Interface Layer"]
        l2["2. Goal & Intent Layer"]
    end
    subgraph s2["Orchestration core"]
        l3["3. Orchestration Layer"]
        l4["4. Agent Runtime Layer"]
        l5["5. Agent Registry Layer"]
    end
    subgraph s3["Infrastructure services"]
        l6["6. Tool Abstraction Layer"]
        l7["7. Memory & Data Layer"]
        l8["8. Event Layer"]
    end
    subgraph s4["Governance and observability"]
        l9["9. Governance & Controls Layer"]
        l10["10. Observability Layer"]
    end
    subgraph s5["Domain and runtime config"]
        l11["11. Domain Pack Layer"]
        l12["12. Business Instance Layer"]
    end
    s1 --> s2
    s2 --> s3
    s3 --> s4
    s4 --> s5

Platform mapping

PlatformPrimary layer(s)Notes
n8n3 (Orchestration)Workflow engine; all workflow definitions live here. Orchestration only — complex agent reasoning runs in LangGraph (Layer 4).
LangGraph4 (Agent Runtime)Stateful/cyclic/multi-agent reasoning runtime; built with the LangChain library; invoked by n8n as a governed step. See ADR-OS-001.
Hookdeck8 (Event)Ingress webhook fan-out and replay
Hookdeck Outpost8 (Event)Egress delivery and retry for outbound events
Redis7 (Memory)Hot state and pub/sub
Supabase PG177 (Memory)Canonical relational truth
QuestDB7 (Memory)Time-series metrics and telemetry
Neo4j7 (Memory)Context graph and decision lineage. The graph memory tier runs on it through the NAMS client (neo4j-labs/agent-memory), adopted as a library, not a platform row — see ADR-OS-002.
Qdrant7 (Memory)Semantic vector memory; the single vector substrate for every indexed memory tier.
Langfuse10 (Observability)LLM tracing and prompt engineering
PostHog10 (Observability)Behavioral analytics
Grafana LGTM Stack10 (Observability)Operational monitoring (Grafana, Alloy, Mimir, Loki, Tempo)

Four-plane projection

ADR-OS-015 admits a four-plane view of the OS agent set (Orchestration, Control, Intelligence, Memory) as a presentation aid for describing the agents to an organisational reader. It is a projection over family and layer. It is not a layer, not a taxonomy, and not an agent’s classification: the layer count stays twelve and family and layer remain authoritative for every agent.

PlaneAgents drawn in itActual family and layer
Orchestrationos-agt-001control, Layer 3
Controlos-agt-002, os-agt-003, os-agt-004, os-agt-008 †control (Layers 9, 5, 9); os-agt-008 is observability, Layer 10
Intelligenceos-agt-005, os-agt-006, os-agt-007intelligence, Layer 10
Memoryos-agt-010, os-agt-011, os-agt-012, os-agt-009 ‡control (Layer 7, Layer 9) and intelligence (Layer 7); os-agt-009 is intelligence, Layer 4

† os-agt-008 is drawn beside the control agents but is family: observability and strictly read-only. ‡ os-agt-009 is drawn beside the memory agents as the interface to organisational knowledge, but is not a memory agent. That interface role is target state, not current behaviour: ADR-OS-015 §4.4 defers it until os-agt-009’s approval_required.policy is true, it is re-certified through the governance bridge, its invocation path carries the bridge, and its memory_profile is reviewed. Until then it holds semantic-KB read access only, and any depiction of it as an organisational interface must be marked as target state. Any chart that uses these planes must carry these markers and state the actual classification. The AI-Native Org Chart holds the full diagram.

Versioning

  • Version: 0.8
  • Supersedes: v0.7
  • Canonical layer count: 12

Canonical Reference

Taxonomy and Naming

Core Principles

Agent and Workflow Standards

Tech Stack

Memory

  • Synedrix OS Memory Fabric Spec — The Layer 7 control plane this table now records: tier taxonomy, memory record envelope, lifecycle, recall and promotion contracts, retention and erasure.
  • Synedrix OS ADR-OS-002 — Memory Fabric Control Plane — The decision to extend Layer 7 rather than add a layer, and the NAMS-as-library position recorded in the platform mapping.

Agents

  • Synedrix OS - Agent Registry — The twelve OS-owned agents and the layer each is assigned to.
  • Synedrix Trading Domain Pack — Trading domain pack; owns its own market-data, strategy, consensus and execution infrastructure at Layers 11 and 12.

Business Instance Extension and Capability Module

  • Business Instance layer page — Expands the new Layer 12 ownership entries into the Business Instance Extension concept and the domain_pack_version pin.
  • Domain Pack layer page — Where extension points and Capability Modules are declared.
  • Synedrix OS ADR-OS-005 — Business Instance Extension and Capability Module — The decision to extend Layer 12 rather than add a thirteenth layer.

Synedrix OS · August 2026