Tip: select any text on this page to bring up the Ask tooltip and question the Synedrix OS assistant about it.
What Synedrix OS is, and what it is not
The one platform every industry-specific deployment runs on top of.
Synedrix OS coordinates specialised agents across workflows, tools, and data under centralised policy, approvals, and audit. A domain pack configures it for one industry, and a business instance configures it for one deployment, without either one forking the platform underneath them. It is a platform to configure, not a chatbot framework, a single-purpose automation tool, or a system that gets rebuilt from scratch for every customer. Every business that adopts it runs the same core, tested once, instead of rebuilding governance and orchestration for itself.
One layer in a larger operating model
The governed operating layer under human accountability, between the organisational work graph and the twelve technical layers.
Synedrix OS is the governed operating layer under human accountability. It sits between the organisational work graph that coordinates execution and the twelve technical layers that implement the platform: the reusable core every domain pack and business instance configures.
Above it, humans keep strategy, authority, and the judgment calls where stakes are high. Below it, domain packs add industry logic and business instances add tenant configuration. The OS does not own those. It provides the shared primitives (orchestration, governance, memory, tool mediation, observability) they all run on.
It turns organisational objectives into coordinated work across agents, workflows, systems, and the people who need to sign off. Goals flow through that layer, get broken into work under policy and approvals, and return as proposed actions or completed outcomes inside boundaries humans set.
- Human accountability
- Organisational work graph
- Synedrix OS
- 12 technical layers
- Domain Packs / Business Instances
Six primitives every domain pack inherits, not rebuilds
The platform enforces them. Domain packs don't get a free pass.
Orchestration
Routes work across agents, tools, and workflows under explicit sequencing and retry rules: the same routing logic every domain pack reuses instead of rebuilding its own scheduler.
Agent lifecycle management
Registers, versions, and retires agents against a shared capability schema, so every agent stays discoverable, auditable, and safe to deprecate without breaking its callers.
Memory primitives
Seven specialised stores, governed by a control plane that decides what gets formed, consolidated, promoted across tiers, and forgotten, with lineage kept for every step.
Governance
Policy evaluation, approval routing, and authority boundaries enforced before execution. No agent writes to a production system without policy-aware, auditable visibility.
Tool mediation
Normalises access to external systems through a shared adapter layer, so domain packs call one consistent interface instead of coupling directly to a dozen vendor APIs.
Observability
Makes every execution measurable, explainable, and reviewable end to end. Logs, traces, metrics, and decision lineage are part of the platform, not something bolted on later.
active_tool_set before it executes; a call to anything outside it is rejected and emits agent.tool.unauthorized rather than reaching the vendor API. The same rule holds for the other five primitives: orchestration, lifecycle, memory, governance, and observability are all checked at the platform boundary, not trusted at the domain-pack boundary.OS, domain pack, business instance
The rule of inclusion decides where anything lives. Reusable across every domain, it belongs in the OS. Specific to one business, it belongs in a domain pack. Specific to one deployment, it belongs in the business instance.
Each tier owns a different kind of decision, and the boundary between them is what keeps the platform reusable instead of forked per customer.
Synedrix OS
Orchestration, governance, memory, and observability: the primitives every domain pack inherits rather than rebuilds.
Domain pack
Domain entities, events, specialist agents, and policies: the business logic that makes Trading different from Commerce.
Business instance
Secrets, approval thresholds, deployment mode, and tenant configuration: the knobs that make one customer's deployment different from another's.
Cloud-connected, self-hosted hybrid, or air-gapped
All three modes run the same platform code, the same agent architecture, and the same governance model. The deployment mode affects only where model inference occurs and whether external API calls are permitted.
Cloud-connected
All platform components run self-hosted, except the inbound Hookdeck gateway; model inference uses external cloud APIs. No business data is stored on external infrastructure, and data flows to model APIs for inference only.
Fits: Organisations comfortable with standard cloud data-processing agreements; development and staging.
Self-hosted hybrid
All components self-hosted except the inbound Hookdeck gateway, plus local inference. The split is declared per agent in the runtime policy: each agent's `model_type` is `cloud` or `local`, with the business instance default applied to agents that don't declare one.
Fits: Local inference on sensitive or regulated workflows, cloud APIs for lower-sensitivity tasks, and cost management.
Air-gapped
All components self-hosted except the inbound Hookdeck gateway, with all inference local. No outbound connection or external API call leaves the customer's infrastructure, and no business data leaves it. Inbound events pass through Hookdeck before delivery; that one third-party path must be disclosed to, and accepted by, the customer. Outbound blocking is enforced at the network level.
Fits: Regulated industries (finance, healthcare, legal, government, insurance) and classified or defence environments whose policy accepts the single inbound Hookdeck path.
primary_model or fallback_model is a cloud model URI while deployment_mode: air-gapped is set, configuration fails validation, and the business instance is rejected before it can be deployed.Explicit exclusions
Domain entities, secrets, tenant configuration, and model weights stay outside the OS.
The OS doesn't own domain entities, domain-specific events, or domain policies (those belong to a domain pack), secrets, approval thresholds, or tenant configuration (a business instance's job), or the model weights and inference runtime (supplied by whichever deployment mode a business chooses). It provides the platform these things run on, not the things themselves.
Twelve canonical layers
The reusable core every domain pack and business instance configures.
Shared before specific. · Controls before execution. · Tools are adapters, not business logic. · Memory is shared, access is scoped. · Memory moves only under governance.
Twelve OS-owned agents, three families
Cross-domain and identical regardless of which domain pack is active. Domain packs contribute their own specialist agents against the same registry schema.
Status is the agent's registry lifecycle state. Every agent here is specified; the platform that runs them is being built.
Routes work, gates actions, and commits what every other family only proposes.
Orchestrator Agent
control · os-agt-001Decomposes goals into task graphs, routes to specialists, manages retries and approvals.
Policy Guard Agent
control · os-agt-002Evaluates proposed actions against policy rules; emits allow, block, or escalate.
Registry & Capability Agent
control · os-agt-003Resolves which agents and workflows are available for a given goal.
HITL Gateway Agent
control · os-agt-004Routes approval requests to human reviewers, captures decisions, enforces timeouts.
Memory Curator Agent
control · os-agt-010The only agent that commits durable memory; every other agent proposes. Forms, consolidates, promotes and erases records.
Memory Access Broker Agent
control · os-agt-012Resolves recall scope against each agent's memory profile before any store is queried. Never sees memory content.
Analyses, projects, and proposes. Every agent here is recommend-only.
Analytics Agent
intelligence · os-agt-005Aggregates cross-domain metrics and surfaces performance signals.
Forecasting Agent
intelligence · os-agt-006Generates forward projections from time-series data.
Anomaly Detection Agent
intelligence · os-agt-007Monitors operational signals and emits anomaly events for triage.
General Chat Agent
intelligence · os-agt-009Answers questions about Synedrix OS from a semantic knowledge base, with cited sources. It powers the assistant on this site.
Consolidation & Reflection Agent
intelligence · os-agt-011Proposes consolidations, reflections and distilled skills from accumulated memory. Reads broadly, writes nothing.
Strictly read-only. Reconstructs what happened, why, and under whose authority.
Audit & Lineage Agent
observability · os-agt-008Reconstructs what happened, why, and under whose authority. Strictly read-only.
Twelve infrastructure platforms, non-overlapping responsibilities
Each one links to a page on what it does here and what it must not do.
| Platform | Role | What it does |
|---|---|---|
 n8n | Orchestration | Workflow kernel: sequencing, agent handoffs, approvals, retries. |
 LangGraph | Agent runtime | Stateful, cyclic, multi-agent reasoning, invoked by n8n as a single governed orchestration step. |
 Hookdeck | Ingress gateway | Inbound event validation, buffering, and replay. |
| Hookdeck Outpost | Egress gateway | Durable outbound notification delivery. |
 Redis | Coordination bus | Short-lived working data, live messaging between components, keys that make a retry safe, and rate limits. |
 Supabase PG17 | Transactional state | Canonical relational truth: entities, workflow state, audit trails. |
 QuestDB | Temporal data | High-volume time-series: metrics, events, trends. |
 Neo4j | Context graph | Workflow and outcome lineage, entity relationship graphs. |
 Qdrant | Semantic memory | Vector retrieval, context recall, RAG, pattern matching. |
 Langfuse | LLM engineering | Prompt versioning, LLM traces, token and cost tracking, evaluations. |
 PostHog | Behavioural analytics | Workflow analytics, feature flags, experiments. |
 Grafana LGTM Stack | Operational monitoring | Grafana, Alloy, Mimir, Loki, Tempo: dashboards, alerts, SLOs, logs, traces. |
Most components are open source and self-hostable. Hookdeck's inbound Event Gateway is proprietary managed SaaS (not self-hostable); Hookdeck Outpost (egress) is Apache 2.0 and self-hostable. n8n is fair-code and self-hostable. See each platform page for licence detail.
Four more tools we're testing right now
LanceDB, EverOS, Semantica, and Docling are running in our labs right now: real tools, actually tested, with nothing decided yet either way.
Platform questions, answered
What the platform is, how domain packs extend it, how it deploys, and how agents stay accountable. Ask the assistant for deeper, source-grounded detail.
What is Synedrix OS?
Synedrix OS is the governed operating layer for agentic business systems: a reusable, self-hostable platform that coordinates specialised agents across workflows, tools, and data under centralised policy, approvals, and audit. It is a platform to configure, not a chatbot framework or a single-purpose automation tool rebuilt for every customer.
What are domain packs, and how do they extend the platform?
Domain packs add industry-specific entity models, event catalogs, specialised agents, tool adapters, policies, and workflow libraries on top of the shared OS. Trading is the first fully specified pack; Commerce, Ops, and Finance are registered scopes that inherit the same core primitives.
What deployment modes does Synedrix OS support?
Synedrix OS supports cloud-connected, self-hosted hybrid, and air-gapped deployments. The same core platform runs in each mode; inference location and external connectivity change, not the governance model.
How does Synedrix OS keep AI agents accountable and auditable?
Agents operate under explicit authority levels (recommend, approve, execute), policy-aware orchestration, escalation paths to humans, and full audit trails. No agent writes to production systems without orchestration visibility, and irreversible or regulated actions require declared approvals.
In active development
Synedrix OS is in active development. The architecture documented here is complete and canonical. The platform is being built. Technical co-founders and early infrastructure investors are welcome: see /build-with-us and /invest.