AI-Native Org Chart

Status: Canonical Implements: Core Principles — Principle 6 (humans stay above the automation layer), Principle 3 (specialised agents over mega-agents), Principle 9 (one substrate, many domains) Adopted by: ADR-OS-015 — AI-Native Organisational Model (Status: Accepted, October 2026) Authority for: The domain-agnostic business-function archetype used to describe an agent-run organisation, and the named set of OS-level human roles and what each is accountable for. Not authority for: Agent definitions (Agent Registry), the tier ownership split (Responsibility Matrix), approval mechanics (Workflow Contract Spec), or memory authority (Memory Fabric Spec). Where this document and any of those disagree, they win.

Overview link

Synedrix OS should not be modelled as twelve AI employees reporting to a CEO. A better abstraction is an AI-native operating layer underneath a relatively small human leadership structure. The agents form a horizontal intelligence and control plane; humans retain accountability, authority, relationships and strategic judgment.

The key design principle is this:

The human org chart defines accountability. The Synedrix OS work graph defines execution.

That distinction changes how departments, managers, workflows, approvals, knowledge and decision-making are designed. It also aligns with the direction of current work on agentic organisations: McKinsey’s The agentic organization describes org charts based on hierarchical delegation pivoting toward agentic networks — work charts — based on exchanging tasks and outcomes, with governance, escalation thresholds, agent ownership and human accountability remaining explicit.

This document reads the twelve OS agents onto a business organisation. It maps each agent to the function- independent service it provides, states what humans still own and why, and traces how work actually flows.

Terminology. “Org chart” in this document names the figures in §2, §3 and §20 and nothing else. The canonical term for who owns what across Synedrix OS, domain packs and business instances is responsibility matrix, specified in Synedrix OS - Responsibility Matrix. This document adds a second axis — human versus agent — and does not restate the first.

1. How to read this chart link

The figures below are not reporting hierarchies. Four things follow from that, and they are the difference between a useful diagram and a misleading one.

• No line means “reports to”. Authority in Synedrix OS is decision_scope, declared per agent. An agent with approve binds an agent with execute on one specific question and holds no authority over it otherwise. There is no managerial relationship in either direction.
• Vertical position is plane, not seniority. An agent lower in a figure is not subordinate. It answers a different question.
• The four-plane view is a projection, not a classification. family and layer assignment remain authoritative for every agent, per ADR-OS-015 §4.2. Two agents are drawn outside their family because it reads better organisationally; both carry a marker and both are stated plainly in §3.1.
• Business functions are demand-side labels. They name the classes of goal an organisation originates. They are not domain packs, they mint no layer codes, and no rule, entity or threshold belonging to any of them lives at the OS layer.

Markers used throughout:

2. From hierarchy to a dual coordination model link

A conventional company is organised primarily through hierarchy:

flowchart TD
  A[CEO]:::term --> B[Executives]:::term --> C[Directors]:::term --> D[Managers]:::term --> E[Teams]:::term --> F[Individual contributors]:::term

The hierarchy serves several purposes simultaneously: assigning authority, transmitting information, coordinating work, approving decisions, allocating resources, and monitoring execution.

An AI-native company can separate those responsibilities.

flowchart TD
  subgraph human [HUMAN ACCOUNTABILITY LAYER]
    B[Board]:::term --> C[CEO]:::term --> EL[Executive Leadership]:::term --> BO[Business Owners]:::term --> DS[Domain Specialists]:::term
  end
  subgraph os [SYNEDRIX OS LAYER]
    O[Orchestrator]:::agent
    O --> CP[Control Plane]:::agent
    O --> IP[Intelligence Plane]:::agent
    O --> MP[Memory Plane]:::agent
  end
  subgraph execution [EXECUTION LAYER]
    DA[Domain Agents + Applications]:::agent
    DA --> S[Sales]:::agent
    DA --> F[Finance]:::agent
    DA --> H[HR]:::agent
    DA --> OP[Operations]:::agent
    DA --> CS[Customer Service]:::agent
  end
  DS <-- HITL / Decisions --> O
  CP --> DA
  IP --> DA
  MP --> DA

The company still has executives, managers, specialists and employees. But machines increasingly perform the coordination work between them. The result is effectively two overlapping structures:

This is the foundation of the Synedrix OS organisational model.

3. The four organisational planes link

The twelve Synedrix OS agents naturally form four functional planes.

flowchart TD
  OR[ORCHESTRATION]:::term --> O[ORCHESTRATOR]:::agent
  O --> cp
  O --> ip
  O --> mp
  subgraph cp [CONTROL PLANE]
    A1[Policy Guard]:::check
    A2[Registry]:::agent
    A3[HITL Gateway]:::agent
    A4[Audit & Lineage †]:::agent
  end
  subgraph ip [INTELLIGENCE PLANE]
    B1[Analytics]:::agent
    B2[Forecasting]:::agent
    B3[Anomaly Detection]:::agent
  end
  subgraph mp [MEMORY PLANE]
    C1[General Chat ‡]:::agent
    C2[Memory Curator]:::agent
    C3[Consolidation & Reflection]:::agent
    C4[Memory Access Broker]:::agent
  end

Each plane answers a fundamentally different organisational question.

The Orchestrator asks: What needs to happen?

The Control Plane asks: Are we allowed to do it, who can do it, and should a human intervene?

The Intelligence Plane asks: What does the data tell us about what is happening and what may happen next?

The Memory Plane asks: What does the organisation already know, and what should it learn from this?

Together these constitute something close to a corporate nervous system.

3.1 Where the analogy breaks link

Two placements in the figure above are organisational rather than architectural, and both matter.

† Audit & Lineage is drawn beside the control agents, but it is not one of them. os-agt-008 is family: observability, its decision_scope is recommend, and its execution scope is “None — this agent is read-only by design”. A hard registry invariant governs it: it must never appear in any agent’s tools_allowed list — it is a query target, not a callable tool. Nothing in the control plane tasks it, and no work flows into it from any agent. It reads the audit trail, the lineage graph and the trace store, and it answers humans. The absence of an inbound line is the invariant, not an omission in the drawing.

‡ General Chat is drawn in the Memory Plane, but it is not a memory agent. os-agt-009 is family: intelligence at Layer 4 (Agent Runtime), not Layer 7. There are exactly three memory agents — os-agt-010, os-agt-011 and os-agt-012 — and the separation between them is load-bearing (§14). General Chat appears beside them because it is the employee-facing interface to organisational knowledge, and every one of its reads goes through the Memory Access Broker. It is the interface, not a fourth memory agent.

And no line in either figure means “reports to”. The Orchestrator invokes agents but holds no domain authority over them. Policy Guard binds the Orchestrator on the question may this action proceed and on no other question. Authority here is per-decision, not positional.

4. Orchestrator — the coordination layer of the company link

The Orchestrator is probably the most important organisational component. It should not be considered the “AI CEO”. It is closer to a combination of chief of staff, workflow engine, project coordinator, operating system scheduler and delegation engine.

The human CEO says:

Increase enterprise revenue by 15% next year without reducing gross margin.

The Orchestrator does not decide whether that is the right strategic objective. It translates the objective into executable work.

flowchart TD
  B[Business Objective]:::term --> R[Increase enterprise revenue +15%]:::term --> O[ORCHESTRATOR]:::agent
  O --> T1[analyse current customers]:::agent
  O --> T2[analyse pipeline]:::agent
  O --> T3[forecast demand]:::agent
  O --> T4[analyse pricing]:::agent
  O --> T5[identify churn risk]:::agent
  O --> T6[model sales capacity]:::agent
  O --> T7[identify high-value segments]:::agent
  O --> T8[generate account plans]:::agent
  O --> T9[create campaigns]:::agent
  O --> T10[allocate tasks]:::agent
  O --> T11[monitor outcomes]:::agent

This is a major organisational shift. Today, much of this decomposition happens through meetings: CEO → CRO → VP Sales → Sales Manager → Account Executive. In an agentic organisation, the task graph can be generated dynamically. Humans become owners of outcomes rather than routers of tasks.

What it does not do. os-agt-001 holds decision_scope: execute, but that scope is orchestration, not business authority. It “routes and sequences work but does not itself execute domain-specific business logic, make domain decisions, or write to external systems directly”. Every side effect is delegated to a specialist agent through governed invocation. It sequences; it does not decide what the business should do.

5. Registry — the digital workforce directory link

As soon as the company has dozens or hundreds of agents, a new problem appears: who knows which agent can do what? That is what Registry solves.

Imagine a business instance with 150 registered capabilities:

customer_churn_predictor
invoice_reconciliation_agent
campaign_optimizer
contract_analyzer
lead_scoring_agent
procurement_agent
pricing_agent
fraud_detection_agent
legal_review_agent
inventory_forecasting_agent

Registry stores far more than the name. Conceptually:

flowchart LR
  A[Agent]:::agent
  A --> a1[Identity]
  A --> a2[Owner]
  A --> a3[Domain]
  A --> a4[Capabilities]
  A --> a5[Tools]
  A --> a6[Permissions]
  A --> a7[Model]
  A --> a8[Version]
  A --> a9[Cost]
  A --> a10[SLA]
  A --> a11[Reliability]
  A --> a12[Required policies]
  A --> a13[Allowed data classes]
  A --> a14[Autonomy level]
  A --> a15[Escalation rules]

When the Orchestrator needs something like forecast next quarter’s customer churn, it does not hardcode an agent name. It asks Registry for a capability, and Registry answers:

Agent: churn_forecasting_v4

Reliability: 97.4%
Owner: Customer Analytics

Input:
- customer profile
- usage metrics
- support history

Allowed data:
- internal
- customer confidential

Human approval:
Not required for prediction

Human approval:
Required for automated retention offers > €5,000

Registry therefore becomes the organisational directory of the machine workforce.

Open item — target state, not the current contract. os-agt-003’s declared capability_map output today returns only agent_id, an optional workflow_id, capability, availability_status and version. The reliability score, owner, input-data schema, allowed-data classes and approval-threshold fields shown above are the richer capability record this document argues Registry should expose — not what a caller receives today. Closing this gap is an Agent Registry schema change, not something this document can declare on its own authority.

What it does not do. os-agt-003 is decision_scope: recommend. It “never modifies agent or workflow registry entries — registration is a human operator action, not an agent action”. The registry is append-only at runtime. And when Registry cannot resolve a required capability, that is not a retry condition: a missing capability is a registration gap, not a transient failure, and it breaks out to a human operator. The directory can tell you the workforce is short-staffed. It cannot hire.

The €5,000 figure above, and every other concrete threshold in this document, is a Business Instance configuration value shown for illustration. Synedrix OS owns the mechanism — that a threshold is consulted. The business instance owns the number.

6. Policy Guard — executable corporate governance link

A major difference between traditional companies and AI-native companies is that policy can become executable.

Today, policies typically exist as documents — travel policy, procurement policy, privacy policy, pricing guidelines, discount policy, security policy — and humans are expected to remember them. Synedrix OS represents the important rules computationally:

IF discount <= 10%
AND customer_segment = SME
AND gross_margin >= 30%
THEN auto-approve

IF discount > 20%
THEN require Sales Director

IF data_classification = "HR Confidential"
AND requester_department != HR
THEN deny access

Policy Guard therefore sits across every workflow.

flowchart TD
  P1[Proposed Action]:::term --> G1{Policy Guard}:::check
  G1 --> AL[ALLOW]:::check
  G1 --> BL[BLOCK]:::warn
  AL --> EX[Execution]:::agent
  P2[Proposed Action]:::term --> G2{Policy Guard}:::check
  G2 --> RH[REQUIRES HUMAN AUTHORITY]:::warn
  RH --> H[HITL Gateway]:::agent

The organisational implication is significant. Compliance stops being only a department that reviews completed processes. It becomes embedded into execution: spending limits, privacy restrictions, authorisation boundaries, contractual rules, security requirements and approval thresholds are all evaluated while work occurs. McKinsey describes this pattern — guardrail agents operating within a control function, monitoring agent activity and enforcing policy inside workflows — as central to enterprise agentic infrastructure.

What it does not do. os-agt-002 is decision_scope: approve: it “evaluates and decides, it never executes business actions itself”. Its block is final within the workflow invocation, and no human decision, including a HITL approval, reverses it: a human changes the policy and the action is re-proposed. Critically, Policy Guard enforces policy; it does not decide what the company’s ethical or legal policy ought to be. That remains human (§21).

7. HITL Gateway — where organisational authority lives link

Human-in-the-loop is often misunderstood as show a confirmation dialog before the agent does something. Synedrix OS treats HITL — human-in-the-loop — much more seriously. The HITL Gateway is the boundary between machine autonomy and human authority.

It understands monetary thresholds, reputational risk, legal consequences, confidence, irreversibility, policy exceptions, customer impact, employee impact and security sensitivity.

Consider procurement:

flowchart TD
  M[€400 routine supplier payment]:::term --> PS[policy satisfied]:::check --> AE[AUTOMATIC EXECUTION]:::agent
  C[€87,000 software contract]:::term --> PG{Policy Guard}:::check --> H[HITL Gateway]:::agent
  H --> D1[Department Head]:::term
  H --> D2[Procurement]:::term
  H --> D3[Security]:::term
  H --> D4[CFO]:::term
  D1 --> AR[Approve / Reject]:::check
  D2 --> AR
  D3 --> AR
  D4 --> AR

A rejected or edited proposal is resubmitted as a new proposed action through Policy Guard — the HITL Gateway itself never carries a modified payload back into execution; it captures a decision, not an edit.

This is where the human organisational hierarchy intersects the Synedrix OS work graph. The HITL Gateway knows who holds authority.

Therefore:

Agent decision ≠ organisational authority.

Synedrix OS can recommend. Synedrix OS can coordinate. Synedrix OS can execute within delegated boundaries. But humans define those boundaries.

What it does not do. os-agt-004 is “a routing and capture mechanism — it does not interpret, modify, or override the human decision it receives”. It captures decision, reviewer_id, rationale and decided_at, enforces a timeout, and returns a binding outcome. On timeout it escalates rather than deciding. And HITL approval does not bypass Policy Guard: both must pass, and policy is re-evaluated after approval (§22.2).

8. Audit & Lineage — the corporate evidence system † link

Traditional systems frequently tell you transaction completed. An AI-native system must answer something much more difficult: why did this happen?

Suppose Synedrix OS changes a customer price. Audit & Lineage reconstructs:

flowchart TD
  C[CEO Objective]:::term --> R[Revenue optimisation initiative]:::term --> O[Orchestrator task #83291]:::agent --> P[Pricing Agent]:::agent
  P --> I1[Customer segmentation data]
  P --> I2[Competitive pricing]
  P --> I3[Historical margin]
  P --> I4[Demand forecast]
  P --> RP[Recommended price +6%]:::agent --> PG[Policy Guard]:::check --> AL[Allowed]:::check --> SD[Sales Director approval]:::term --> CRM[CRM update]:::agent --> CN[Customer notification]:::agent

Audit retains:

WHO
WHAT
WHEN
WHY
USING WHICH DATA
USING WHICH AGENT
USING WHICH MODEL
USING WHICH POLICY
WITH WHICH HUMAN APPROVAL
RESULTING IN WHICH ACTION

That creates organisational explainability, and it is what Principle 7 requires: the system must always be able to answer what happened, why it happened, and under whose authority.

What it does not do — and cannot. os-agt-008 is strictly read-only and always will be. It may never modify, redact or amend an audit record. It is never invoked by another agent; it appears in no tools_allowed list anywhere in the platform. It is reached by a human — in practice the human compliance owner — asking it a question (§22.5). An internal audit department receives requests and holds a backlog. This does not.

9. Analytics — the company’s real-time observational system link

Analytics is broader than traditional BI dashboards. Instead of humans repeatedly asking show me last month’s revenue, Analytics becomes a continuously available reasoning capability spanning customers, revenue, margins, marketing, operations, inventory, employees, support, products and finance.

For example, the CEO asks General Chat: Why are European margins falling?

General Chat does not invent an answer. The flow becomes:

flowchart TD
  G[General Chat ‡]:::agent --> O[Orchestrator]:::agent --> A[Analytics]:::agent
  A --> R[Revenue]
  A --> PR[Pricing]
  A --> L[Logistics]
  A --> F[FX]
  A --> C[COGS]
  A --> FD[Finding: Margin ↓ 3.8%]:::warn
  FD --> D[Drivers: logistics +1.5%, discounting +1.2%, FX +0.7%, returns +0.4%]:::term

Analytics therefore becomes enterprise-wide situational awareness.

What it does not do. os-agt-005 is decision_scope: recommend. It “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.”

‡ Target state. The routing step shown above depends on General Chat invoking the Orchestrator, which the current registry does not permit. See §13 and ADR-OS-015 §4.4.

10. Forecasting — organisational foresight link

Analytics explains the present and the past. Forecasting deals with possible futures: revenue, cash flow, sales pipeline, customer churn, inventory, staffing, demand, capacity, project delivery, marketing ROI.

More importantly, Forecasting provides scenario analysis:

Executives now make decisions with forward-looking simulations rather than only historical dashboards.

The human still chooses the scenario. The machine expands the decision space. That sentence is the invariant, not a stylistic preference: os-agt-006 “must not represent forecasts as decisions or thresholds. Acting on a forecast is always the responsibility of the requesting workflow or human operator.” Forecasting supplies projections. It never sets a target, a budget or a threshold.

11. Anomaly Detection — the corporate immune system link

Analytics answers questions. Anomaly Detection does not wait to be asked. It continuously observes: unexpected revenue decline, unusual expense, supplier delay, customer churn spike, API usage explosion, suspicious payment, inventory imbalance, marketing CAC spike, employee access anomaly, support backlog surge.

Imagine normal enterprise churn is 2.5%, and it suddenly reaches 5.8%:

flowchart TD
  A([Anomaly]):::warn --> O[Orchestrator]:::agent
  O --> A1[Analytics]:::agent
  O --> A2[Customer Support]:::agent
  O --> A3[Product Usage]:::agent
  O --> A4[Account Management]:::agent
  O --> H[Root cause hypothesis: Recent API change]:::term
  H --> HI[HITL]:::agent --> E[Engineering / Product response]:::term

This makes the organisation reactive at machine speed.

What it does not do. os-agt-007 “observes and signals, it never acts on what it detects. Remediation is a separate workflow that must be explicitly triggered and governed.” The detector never fixes.

12. Intelligence as a shared corporate service link

Analytics, Forecasting and Anomaly Detection do not belong exclusively to Finance. They form a shared enterprise intelligence capability available to every business function on identical terms.

That produces an operating loop:

flowchart TD
  BE([BUSINESS EVENTS]):::term --> A[Analytics]:::agent
  A --> F[Forecasting]:::agent
  A --> AD[Anomaly Detection]:::agent
  F --> O[Orchestrator]:::agent
  AD --> O
  O -- recommended action --> PG{Policy Guard}:::check
  PG --> L[LOW RISK]:::check --> EX[execute]:::agent
  PG --> HR[HIGH RISK]:::warn --> HG[HITL Gateway]:::agent --> H([Human]):::term

That loop operates across departments. A revenue anomaly might simultaneously trigger Sales investigation, Marketing attribution analysis, revised Finance forecasting and Operations capacity adjustments. The company starts behaving less like disconnected departments and more like a shared event-driven system.

This is why none of the three intelligence agents is mapped to a single function anywhere in this document. Binding Forecasting to Finance or Anomaly Detection to Operations would recreate exactly the departmental silo the shared plane removes.

13. General Chat — the organisational interface ‡ link

General Chat is the primary human interface into Synedrix OS. Employees should not need to know which agents exist.

A sales manager asks: Which customers should my team focus on this week? An employee asks: What is our parental leave policy? The CFO asks: What happens to runway if revenue falls 12%? A product manager asks: What were the main lessons from our previous three launches?

General Chat determines what type of request it is:

flowchart TD
  U([USER]):::term --> GC[General Chat ‡]:::agent
  GC --> Q[Question]:::check
  GC --> A[Action]:::check
  GC --> AN[Analysis]:::check
  Q --> M[Memory]:::agent
  A --> O[Orchestrator]:::agent
  AN --> AY[Analytics]:::agent

The user therefore interacts with one enterprise interface rather than hundreds of agents.

Open item — this section describes target state, not the current registry.

os-agt-009 today holds decision_scope: recommend, “triggers no side effects”, has no owning workflow, is invoked directly rather than through the orchestration layer, and reaches semantic memory read-only with “no access to operational, conversation, or canonical relational memory”. Routing requests to os-agt-001 or os-agt-005, as drawn above, is not currently permitted.

The registry states the remedy for its own conditionality: the approval_required.policy: false declaration “must flip to true and the agent re-certified through the governance bridge before any write-capable tool is added”. ADR-OS-015 §4.4 records the full set of conditions and defers the decision. Whether the enterprise interface should be os-agt-009 at all, rather than a Human Interface surface at Layer 1 calling os-agt-001 directly, is undecided.

14. Memory Access Broker — zero-trust corporate knowledge link

One of the dangerous assumptions in enterprise AI is: if the AI knows something, every employee can ask for it. That cannot be allowed.

Imagine the memory fabric contains board minutes, employee salaries, customer contracts, technical documentation, sales data, legal disputes, product roadmaps, HR records, incident reports and strategy documents.

A developer asks: What is the CEO’s compensation?

General Chat never directly queries memory. Instead:

flowchart TD
  E([Employee]):::term --> GC[General Chat ‡]:::agent --> MAB[Memory Access Broker]:::check
  MAB --> Q1[Who is requesting?]
  MAB --> Q2[What role?]
  MAB --> Q3[What data classification?]
  MAB --> Q4[What policies apply?]
  MAB --> D[DENY]:::warn

The broker allows Synedrix OS to implement zero-trust organisational memory. A permitted request follows the same path and returns through it:

flowchart LR
  E([Employee]):::term --> GC[General Chat ‡]:::agent --> MAB[Memory Access Broker]:::check --> EM[Enterprise Memory]:::agent
  MAB -.-> GC2[General Chat ‡]:::agent
  GC2 -.-> E2([Employee]):::term

How it actually works, and why that matters. os-agt-012 resolves the requester’s declared scope against its memory_profile and returns allow | partial | deny with tiers_granted[], tiers_denied[] and filter_predicates — before any store is queried. The predicates are pushed down into the query. It never inspects retrieved records and filters them afterwards, “because out-of-scope memory that has already entered the process has already leaked”. It holds no access to memory content in any tier: it 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 platform.

A denial is terminal. The requester escalates; it does not retry with a narrowed request.

Open item — target state. os-agt-009 today holds semantic-KB read access only (Qdrant, read-only), with “no access to operational, conversation, or canonical relational memory” — the tiers where board minutes, compensation records and legal disputes would actually live. Its current LangGraph→Qdrant path is direct, with no Memory Access Broker step, which the registry explicitly scopes as compliant only while decision_scope: recommend holds and is documented as a bounded exception in the DGX deployment topology, not an oversight. The zero-trust flow shown above — reaching regulated organisational records through os-agt-012 — depends on the same os-agt-009 interface conditions §13 already defers to ADR-OS-015 §4.4, plus giving General Chat a recall path into the tiers the broker actually governs.

15. Memory Curator — institutional knowledge management link

Companies produce enormous amounts of information — emails, chat, meetings, tickets, reports, documents, CRM notes, incidents, projects, AI conversations. But information is not memory. If Synedrix OS stored everything indiscriminately, memory would become noise.

The Memory Curator determines what survives:

Incident #381

Temporary data:
- debugging messages
- intermediate logs

Durable knowledge:
- root cause
- affected systems
- remediation
- prevention rule
- architectural lesson

Memory Curator transforms operational experience into reusable knowledge.

What it does not do. os-agt-010 is the only agent permitted to commit durable memory — and it “commits but never decides what should be remembered”. It has no authority to originate a record of its own, and none 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.

16. Consolidation & Reflection — organisational learning link

This agent moves beyond retrieval. Its purpose is to ask: what should the company learn from accumulated experience?

Suppose Synedrix OS observes 28 failed projects over two years. Reflection may discover:

FAILED PROJECT PATTERNS

67% involved unclear ownership
58% involved vendor integration
51% lacked technical discovery
43% exceeded initial scope by >40%

It may then propose:

New project policy:

Projects > €100k require:
- explicit accountable owner
- architecture review
- vendor integration assessment
- scope risk score

But critically, Reflection does not independently change corporate policy. The flow is:

flowchart TD
  A[Experience]:::term --> B[Memory]:::agent --> C[Consolidation & Reflection]:::agent --> D[Suggested organisational learning]:::agent --> E[Human governance]:::term --> F[Approved policy change]:::term --> G[Policy Guard]:::check

That creates a learning organisation.

Why it holds no write authority. os-agt-011 reads every memory tier and writes to none. The registry states the reasoning directly: “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.” It may not even resolve a detected conflict unilaterally — it proposes a resolution, and the contested records stay flagged until the proposal is committed by os-agt-010.

16.1 Three memory agents, not one department link

A conventional organisation would call all of this “Knowledge Management” and staff it as one function. Synedrix OS deliberately does not, and the separation is the design:

No agent performs more than one of the three.

General Chat (os-agt-009) is the employee-facing interface to this fabric, not a fourth memory agent — it is family: intelligence at Layer 4, and every read it makes passes through os-agt-012.

17. The management role changes significantly link

This architecture does not necessarily eliminate management. It changes what managers do.

Traditional managers spend substantial time on status gathering, reporting, meeting coordination, task assignment, information routing, escalation, follow-ups and dashboard creation. Much of this is highly automatable.

The manager of the future spends more time on priority setting, judgment, coaching, conflict, customer relationships, resource trade-offs, ethical decisions, organisational design and strategy.

So the managerial role moves from controller of tasks toward owner of outcomes.

18. Business functions are enabled by domain packs link

This connects strongly with the Synedrix OS domain pack concept, specified in the Synedrix OS - Domain Pack Template.

The relationship is many-to-many, not one-to-one. One business function may draw on several Domain Packs, Capability Modules and Business Instance Extensions together; one Domain Pack may support several functions. Customer Operations, for instance, might combine capabilities from the Customer Service, Trading and Commerce domain packs plus a company-specific BIE for its own escalation workflow — no single pack owns the function, and none of the three packs is exclusive to it.

The lists below show representative agents a pack might contribute to a function, not a department’s full agent roster or an exclusive assignment.

SALES DOMAIN PACK          FINANCE DOMAIN PACK        PEOPLE DOMAIN PACK

Lead Qualification         AP Agent                   Recruiting Agent
Opportunity Scoring        AR Agent                   Onboarding Agent
Account Research           Cash Forecast Agent        Workforce Planning
Proposal Agent             Expense Agent              Performance Analytics
Pricing Agent              Revenue Recognition        Learning Agent
Renewal Agent              Financial Reporting
CRM Agent

OPERATIONS DOMAIN PACK

Inventory Agent
Supplier Agent
Scheduling Agent
Capacity Agent
Logistics Agent

Synedrix OS sits above them:

flowchart TD
  OS[SYNEDRIX OS]:::agent --> S[Sales Domain Pack]:::agent
  OS --> F[Finance Domain Pack]:::agent
  OS --> H[HR Domain Pack]:::agent
  S --> A1[Agents]:::agent
  F --> A2[Agents]:::agent
  H --> A3[Agents]:::agent

This means Synedrix OS itself stays domain-agnostic. The company-specific intelligence lives in domain packs.

Naming. The function names above are archetype labels, not pack identifiers. com, fin and ops are already registered layer codes for Synedrix Commerce, Synedrix Finance and Synedrix Ops. This document therefore says the Finance function, never Synedrix Finance. Archetype names mint no layer codes and create no registry entries.

Domain-pack agents are bound by rules the OS agents are not: agent_id prefixed with the pack’s layer code, owner set to the pack rather than synedrix-os, family restricted to domain or customer — packs may not register agents in the control or observability families — an escalation_path whose terminal node reaches os-agt-001 or os-agt-004, and approval_required.policy: true for any financial transaction, regulated messaging or irreversible external write.

19. Business Instance Extensions — company-specific operating logic link

There is another layer beyond generic domain packs.

A generic Sales domain pack knows how sales organisations work. But one company may have a €50k enterprise approval threshold, HubSpot CRM, NetSuite ERP, custom pricing, EU-only customer data, three sales regions, a partner channel and specific commission rules.

Those details belong in a Business Instance Extension:

flowchart TD
  C[SYNEDRIX OS CORE]:::agent --> P[SALES DOMAIN PACK]:::agent --> B[COMPANY A BIE]:::term
  B --> B1[policies]
  B --> B2[systems]
  B --> B3[roles]
  B --> B4[thresholds]
  B --> B5[schemas]
  B --> B6[processes]

That allows Synedrix OS to remain reusable while every deployment becomes deeply organisation-specific. The decision rule from the Responsibility Matrix is blunt: a one-off refund workaround for a single customer is a Business Instance Extension, never a change to the domain pack.

BIE agents use family: customer and are owned by the business instance identifier — not synedrix-os, and not the domain pack ID, even when the extension targets a specific pack. The full model is ADR-OS-005.

20. Mapping the twelve OS agents into the company link

The uniformity of the third column is the finding. These twelve agents are not distributed across business functions — the functions are distributed across one shared spine:

flowchart TD
  F1[Revenue]:::term --> S1[steward]:::term --> K1[pack]:::agent
  F2[Finance]:::term --> S2[steward]:::term --> K2[pack]:::agent
  F3[Operations]:::term --> S3[steward]:::term --> K3[pack]:::agent
  F4[Product&Eng]:::term --> S4[steward]:::term --> K4[pack]:::agent
  F5[People]:::term --> S5[steward]:::term --> K5[pack]:::agent
  F6[Legal&Risk]:::term --> S6[steward]:::term --> K6[pack]:::agent
  F7[Service]:::term --> S7[steward]:::term --> K7[pack]:::agent
  K1 --> G1
  K2 --> G1
  K3 --> G1
  K4 --> G1
  K5 --> G1
  K6 --> G1
  K7 --> G1
  subgraph spine [GOVERNANCE SPINE — identical for all seven functions]
    G1[Orchestrator decompose]:::agent --> G2[Registry resolve]:::agent --> G3[Broker scope]:::agent --> G4[Policy Guard evaluate]:::check --> G5[HITL capture]:::agent --> G6[Curator commit]:::agent
    G7[Audit & Lineage reconstructs, on query †]:::agent
  end

Every function differs only in its pack row and its steward. Nothing else changes.

21. What humans still own link

This is the critical governance boundary. Humans retain accountability rather than routine coordination.

The Board owns governance, fiduciary responsibility and CEO oversight. The CEO owns corporate purpose, strategic direction, capital allocation and ultimately business outcomes. Executives own domain outcomes and define acceptable autonomy.

Managers increasingly own priorities, exception handling, coaching, resource allocation and judgment rather than status collection and task routing.

Subject-matter experts remain responsible for difficult domain judgments, particularly where information is incomplete or contextual.

Legal, risk, security and compliance leaders define policies and risk appetite. Policy Guard enforces those policies; it should not independently decide what the company’s ethical or legal policy ought to be.

Humans also retain decisions involving substantial irreversible consequences: major hiring and firing decisions, significant financial commitments, legal commitments, strategic partnerships, sensitive customer situations, policy changes and similar high-impact actions.

This distinction is consistent with the direction of current work on agentic organisations: humans increasingly steer outcomes and supervise exceptions rather than manually execute every process, but final accountability remains human.

21.0 Two layers, not one link

The six roles derived in §21.1 are not the complete human organisational accountability model described above — they are a narrower thing underneath it: the machine-readable interface Synedrix OS uses at runtime to know which human to route a decision to.

flowchart TD
  A[ORGANISATIONAL ACCOUNTABILITY ACTORS: Board / CEO / Executives / Managers / SMEs / Governance leaders]:::term
  B[SYNEDRIX HUMAN CONTROL ROLES: operator / risk owner / domain steward / compliance owner / senior reviewer / business instance owner]:::term
  C[SYNEDRIX OS AUTHORITY BOUNDARY]:::check
  A --> B --> C

CEO strategic accountability, Board fiduciary responsibility, executive outcome ownership, managerial judgment and SME domain expertise do not need to appear as agent escalation terminals in order to exist — they exist independently of this document and of Synedrix OS altogether. The six roles below are the subset of that broader accountability that Synedrix OS can actually address a decision to.

A single person typically holds several control roles at once — a CFO, for example, may hold business instance owner, human risk owner, and human domain steward for the Finance function simultaneously. The mapping from an organisational role to one or more control roles is a business-instance decision, not something this document, the Agent Registry, or ADR-OS-015 specifies.

21.1 Where these roles come from link

The roles below are not designed. Each is derived — it appears here only because an OS agent’s declared escalation_path terminates there, or because the Responsibility Matrix assigns it a Business Instance value. Where nothing derives, nothing is claimed.

A role is an accountability surface, not a job title. One person may hold several; a large business instance may split one across many. Pack-level and instance-level role names such as trading-operator or mrd-owner are instantiations of these roles within a pack or instance, never additions to the OS-level set.

21.2 HITL and HOTL by function link

HITL — human-in-the-loop — is a required checkpoint: the system cannot proceed until a human decides. HOTL — human-on-the-loop — is observational: the system continues, and the human can intervene but is not in the execution path. Which applies is declared per action class in the workflow contract’s approval_requirements.

Synedrix OS owns the mechanism — that a posture is declared, and one hard rule. The business instance owns which actions cross the threshold, who approves, and the timeout.

The entries below are examples of business-instance defaults, not OS-level mandates — the only OS-level hard rule is that these action classes require approval_required.policy: true (a Policy Guard evaluation). Whether that evaluation also requires a human checkpoint (HITL) versus permits autonomous execution once policy allows it (HOTL) is the business instance’s choice, not this document’s.

The hard rule, taken from the agent-contribution requirements: any agent whose execution scope includes financial transactions, regulated messaging, or irreversible external writes must declare approval_required.policy: true. No business instance configuration relaxes that.

Every posture in the table is a default a business instance sets, never a fact about the function.

22. How work flows link

Five traced flows. Each reuses a pattern already specified in Agent Registry §5 or in Academy chapter 08.1 rather than inventing a new one.

22.1 Human-initiated: “Launch Product X in Spain” link

A CEO gives Synedrix OS an objective:

Launch Product X in Spain during Q1 while maintaining a minimum 25% gross margin.

flowchart TD
  CEO([CEO]):::term --> O[ORCHESTRATOR]:::agent
  O --> R[Registry]:::agent --> R1[discover required capabilities]
  O --> M[Memory Access Broker]:::agent --> M1[previous launches / pricing / customers]
  O --> A[Analytics]:::agent --> A1[market + customer + historical performance]
  O --> F[Forecasting]:::agent --> F1[demand / revenue / margin scenarios]
  O --> P[Policy Guard]:::check --> P1[legal / budget / brand / data constraints]
  O --> D[Domain workflows]:::agent
  D --> D1[Finance]
  D --> D2[Marketing]
  D --> D3[Sales]
  D --> D4[Operations]
  D --> D5[Customer Service]
  O --> L[proposed launch plan]:::term
  L --> H[HITL Gateway]:::agent --> AP[CEO / CFO / CMO approval]:::term --> O2[ORCHESTRATOR]:::agent --> EX([EXECUTION]):::term

Once launched, the loop continues. Analytics monitors conversion, revenue and margin. Anomaly Detection notices deviations. Forecasting recalculates the quarter. The Orchestrator proposes corrective actions. Policy Guard evaluates them. Routine actions execute autonomously; consequential ones go through HITL.

The execution path emits the events that reconstruct the complete causal chain; Audit & Lineage correlates and returns it on query:

flowchart TD
  A[Objective]:::term --> B[data used]:::agent --> C[memory retrieved]:::agent --> D[agents invoked]:::agent --> E[models / versions]:::agent --> F[recommendations]:::agent --> G[policy evaluations]:::check --> H[human approvals]:::term --> I[actions]:::agent --> J[outcomes]:::term

That traceability matters because scaled agentic architectures need explicit identity, ownership, access control and comprehensive logging rather than opaque autonomous execution — a point McKinsey makes directly in its work on agentic infrastructure.

What this shows about who owns what. The human enters at exactly one point — the approval gate — not continuously. The correlation identifier is allocated once, at arrival, and propagated unchanged through every subsequent step.

22.2 Pre-execution policy gate with escalation link

Domain Agent proposes high-impact action
              │
              ▼
        Policy Guard
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
  allow     block    escalate
    │         │         │
    │         │         ▼
    │         │   HITL Gateway
    │         │         │
    │         │    ┌────┼────┬────────┐
    │         │    ▼    ▼    ▼        ▼
    │         │ approved rejected timeout
    │         │    │    │            │
    │         │    │    │            ▼
    │         │    │    │      escalate to operator
    │         │    │    │
    ▼         ▼    ▼    ▼
 proceed    halt  RE-EVALUATE  halt + notify
              │        │
     policy.block.raised
                       ▼
                 Policy Guard again

What this shows about who owns what. Authority without hierarchy: one agent’s decision binds another with no reporting line between them. block is final within the invocation, and no human decision, including HITL approval, reverses it. And the resumed run re-enters the policy boundary — that is where an edited argument or a changed policy is caught. Approval is not a bypass.

22.3 Machine-initiated: net revenue retention decline link

Nobody asked for this work.

flowchart TD
  AD[Anomaly Detection notices NRR 112% → 103%]:::warn --> O[Orchestrator — creates task graph]:::agent
  O --> T1[Customer analytics]:::agent
  O --> T2[Churn analysis]:::agent
  O --> T3[Product usage]:::agent
  O --> T4[Support analysis]:::agent
  O --> T5[Pricing analysis]:::agent
  T1 --> RG[Registry identifies the appropriate agents, Memory Access Broker retrieves historical context]:::agent
  T2 --> RG
  T3 --> RG
  T4 --> RG
  T5 --> RG
  RG --> FN[Analytics: enterprise customers with API-heavy usage, Memory: API pricing changed 6 months ago, Reflection: similar complaint pattern in support tickets, Forecasting: unchanged → NRR 96% within 2 quarters]:::term
  FN --> OP[Options assembled by the Orchestrator: 1. Grandfather strategic accounts, 2. Introduce volume pricing, 3. Launch retention campaign, 4. Adjust API pricing model]:::agent
  OP --> PG{Policy Guard}:::check
  PG --> CA[campaign actions execute autonomously]:::agent
  PG --> PC[pricing changes → HITL Gateway]:::agent
  PC --> AP[CRO / CFO / CEO]:::term --> O2[option 2 approved]:::term --> OI[Orchestrator invokes Pricing Agent]:::agent --> PE[Pricing Agent executes]:::agent
  PE --> EV[Every step emits its own record, Audit & Lineage reconstructs on query, Analytics monitors results, Reflection proposes a revision → Broker scopes → Curator commits]:::agent

What this shows about who owns what. The options are produced by domain agents, Analytics and Forecasting; the Orchestrator assembles and sequences them — it holds no domain authority and does not decide what the commercial remedy should be. The human decides which option, not whether to investigate.

This closes the operational loop:

flowchart LR
  A[Observe]:::agent --> B[Understand]:::agent --> C[Predict]:::agent --> D[Decide]:::agent --> E[Govern]:::check --> F[Act]:::agent --> G[Measure]:::agent --> H[Learn]:::agent --> I[Remember]:::agent --> A

That loop is arguably the core organisational architecture of Synedrix OS.

22.4 Memory recall and durable commit link

flowchart TD
  R1[Agent calls tool:memory-recall]:::agent --> R2{Memory Access Broker intersects requested scope with memory_profile.recall_scope}:::check
  R2 -- deny --> R3[memory.recall.denied]:::warn --> R4[escalate — do not retry narrowed]:::warn
  R2 -- allow --> R5[filter predicates pushed into the query]:::agent --> R6[records returned with provenance + validity_interval]:::agent --> R7[memory.recall.served]:::term
  P1[Agent calls tool:memory-propose]:::agent --> P2[returns a proposal id, never a committed record]:::agent --> P3[WF-OS-MEMORY-CONSOLIDATE]:::agent
  P3 --> P4[Consolidation & Reflection proposes merges / promotions]:::agent --> P5[Memory Access Broker scope-validates each proposal]:::check --> P6[Policy Guard gates promotions]:::check --> P7[Memory Curator commits]:::agent
  P7 --> E1[memory.record.formed]:::term
  P7 --> E2[memory.record.consolidated]:::term
  P7 --> E3[memory.record.promoted]:::term

What this shows about who owns what. Three agents do what one department would do, and that is not redundancy — it is the separation that keeps may this agent see this, what is worth remembering and what is actually written in different hands. Note also that the proposal path is asynchronous: an agent never waits on extraction, and never gains write authority as a side effect of learning something.

22.5 Explainability query † link

flowchart TD
  H[Human — compliance owner or operator]:::term -- correlation_id --> A[Audit & Lineage †]:::agent --> C[Ordered chain returned]:::term
  C --> C1[what was decided]
  C --> C2[by which agent]
  C --> C3[under which rule and policy version]
  C --> C4[approved by whom]
  C --> C5[what happened as a result]
  C --> C6[any memory promoted from it]

What this shows about who owns what. Any human — a compliance reviewer or an operator, per Agent Registry §5.4 — may submit this query; the compliance owner is its escalation owner, not its sole caller. This is the only flow initiated by a human into an agent, and the only one where an agent is a terminus rather than a participant. It is also why os-agt-008 has no inbound edge anywhere else in this document: it is not part of any execution path. Without this flow, its detachment in §3 would look like an oversight rather than the design.

Deliberately not traced here: goal decomposition and routing, which is absorbed into §22.1; and the real-time pipeline pattern from Agent Registry §5.5, which is Trading-specific — tracing it would import domain logic into an OS-layer document.

23. What the human org chart becomes link

For a conventional company organised through a traditional executive hierarchy, the resulting shape is closer to:

flowchart TD
  CEO([CEO]):::term --> CFO[CFO]:::term
  CEO --> COO[COO]:::term
  CEO --> CRO[CRO]:::term
  CEO --> CPO[CPO]:::term
  CEO --> CTO[CTO/CIO]:::term
  CFO --> OS[SYNEDRIX OS]:::agent
  COO --> OS
  CRO --> OS
  CPO --> OS
  CTO --> OS
  OS --> M[Enterprise agent mesh]:::agent
  M --> F[Finance Agentic Team]:::agent --> HF[Humans + Agents]:::term
  M --> R[Revenue Agentic Team]:::agent --> HR[Humans + Agents]:::term
  M --> O[Operations Agentic Team]:::agent --> HO[Humans + Agents]:::term

Consequently, do not create twelve executive-equivalent AI roles. The twelve Synedrix OS agents constitute the company’s shared control, intelligence and organisational-memory plane.

Underneath them sit dozens or hundreds of domain agents — Accounts Receivable Agent, Procurement Agent, Sales Qualification Agent, Campaign Agent, Customer Support Agent, Recruiting Agent, Inventory Agent, Contract Analysis Agent, and so on. The OS agents govern and coordinate those agents.

This produces three organisational layers:

flowchart LR
  A[Human Governance Layer]:::term --> B[Synedrix OS]:::agent --> C[Domain agent mesh]:::agent

rather than:

flowchart LR
  A[CEO]:::term --> B[VP]:::term --> C[Director]:::term --> D[Manager]:::term --> E[Employee]:::term

That is the deeper organisational implication. The Orchestrator replaces much of coordination. Policy Guard and HITL replace much of supervisory control. Analytics, Forecasting and Anomaly Detection replace much of information aggregation. Registry manages the digital workforce. The three memory agents, reached through the employee-facing interface, provide institutional cognition. Audit & Lineage supplies organisational accountability.

Humans then concentrate primarily on purpose, priorities, judgment, relationships, creativity, policy and accountability.

24. The final AI-native organisation link

flowchart TD
  B[BOARD]:::term --> C[CEO]:::term --> hel
  subgraph hel [HUMAN EXECUTIVE LAYER]
    E1[CFO]:::term
    E2[CRO]:::term
    E3[COO]:::term
    E4[CPO]:::term
    E5[CTO]:::term
  end
  E1 --> OS[SYNEDRIX OS]:::agent
  E2 --> OS
  E3 --> OS
  E4 --> OS
  E5 --> OS
  OS --> O[ORCHESTRATOR]:::agent
  O --> CP[CONTROL PLANE]:::agent
  O --> IP[INTELLIGENCE PLANE]:::agent
  O --> MP[MEMORY PLANE]:::agent
  CP --> DP[DOMAIN PACK LAYER]:::agent
  IP --> DP
  MP --> DP
  DP --> S1[Sales]:::agent
  DP --> S2[Finance]:::agent
  DP --> S3[Operations]:::agent
  DP --> S4[HR]:::agent
  DP --> S5[Customer Service]:::agent
  S1 --> DA[DOMAIN AGENTS]:::agent
  S2 --> DA
  S3 --> DA
  S4 --> DA
  S5 --> DA
  DA --> SY[SYSTEMS]:::agent --> X[CRM / ERP / APIs / SaaS / Databases]:::term

The human layer answers: What do we want?

Synedrix OS answers: How should the organisation coordinate itself to achieve it?

Domain agents answer: What specific work needs to be executed?

Systems answer: Where does the actual transaction happen?

And the intelligence and memory loops continuously ask: What happened, what changed, what will happen next, and what should we learn?

The most powerful framing for Synedrix OS is therefore not simply multi-agent orchestration software. It is an AI-native organisational operating system: a layer that turns human objectives, enterprise knowledge, business policies, specialised agents and existing software systems into governed, observable, continuously learning work graphs. The traditional org chart describes who is accountable; the Synedrix OS work graph describes how the company actually gets work done. That separation between an accountability chart and a dynamic work chart is the most important design principle here.

25. What this document does not establish link

• Headcount or job design. No staffing number appears anywhere in this document. A role is an accountability surface, not a job title, and nothing here implies how many people hold one.
• Domain logic. Business functions are demand-side labels. No rule, entity, event, policy or metric belonging to any of them is specified here or promoted to the OS layer.
• Agent capability. Every claim about an agent traces to its Agent Registry entry. Where the registry is silent, this document is silent.
• Ownership across tiers. That is the Responsibility Matrix, and this document defers to it entirely.
• Maturity staging or adoption sequencing. No phased rollout, readiness model or procurement guidance is implied.
• Approvers or thresholds. Every figure in this document is illustrative Business Instance configuration.

26. Invariants this document does not relax link

Versioning link

• Version: 0.3
• Supersedes: synedrix-os-ai-native-org-chart-v0.2
• Related: ADR-OS-015 — AI-Native Organisational Model, Synedrix OS - Responsibility Matrix, Synedrix OS - Agent Registry

Related Documents link

Decision record link

• ADR-OS-015 — AI-Native Organisational Model — The decision this document implements: the accountability/execution separation, the four-plane projection, the canonical human role set, and the deferral on os-agt-009.

Agents and authority link

• Synedrix OS - Agent Registry — The twelve agent definitions, every escalation_path the human roles in §21.1 are derived from, and the six interaction patterns §22 reuses.
• Synedrix OS - Agent Spec — The decision_scope semantics the planes render.
• Synedrix OS — Tool Authorization Model — Why os-agt-008 is bound as no agent’s tool, and how an active tool set is resolved rather than self-expanded.

Governance and human oversight link

• Synedrix OS - Core Principles — Principle 6, which this document implements; Principle 9, which requires the archetype to stay domain-agnostic.
• Synedrix OS - Responsibility Matrix — The tier ownership split. This document adds the human/agent axis and does not restate it.
• Synedrix OS - Workflow Contract Spec — Where HITL and HOTL posture is actually declared, in approval_requirements.
• Synedrix OS - Agentic Enterprise Manifesto Outline — §8 Human Role, the prose position §21 turns into a derived role set.

Structure and vocabulary link

• Synedrix OS - Layer Taxonomy Table — The twelve layers the four-plane view projects over; Layer 1 and Layer 12 are the human layer in §2.
• Synedrix OS - Taxonomy & Platform Spec — Domain pack naming and layer codes; why archetype names are not pack names.
• Synedrix OS — Vocabulary — HITL, HOTL, coordination model, responsibility matrix.
• Synedrix OS - Domain Pack Template — What a domain pack declares, referenced in §18.
• ADR-OS-005 — Business Instance Extension and Capability Module — The BIE model referenced in §19.

Lifecycle contracts link

• Synedrix OS — Goal Model Spec — The goal lifecycle a business objective follows through §22.1.
• Synedrix OS — Task Graph Spec — Runtime task graphs, runnability, and suspension while awaiting approval.
• Synedrix OS — Outcome Spec — The Outcome Envelope, the unit of lineage.
• Synedrix OS — Memory Fabric Spec — The three-way memory authority split §16.1 states, and the model for this document’s figures.

Consolidated reference link

• Synedrix OS - Consolidated Canonical Reference — Single-file synthesis of all canonical specifications.

Teaching material link

• Synedrix OS Academy — Chapter 08.1 traces a governed request path through the core agents and is the source for §22.1’s shape. Teaching material, not normative: where a chapter and a specification disagree, the specification wins.

Synedrix OS · September 2026