Synedrix OS - Agent Registry

This document defines the canonical registry entries for all agents owned by Synedrix OS. These agents are cross-domain: they operate identically regardless of which domain pack is active. Domain packs contribute their own agent entries using the same registry schema defined in §2; those entries are not listed here.

Status: Canonical OS-level reference · Date: October 2026 Scope: OS-owned agents — control, intelligence, and observability families

1. Purpose link

The agent registry is the authoritative catalog of what agents exist in the system, what they are responsible for, what they are permitted to do, and where they sit in the authority and escalation structure. Without a formal registry, multi-agent systems accumulate implicit assumptions about agent roles and permissions that are difficult to audit or evolve safely.

This document covers the OS layer of the registry. It:

• Defines the twelve OS-owned agents and their full contracts
• Specifies the authority boundary and tool access for each
• Documents how OS agents interact with each other and with domain agents
• Provides the registration schema that domain packs must use when contributing their own agents

2. Agent Registry Schema link

Every agent registered in Synedrix OS, including whether OS-owned or domain-contributed, must declare all fields in this schema.

3. OS Agent Summary link

Twelve agents are owned and shipped by Synedrix OS across three families.

The twelve agents by family:

flowchart TB
    OS["Synedrix OS: 12 agents"]
    subgraph control["Control family"]
        os_agt_001["Orchestrator Agent (os-agt-001)"]
        os_agt_002["Policy Guard Agent (os-agt-002)"]
        os_agt_003["Registry & Capability Agent (os-agt-003)"]
        os_agt_004["HITL Gateway Agent (os-agt-004)"]
        os_agt_010["Memory Curator Agent (os-agt-010)"]
        os_agt_012["Memory Access Broker Agent (os-agt-012)"]
    end
    OS --> control
    subgraph intelligence["Intelligence family"]
        os_agt_005["Analytics Agent (os-agt-005)"]
        os_agt_006["Forecasting Agent (os-agt-006)"]
        os_agt_007["Anomaly Detection Agent (os-agt-007)"]
        os_agt_009["General Chat Agent (os-agt-009)"]
        os_agt_011["Consolidation & Reflection Agent (os-agt-011)"]
    end
    OS --> intelligence
    subgraph observability["Observability family"]
        os_agt_008["Audit & Lineage Agent (os-agt-008)"]
    end
    OS --> observability

3.2 Canonical identifier forms link

Per Naming Convention Spec §3, agents also carry a canonical {layer}-{archetype}-{capability-slug}-{seq} identifier. Both forms are valid until migration completes.

4. OS Agent Definitions link

os-agt-001 - Orchestrator Agent link

Family: Control · Owner: Synedrix OS

Mission: Decompose incoming goals and events into executable task graphs, route work to the correct specialist agents or workflows, manage sequencing, retries, and approvals, and ensure every execution path reaches a declared terminal state.

Authority boundary: The Orchestrator Agent routes and sequences work but does not itself execute domain-specific business logic, make domain decisions, or write to external systems directly. All side effects are delegated to specialist agents through governed invocation.

os-agt-002 - Policy Guard Agent link

Family: Control · Owner: Synedrix OS

Mission: Evaluate proposed actions against the active policy ruleset before execution proceeds, enforce authority boundaries, apply risk thresholds, and emit a binding allow / block / escalate decision that the Orchestrator Agent must respect.

Authority boundary: The Policy Guard Agent evaluates and decides, it never executes business actions itself. Its block decision is final within the current workflow invocation; no human decision, including a HITL approval, reverses it. To change the outcome, a human changes the policy or thresholds and the action is re-proposed and re-evaluated (ADR-OS-018).

os-agt-003 - Registry & Capability Agent link

Family: Control · Owner: Synedrix OS

Mission: Resolve which agents, workflows, and capabilities are available, active, and correctly scoped for a given goal or task, and return a structured capability map that the Orchestrator Agent uses for routing.

Authority boundary: The Registry & Capability Agent reads registry state and returns routing recommendations. It never modifies agent or workflow registry entries, registration is a human operator action, not an agent action.

os-agt-004 - HITL Gateway Agent link

Family: Control · Owner: Synedrix OS

Mission: Manage the human-in-the-loop approval surface for all workflows that require human review - route approval requests to the correct reviewer, capture structured decisions, enforce review timeouts, and return binding outcomes back to the requesting workflow.

Authority boundary: The HITL Gateway Agent is a routing and capture mechanism, it does not interpret, modify, or override the human decision it receives. On timeout it escalates rather than deciding autonomously.

os-agt-005 - Analytics Agent link

Family: Intelligence · Owner: Synedrix OS

Mission: Aggregate cross-domain operational metrics, generate structured performance reports, and surface business-level signals that support human decision-making and domain pack monitoring, without owning or acting on the domain data it summarizes.

Authority boundary: The Analytics Agent reads broadly but writes nothing except its own report records and anomaly event emissions. It must not modify source data or trigger execution workflows directly.

os-agt-006 - Forecasting Agent link

Family: Intelligence · Owner: Synedrix OS

Mission: Generate forward-looking projections from historical time-series and operational data across domains, and return structured forecast outputs that domain agents and human operators can use for planning and threshold calibration.

Authority boundary: The Forecasting Agent produces probabilistic outputs. It must not represent forecasts as decisions or thresholds. Acting on a forecast is always the responsibility of the requesting workflow or human operator.

os-agt-007 - Anomaly Detection Agent link

Family: Intelligence · Owner: Synedrix OS

Mission: Continuously monitor operational signals, workflow metrics, and event streams across all active domains, identify patterns that fall outside configured normal bounds, and emit structured anomaly events for downstream triage and response.

Authority boundary: The Anomaly Detection Agent observes and signals, it never acts on what it detects. Remediation is a separate workflow that must be explicitly triggered and governed.

os-agt-008 - Audit & Lineage Agent link

Family: Observability · Owner: Synedrix OS

Mission: Correlate workflow execution traces, agent invocation records, policy decisions, and tool call logs into structured run lineage, and respond to explainability queries with a complete, sourced reconstruction of what happened, why, and under whose authority.

Authority boundary: The Audit & Lineage Agent is strictly read-only and always will be. It may never modify, redact, or amend audit records. Any amendment to audit state is a human operator action with its own audit trail.

os-agt-009 - General Chat Agent link

Family: Intelligence · Owner: Synedrix OS · Layer: 4 (Agent Runtime) · Canonical ID: os-int-general-chat-001

Mission: Answer natural-language questions about Synedrix OS by retrieving grounded context from a semantic knowledge base and composing a cited response, for standalone chat surfaces (e.g. a public website) that sit outside any domain pack.

Authority boundary: The General Chat Agent retrieves and answers; it never writes to any system of record and holds no execution authority. Its direct Vercel-to-LangGraph invocation path bypasses the n8n orchestration layer that normally carries the governance bridge — this is compliant only while decision_scope: recommend holds and no write-class tool is bound. Any expansion of its tool set to include a write-class tool requires routing through n8n/Orchestrator or embedding an equivalent Policy Guard/HITL call inside the graph before that tool may be enabled.

Organisational-interface conditions (ADR-OS-015 §4.4): os-agt-009 is not the organisational interface, and may not classify and route requests to os-agt-001 or os-agt-005, until all of the following hold: its approval_required.policy flips to true; it is re-certified through the governance bridge; its invocation path carries the bridge, or an equivalent in-path governance control is specified; and its memory_profile is reviewed against the wider recall surface routing implies. Until then, any depiction of os-agt-009 as an organisational interface is marked as target state.

os-agt-010 - Memory Curator Agent link

Family: Control · Owner: Synedrix OS · Layer: 7 (Memory & Data) · Canonical ID: os-ctl-memory-curator-001

Mission: Commit every durable memory record on behalf of the agents that propose them — forming, consolidating, promoting, expiring and erasing records under the memory lifecycle — so that no agent writes durable memory directly and every record carries complete provenance.

Authority boundary: The Memory Curator commits but never decides what should be remembered. Formation and consolidation proposals originate elsewhere — from any agent for formation, from os-agt-011 for consolidation and reflection — and the Curator’s role is to validate the envelope, enforce provenance, apply the write across the write-authoritative store and its projections, and emit the event. It has no authority to originate a memory record of its own, and no authority to commit an operation that os-agt-012 has not scoped or that os-agt-002 has blocked. It may never destroy lineage: erasure removes content and leaves a tombstone.

os-agt-011 - Consolidation & Reflection Agent link

Family: Intelligence · Owner: Synedrix OS · Layer: 7 (Memory & Data) · Canonical ID: os-int-memory-consolidation-001

Mission: Analyse accumulated memory records to propose consolidations, higher-order reflections, distilled procedural skills, tier promotions and conflict resolutions — producing recommendations only, never writes.

Authority boundary: The Consolidation & Reflection Agent reads broadly and writes nothing. Reading broadly is precisely why it holds no write authority: an agent that can both survey the whole fabric and commit to it could rewrite memory to match its own inference without a second opinion. Every proposal it emits is a recommendation carrying its derived_from chain and a rationale, and is only durable once os-agt-012 has scoped it and os-agt-010 has committed it. It may not resolve a detected conflict unilaterally — it proposes a resolution and the contested records remain flagged until the proposal is committed.

os-agt-012 - Memory Access Broker Agent link

Family: Control · Owner: Synedrix OS · Layer: 9 (Governance & Controls) · Canonical ID: os-ctl-memory-broker-001

Mission: Mediate every memory recall and every memory write proposal, resolving the requester’s declared scope against its memory_profile before any store is queried, and emitting an allow, partial or deny decision.

Authority boundary: The Memory Access Broker decides whether and at what scope memory may be read or written, and never sees the memory content itself. That separation is deliberate: the broker is on the path of every recall in the system, so granting it content access would make it the single most privileged reader in the OS. It resolves scope before the store is queried and returns filter predicates that are pushed down into the query — it never inspects and filters results after retrieval, because out-of-scope memory that has already entered the process has already leaked. A denial is terminal; the requesting agent escalates through its own path rather than reissuing a narrowed request automatically.

4.1 Authority and task surface declarations link

These declarations instantiate authority and task_surface for the twelve OS agents, so the autonomy ladder of ADR-OS-010 can be derived for each task class. They apply the conventions of ADR-OS-017: the agent-level approval field is approval_required (an object), risk_tier takes the four values in §2, and every agent declares governance_class. os-agt-002’s risk_tier is critical, which supersedes control-plane. The other tiers, the can_* flags and the task-class names are proposals taken from each agent’s existing input contract, execution scope and owner workflows, and the agent’s owner confirms them.

Own-output convention. Writes to an agent’s own outputs, caches, telemetry, declared events and designated audit records are not execution. Only a change of state in another system counts, and only that sets can_execute. A store that another agent reads as an input to a decision is not an own output, because a write to it changes what another agent decides; writing it is execution (ADR-OS-017 §3.1, limit 4). This is why os-agt-005, 006 and 007 stay can_execute: false although their execution scope lists writes to a report, forecast or anomaly store. os-agt-003 is an open case: its refresh-capability-cache task writes the Redis capability cache that os-agt-001 consults when it decomposes and dispatches, which limit 4 reads as execution. The registry keeps os-agt-003 at can_execute: false and recommend scope as provisional, and the owner decides whether the agent is re-scoped or the cache is treated as a designated output.

Agent-level declarations.

os-agt-001 delegates: it decomposes and dispatches, and the dispatched task carries its own gate, so it declares an explicit { policy: false, hitl: false } rather than leaving the field implied. os-agt-008 and os-agt-009 set no flag: they answer queries and write nothing, and can_recommend is declared false explicitly because it defaults to true. The gate agents (os-agt-002, 004, 012) set only can_approve.

Task surface. autonomous marks a class that needs no approval gate. A gate agent’s gate-function classes are listed in neither list and are marked gate, because the agent is itself the control and the class is not an action awaiting approval (ADR-OS-017 §3.3). They sit off the ladder, and governance_class stays autonomous. os-agt-001’s decompose-goal drafts a task graph and changes no external state, so it is L2; dispatch-task is not graded because the dispatched task carries its own level. The level is derived by the ADR-OS-010 mapping (most restrictive bound wins) and is a read-only view, never an input to authorisation.

os-agt-010 carries one class per operation in its input contract. All six are approval_required; form, consolidate, demote and expire are low, promote is high because it can widen visibility or cross into relational, and erase is irreversible. The agent-level object declares only the gate every operation shares, an os-agt-012 scope decision (broker: true). Policy approval is declared per class, because Memory Fabric Spec §7.3 requires it for some operations only:

Consistency check. The rules of ADR-OS-010 §4 item 6, plus the checks the declarations make possible, were applied to these declarations: scope against flags, level against the decision_scope ceiling, a class never both autonomous and approval-required, governance_class against the class gates, risk_tier values, an execute-scope agent declaring approval_required, and, as a flag rather than a rule, an irreversible class with no human gate. Four findings are open, and the declarations are published as they are until the owners and the ADR decide:

• os-agt-010 erase is irreversible and no human gate is declared. Under ADR-OS-010 §3.1 an irreversible task with policy approval is L4, and the read-only view flags it (and promote, which is high) as having no human gate. That is not a rule failure: the ADR does not require HITL for irreversible work (§4 item 9). The canon declares { broker: true, policy: true } for erase, with no human gate, and the Memory Fabric Spec §7.3 does not require one. Whether erase should gain a hitl requirement is an enforcement decision, since erasure leaves a tombstone and lineage survives. This registry does not decide it, and keeps the canon’s declaration. The owner of os-agt-010 decides, and the decision goes in a later registry version.
• Rule R1 as worded fails every recommend-only class marked autonomous. R1 ("can_execute false with a class marked autonomous") is still the accepted rule, so an implementation of it rejects the autonomous classes of os-agt-003, 005, 006, 007, 008, 009 and 011. They are listed here as failures against the rule as written, not as passes. This registry reads autonomous as “no approval gate needed”, which a recommend-only class legitimately is, and ADR-OS-010 records the proposed narrowing to a class whose side_effect_class is not none; that ADR is amended first, and this finding closes with it.
• os-agt-003 writes a store another agent reads as a decision input. The capability cache that refresh-capability-cache writes is consulted by os-agt-001, which the own-output convention reads as execution, yet os-agt-003 is recommend scope with can_execute: false. Either the agent is re-scoped or the cache is designated an output. The owner of os-agt-003 decides.
• os-agt-010 has no governance_class. Whether an os-agt-012 broker decision counts as a policy gate is undecided (ADR-OS-010 §8), so the value is pending. The per-class approval table above carries what can be said now.

Two further notes. The gate agents have declared effects the ladder does not grade, and they stay off it. os-agt-004 notifications to approvers are the gate’s designated output channel, so they count as its own output under the convention above and do not set can_execute; the owner of os-agt-004 confirms that reading.

Obligations of the higher tiers. os-agt-001 and os-agt-004 are high; os-agt-002, os-agt-010 and os-agt-012 are critical. The Agent Evaluation Spec makes policy compliance checks blocking and requires a 1.0 compliance rate for high and critical agents alike, and the Agent Registry Spec requires strict observability for both tiers. Under ADR-OS-017 §6.2 these obligations apply to all five agents. Whether the existing evaluation suites for these agents meet them has not been checked.

5. Agent Interaction Patterns link

OS agents interact in predictable patterns across all domain packs. The six most common:

5.1 Goal decomposition and routing link

This is the entry pattern for every goal Synedrix OS receives, regardless of domain. It exists to keep two concerns separate: what agents and workflows currently exist and are healthy (os-agt-003’s job) from how a specific goal should be decomposed and sequenced (os-agt-001’s job). The Orchestrator Agent never queries the registry directly by hand-coded assumption — it always asks the Registry & Capability Agent, so that agent availability, versioning, and deprecation are resolved in one place rather than duplicated across every workflow.

flowchart TD
  H([Human Intent]):::term --> O1[Orchestrator Agent os-agt-001: decompose goal_id goal_type intent_payload into a task graph]:::agent
  O1 --> R[Registry & Capability Agent os-agt-003: resolve required_capabilities against the live registry]:::agent
  R -- all capabilities resolved --> O2[Orchestrator Agent: receives capability_map, assigns tasks, invokes domain agents]:::agent
  R -- unresolved_capabilities --> O3[Orchestrator Agent: escalates to human operator per os-agt-003 escalation path, task graph pauses at the unresolved node rather than partially executing]:::warn
  O2 --> D[domain agents execute assigned tasks]:::agent
  D -- any task proposes a high-impact action --> G{Pre-execution policy gate §5.2}:::check
  D --> O4[Orchestrator Agent: collects task outcomes, transitions the task graph to a terminal_state]:::agent

Walking through the contract fields that actually flow between these steps:

1. Human Intent → Orchestrator Agent. The triggering event carries goal_id, goal_type, intent_payload, priority, and a freshly minted correlation_id that is propagated, unchanged, through every subsequent step of the pattern — this is what lets the Audit & Lineage Agent (§5.4) reconstruct the full path later. The Orchestrator Agent’s decomposition output is a task_graph: an ordered (and possibly branching) set of task nodes, each naming the capability it needs rather than a specific agent — capability resolution is deliberately deferred to the next step so the task graph itself never hard-codes which agent version handles a task.
2. Orchestrator Agent → Registry & Capability Agent. For each distinct capability named in the task graph, the Orchestrator Agent issues a { goal_type, domain?, required_capabilities[], task_context?, correlation_id } request. The Registry & Capability Agent is recommend-scoped: it returns a capability_map (each entry naming the resolved agent_id, optional workflow_id, capability, availability_status, and version) but never invokes anything itself.
3. The unresolved-capability branch. If any requested capability has no active, correctly-scoped agent — for example a domain pack agent that is deprecated or not yet registered — it lands in unresolved_capabilities[] instead of capability_map. Per os-agt-003’s registry entry, this is the one case where the pattern breaks out to a human operator rather than looping back to the Orchestrator Agent for a retry: a missing capability is a registration gap, not a transient failure, so retrying automatically would just repeat the same gap.
4. Orchestrator Agent → domain agents. Once capability_map is fully resolved, the Orchestrator Agent assigns each task-graph node to its resolved agent_id and invokes it with the task’s scoped inputs plus the same correlation_id. This is the only step in the pattern where a side effect (an actual agent invocation) occurs — consistent with the Orchestrator Agent being the sole execute-scoped agent in this flow; both the Registry & Capability Agent and, in the next pattern, the Policy Guard Agent only ever recommend or approve.
5. High-impact actions branch out, not through. If a domain agent’s assigned task proposes a high-impact action (a financial transaction, a regulated message, an irreversible external write), that task does not proceed directly to execution — it enters the pre-execution policy gate described in §5.2 before the Orchestrator Agent is allowed to mark it complete. Goal decomposition and routing resolves who does the work; the policy gate separately governs whether a specific action is allowed to happen.
6. Terminal state. The Orchestrator Agent is responsible for ensuring every task-graph node reaches a declared terminal state (completed, failed, or escalated) — per its registry entry, “ensure every execution path reaches a declared terminal state” is part of its core mission, not an optional cleanup step. A task graph with a node stuck indeterminately is treated as an orchestration defect.

5.2 Pre-execution policy gate link

flowchart TD
  D[Domain Agent proposes high-impact action]:::agent --> P{Policy Guard Agent evaluate against policy ruleset}:::check
  P -- allow --> O1[Orchestrator Agent proceed with execution]:::agent
  P -- block --> O2[Orchestrator Agent halt, emit policy.blocked event]:::warn
  P -- escalate --> H[HITL Gateway Agent route to human reviewer]:::agent
  H -- approved --> O3[Orchestrator Agent proceed]:::agent
  H -- rejected --> O4[Orchestrator Agent halt and notify]:::warn
  H -- timeout --> O5[Orchestrator Agent escalate to operator]:::warn

5.3 Cross-domain anomaly response link

flowchart TD
  A[Anomaly Detection Agent: detects deviation, emits anomaly.detected event]:::agent --> O[Orchestrator Agent: receives event, instantiates response workflow]:::agent
  O --> AN[Analytics Agent: produces context report for the anomaly]:::agent
  AN --> P[Policy Guard Agent: evaluates proposed remediation]:::check
  P --> H[HITL Gateway Agent: if human review required]:::agent
  H --> S[Domain specialist agent: executes approved remediation]:::agent
  S --> AL[Audit & Lineage Agent: records full trace on query]:::agent

5.4 Explainability query link

flowchart TD
  Q([Human Operator or Compliance Reviewer: submits lineage or audit query]):::term --> A[Audit & Lineage Agent: correlates traces, policy decisions, agent records]:::agent
  A --> R([Structured lineage response returned]):::term

5.5 Domain pack owning a real-time pipeline link

The Trading domain pack is a clear example of a pack that owns transport- and execution-level infrastructure of its own. It is worth reading as the general case: a pack may own its own channel or pipeline, and doing so does not make that channel an OS concern.

flowchart TD
  IN([Inbound market data, exchange feed / broker webhook]):::term --> MD[Market Data Ingest trd-ctl-master-orchestrator-001 — signal ingested, correlation_id assigned]:::agent
  MD --> AN[Technical / On-Chain / Sentiment / Macro Analysts trd-int-*-001 — signal validation, contributing_agents metadata]:::agent
  AN --> ST[Strategy Agents trd-exe-bull-strategist-001, trd-exe-bear-strategist-001, … — BULL/BEAR tagged signals]:::agent
  ST --> CO[Consensus Agent trd-ctl-consensus-001 — quorum aggregation 4-of-7 / 5-of-8, 500ms window]:::agent
  CO --> RM{Risk Manager VETO trd-ctl-risk-manager-001 — canonical + enriched VETO checks}:::check
  RM --> PG[Policy Guard Agent os-agt-002 — evaluates the proposed trade action]:::check
  PG --> PO[Portfolio Optimizer / Position Sizer trd-exe-*-001]:::agent
  PO --> EX[Execution Agent trd-exe-execution-001 — broker-isolated order placement]:::agent
  EX --> PT[Performance Tracker trd-int-performance-tracker-001 — fill confirmation, PnL]:::agent
  subgraph hitl [Trading HITL escalation path]
    Q[HITL Queue Manager WF-TRD-HITL-QUEUE-MANAGER-001]:::agent --> G[HITL Gateway Agent os-agt-004 with channel: trading + order context]:::agent
    G --> HU([Human operator reviews, approves, rejects, or modifies within risk bounds]):::term
    HU --> EX2[Execution Agent trd-exe-execution-001 resumes or cancels the order]:::agent
  end

Note what the OS contributes and what it does not. It orchestrates (os-agt-001), evaluates policy (os-agt-002), and carries the human decision (os-agt-004). It owns no part of the market-data path, the strategy/consensus logic or the broker execution surface, because those are specific to one domain pack and no other pack needs them. A second pack introducing, say, a commerce fulfillment pipeline would own its own transport the same way rather than asking the OS to grow a layer for it.

The Trading pack’s agent entries are defined in Synedrix Trading Domain Pack, not here.

5.6 Memory recall and durable commit link

This is the entry pattern for every memory interaction, and it exists to keep three concerns apart that a single memory service would collapse: may this agent see this (os-agt-012), what is worth remembering (os-agt-011), and what is actually written (os-agt-010). No agent performs more than one of the three.

flowchart TD
  N([Agent needs context]):::term --> T[tool:memory-recall bound only if present in the resolved active_tool_set]:::agent
  T --> B{Memory Access Broker os-agt-012: intersect requested scope with the agent memory_profile.recall_scope}:::check
  B -- deny --> D[memory.recall.denied, the agent escalates, it does not retry a narrowed request]:::warn
  B -- allow --> F[filter predicates pushed down into the Qdrant/Postgres/Cypher query]:::agent
  F --> RR[records returned WITH provenance and validity_interval attached]:::agent
  RR --> S([memory.recall.served]):::term
  L([Agent learns something durable]):::term --> PR[tool:memory-propose proposal only — returns a proposal id, never a committed record]:::agent
  PR --> W[background WF-OS-MEMORY-CONSOLIDATE]:::agent
  W --> C[Consolidation & Reflection Agent os-agt-011: propose merges, promotions, distilled skills]:::agent
  C --> BR[Memory Access Broker os-agt-012: scope-validate each proposal]:::check
  BR --> PG[Policy Guard Agent os-agt-002: gate promotions that require approval]:::check
  PG --> CU[Memory Curator Agent os-agt-010: commit]:::agent
  CU --> EV([memory.record.formed / .consolidated / .promoted]):::term

Three things in this path are load-bearing. Scope resolution happens before the store is queried, not after results return — out-of-scope memory that has already entered the process has already leaked, so filtering afterwards is not a control. The proposal path is asynchronous by design, so an agent never waits on extraction and never gains write authority as a side effect of learning something. And the commit is separated from the recommendation, so the agent that surveys the whole fabric (os-agt-011) is not the agent that can rewrite it.

Erasure follows the same shape with a different terminal: a human or compliance workflow initiates, os-agt-002 approves, os-agt-010 destroys content across the write-authoritative store and every projection, and a tombstone plus the surviving graph lineage keep the audit trail whole. See Memory Fabric Spec §8.4.

6. Domain Pack Agent Contribution link

Domain packs contribute their own agent entries to the shared registry using the same schema defined in §2. Requirements:

• Every domain agent must have a unique agent_id prefixed with the domain pack layer code, e.g. trd-agt-001 for a Trading pack agent, com-agt-001 for a Commerce pack agent.
• owner must be set to the contributing domain pack ID, not synedrix-os.
• family must be domain or customer — domain packs may not register agents in the control or observability families.
• Domain agents must declare their escalation_path explicitly and the terminal node must always be reachable via an OS control agent (os-agt-001 or os-agt-004).
• Domain agents with execution_scope that includes financial transactions, regulated messaging, or irreversible external writes must declare approval_required.policy: true.

Domain pack agent entries are maintained in the domain pack’s own canonical document and contributed to the shared runtime registry at deployment time.

6.1 Business Instance Extension and Capability Module Agent Contribution link

Business Instance Extensions (BIEs) and Capability Modules contribute agents to the shared registry using the same schema defined in §2, per ADR-OS-005. The invariants are the same ones §6 already states for domain-pack agents, restated here for the two owner forms §2’s widened owner enum adds:

• Business Instance Extension agents. family must be customer. owner must be set to the business instance’s own identifier — not synedrix-os and not the domain pack ID, even when the BIE targets a specific pack. Registered at BIE-deployment time, never injected into a running workflow (§7’s append-only invariant applies unchanged).
• Capability Module agents. family must be domain. owner must be set to the contributing domain pack ID (a Capability Module is vendor-owned IP, not customer-owned), qualified with the module identifier so it is distinguishable from the pack’s own core agents.
• Both owner forms must declare escalation_path explicitly, terminating at an OS control agent (os-agt-001 or os-agt-004) — identical to the domain-pack rule in §6.
• Both owner forms with execution_scope covering financial transactions, regulated messaging, or irreversible external writes must declare approval_required.policy: true — identical to the domain-pack rule in §6.
• The stable agent_id prefix convention for BIE and Capability Module agents (analogous to trd-agt-001, com-agt-001 for domain packs) is not yet minted in the Naming Convention Spec’s layer-code table — an open item recorded in ADR-OS-005 §8, deferred to a future Naming Convention Spec bump informed by the first real implementation.

7. Registry Invariants link

• The OS agent registry is append-only at runtime - no running workflow may add, remove, or modify an agent entry.
• OS-owned agents (owner: synedrix-os) may not be overridden, shadowed, or disabled by domain packs.
• An agent with decision_scope: execute must have a non-empty approval_required declaration. A delegating agent declares an explicit object, for example { policy: false, hitl: false }.
• Every agent declares governance_class and risk_tier, except that os-agt-010’s governance_class waits on ADR-OS-010 §8 (whether a broker decision counts as a policy gate); risk_tier is one of low, medium, high or critical. A gate agent declares governance_class: autonomous.
• A high or critical agent has blocking policy compliance checks, a 1.0 compliance rate and strict observability. os-agt-002 is critical.
• A task class is never both autonomous and approval-required, and its derived autonomy level never exceeds the ceiling set by its agent’s decision_scope.
• A write to an agent’s own outputs, caches, telemetry, declared events or designated audit records is not execution and does not set can_execute. A store that another agent reads as an input to a decision is not an own output, and writing it is execution.
• No agent may have systems_allowed entries that bypass the Tool Abstraction layer.
• Every agent must have at least one entry in escalation_path.
• Audit & Lineage Agent (os-agt-008) must never appear in any tools_allowed list - it is a query target, not a callable tool.
• Agent identifiers are not reused. The one exception is the v0.4 reallocation of os-agt-009–os-agt-013 recorded in §3.1, which was taken deliberately to leave the registry contiguous and is not a precedent. New OS agents allocate from os-agt-013 onward.

7.1 Memory control-plane invariants link

These extend the registry invariants above and are specified in full in Memory Fabric Spec §10.

• Memory Curator Agent (os-agt-010) is the only agent permitted to commit durable memory records. Any other agent writing directly to the episodic, semantic, procedural or profile tiers is non-compliant.
• Memory Access Broker Agent (os-agt-012) is on the path of every memory recall and every write proposal. Scope is resolved before the store is queried, never applied to results afterwards.
• Consolidation & Reflection Agent (os-agt-011) holds no write access to any memory tier. It reads broadly precisely because it commits nothing.
• No memory record crosses a tier boundary without a memory.record.promoted event carrying the inherited correlation_id and causation_id.
• Memory recall is a tool call bound in the resolved active_tool_set. Ambient memory injection into an agent’s context is non-compliant.
• Erasure leaves a tombstone; lineage in graph memory survives the erasure of content.

8. Relationship to Other Canonical Documents link

9. Versioning link

• Version: 0.8
• Supersedes: synedrix-os-agent-registry-v0.7
• Status: Canonical OS agent registry
• Applies to: Synedrix OS core platform, all domain packs, and Business Instance Extensions / Capability Modules
• Next steps: domain packs to contribute their own agent entries using the §2 schema; the first real BIE or Capability Module implementation to inform the agent_id prefix convention flagged in §6.1 and ADR-OS-005 §8.

Related Documents link

Canonical Reference link

• Synedrix OS - Consolidated Canonical Reference — Consolidated synthesis; §4 summarizes all 12 OS-owned agents defined here.

Registry Schema and Naming link

• Synedrix OS - Agent Registry Spec — Registry schema; the YAML structure used by all entries in this file.
• Synedrix OS — Naming Convention Spec — Canonical agent IDs; §3.4 lists the canonical OS agent IDs that supersede the os-agt-00x format used here. The memory agents’ canonical forms are listed in §3.2 above.
• Synedrix OS - Agent Spec — Full agent anatomy; the normative schema referenced by each registry entry.

Runtime and Evaluation link

• Synedrix OS - Agent Runtime Policy Spec — Runtime policy schema; governs how each registered agent is executed and model-routed.
• Synedrix OS - Agent Evaluation Spec — Evaluation spec; promotion gates require passing eval suites before an agent becomes active.
• Synedrix OS - Agent DB Schema — Relational schema; persists the registry entries, lifecycle events, invocation starts and outcomes for these agents.

Architecture link

• Synedrix OS - Taxonomy & Platform Spec — Canonical taxonomy and the OS agent families.
• Synedrix OS - Core Principles — The 12 governing principles every registry entry is accountable to.
• Synedrix OS - Layer Taxonomy Table — The canonical layer architecture each agent is assigned to.

Observability link

• Synedrix OS Observability Metrics Spec — Canonical metric families; os-agt-007 (Anomaly Detection) emits events defined in this spec, and the memory control-plane agents emit the memory metric families.

Synedrix OS · August 2026