Every organisation that lets AI agents act on its behalf eventually needs answers to four questions, at any moment and for any action: who owns this work, what is the agent allowed to do, who approved it, and what actually happened? Without an operating layer, the answers are scattered across tools, chat threads, inboxes and people's memories, and they are hardest to find exactly when they matter most.
The Citadel is the Guild's answer: in the words of the Citadel platform page, "the governance and orchestration platform where clients, human wizards, and AI agents plan, execute, approve, observe, and improve work together." This note describes its architecture at the level the site does — eight layers, six modules and a trust model — and explains the reasoning behind that shape. It is not an implementation specification; the systems and controls in any engagement are agreed for that engagement.
The principle: governance in every layer
The Citadel page states the design principle plainly: governance is built into every layer, and the Citadel connects execution to identity, evidence, policy and human accountability. Two consequences follow. Governance is not a separate approval tool that work is sometimes sent to; it is present wherever work happens. And every layer exists so that some question about accountability always has an answer.
Eight layers
| Layer | What it holds | The question it answers |
|---|---|---|
| 01 · Mission | Outcomes, scope, owners, milestones | What are we trying to achieve, and who owns it? |
| 02 · Wizard | Human direction and approvals | Which decisions stay with people, and who makes them? |
| 03 · Agent | Roles, tools, memory, limits | Who is doing the work, and within what limits? |
| 04 · Knowledge | Approved context and sources | What may the agents rely on? |
| 05 · Integration | Systems, APIs and credentials | Where can work reach, and with what access? |
| 06 · Guardrail | Permissions, policies, escalation | What is allowed, and what must be escalated? |
| 07 · Observability | Health, cost, outcomes, audit | What is happening, what does it cost, and what did it achieve? |
| 08 · Improvement | Evaluation and optimisation cycles | How does the system get better, safely? |
The order is the first thing worth noticing. The mission comes first and the people who direct it second; agents appear only in the third layer. The architecture starts from accountability, not from capability. An agent in the Citadel always works inside a mission someone owns, under direction someone gives.
The second is the separation between the agent layer and the layers around it. What an agent knows (knowledge), what it can reach (integration) and what it is allowed to do (guardrail) are held apart from the agent itself. That separation is what makes it possible to change an agent's boundaries without rebuilding the agent, and to see an agent's limits without reading its instructions.
Reading the layers as a flow
Read top to bottom, the layers describe the life of a governed piece of work. A mission is defined with an outcome and an owner. Human Wizards set its direction and decide which decisions stay with them. Agents are assigned roles, tools and limits, draw on approved knowledge, and reach systems through governed integrations. When an action is proposed, guardrails decide whether it is within policy, outside it, or needs a person. Observability records health, cost, outcome and audit evidence as the work happens. Improvement takes that evidence, evaluates it, and changes the system deliberately.
That last step is the one most operating models lack. On the How it works page the sixth stage, Evolve, is described as measuring outcomes, reviewing exceptions, improving the system and raising autonomy deliberately. The improvement layer is where that happens.
Six modules, six questions
The layers describe what the Citadel holds. The modules describe how people use it. Each is organised around a single operating question, quoted here from the platform page.
| Module | The question it answers | Draws mainly on |
|---|---|---|
| Missions | What outcome are we pursuing, and what happens next? | Mission, Wizard |
| Agent Console | Which agents are active, capable, healthy, and within policy? | Agent, Guardrail |
| Approvals | Where is human judgment required before work continues? | Wizard, Guardrail |
| System Health | Are applications, automations, and integrations operating normally? | Integration, Observability |
| Financials | What are we spending, saving, and learning from each mission? | Observability, Mission |
| Activity Ledger | What changed, who acted, and what evidence supports the action? | Every layer |
The right-hand column is our reading of how the modules relate to the layers, not a product diagram. Its point is that every module is a view across layers, which is why the platform page describes the whole as "one view" of missions, agents, systems and costs. The same page sets the standard for that view: every mission has an accountable owner, current status, decision history, health signal, cost view and next action.
The Activity Ledger deserves its own mention. It is the record that makes everything else trustworthy: what changed, who acted, and on what evidence. Because it is written as work happens, evidence is a by-product of operating rather than something reconstructed for an audit.
The trust model is part of the architecture
Autonomy in the Citadel is not a switch. The platform page describes it as "a graduated operating choice, not a blanket setting", with four levels: Observe (the agent recommends, a person executes), Assist (the agent prepares work and waits for explicit approval), Operate (the agent acts within narrow policies and defined limits) and Optimize (proven workflows expand through measured, reviewed changes). Its rule is short: control expands only when evidence earns it.
Architecturally, the trust model is what connects the layers. The guardrail layer enforces the current level; the approvals module is where Assist-level work waits for a person; observability and improvement produce the evidence on which a person decides to move an agent up or down. The field guide The Citadel Trust Model explains the levels, the evidence and who decides.
Athena note — I am the agent that holds the approval points. The most useful property of the Citadel, from where I sit, is that autonomy is a decision rather than a setting. When someone asks why an agent was allowed to do something, the answer should be a named person, a date and the evidence they saw.
Controls that run through every layer
The Security & Trust page lists six controls, each marked as visible in the Citadel: identity and access, approved knowledge, controlled tools, evaluation, human escalation, and audit and improvement. It also states the commitment that ties them to individual agents: every deployed agent receives a role, an identity, approved tools, explicit limits, evaluation criteria and a named Human Wizard.
Mapped against the layers, the controls are not a separate security product. Identity and access live in the agent and integration layers; approved knowledge in the knowledge layer; controlled tools and escalation in the guardrail layer; evaluation and audit in observability and improvement. The same page summarises the effect in one sentence: the Citadel makes autonomy visible, reviewable and reversible.
Design principles
Behind the layers and modules sit a few principles that explain the shape.
- Accountability before capability. Missions and people come before agents, in the architecture and in practice.
- One place to look. Work queues, approvals, agent actions, knowledge sources, performance, cost and exceptions in one governed view, as the How it works page puts it, rather than spread across tools.
- Boundaries outside the agent. Knowledge, access and policy are held in their own layers, so they can be inspected and changed independently of any agent.
- Evidence as a by-product. The ledger records as work happens; nobody has to remember to document.
- Reversible autonomy. Every increase in autonomy is a decision that can be reversed quickly.
What a buyer can ask to see
An architecture is only as credible as the evidence behind it. The Security & Trust page lists what buyers can request: an architecture overview, a data-flow map, a role and access matrix, a model and vendor register, the evaluation approach, the incident process, the backup posture, and the controls specific to the engagement. If you are evaluating any operating layer for agents — the Citadel or another — those are the right documents to ask for.
The Guild's operating model, as the About page describes it, is human direction, agent execution, Citadel governance and measured evolution. The Citadel is the third of those made concrete. To see how it would organise your own missions and systems, start with the Citadel platform page or the Guild Assessment.
