Owner: CoE Lead. Input: Retirement trigger fired — KPI failure, owner departure, replacement, ROI below break-even for 2 quarters, security incident, or scope no longer relevant. Sub-steps:

1. Announce retirement to the affected department.
2. Revoke the agent's identity and credentials in the IdP.
3. Disable the agent in the orchestrator.
4. Archive the audit logs per retention policy (do not delete prematurely if regulation requires retention).
5. Archive the Agent Card and post-mortems in the source repo.
6. Mark the registry entry as Retired with a retirement date and reason.
7. Notify Procurement if the agent's retirement allows downgrading any vendor / LLM commitments.
8. Update affected workflows: the humans who relied on the agent need a path forward (back to manual, replaced by another agent, replaced by a deterministic rule, etc.).

Output / gate criteria: Registry marked Retired; identity revoked; logs archived; affected users informed and re-pathed.

Decision branches: none — this is a clean shutdown.

Skip-this-step risk: Zombie agents. Credentials lingering. Audit logs growing forever. New agents accidentally inheriting old scope.

Worked example — "Accountant in Finance"

Walking the example through Part B to show how the steps land in practice. Imagine the request: "Our AP accountant spends 6 hours a week reconciling vendor invoices against POs in NetSuite. Can we use AI to help?"

The point of the worked example: no part of this workflow was "go into n8n and build something for the accountant." The build step (Step 9) is somewhere in the middle, with eight steps of governance before it and seven steps of operation after it. That ordering is the whole point of the framework.

Quick-reference checklist — Part B (the per-agent flow)

A printable, single-sheet version of Part B.

BEFORE TOUCHING n8n / ANY BUILD TOOL:

[ ] Step 1 — Discovery
    - workflow documented
    - pain point identified
    - "is this an AI problem?" filter applied
    - "is this an agent?" filter applied
    - value + risk briefly estimated

[ ] Step 2 — Intake submitted
    - registry entry created, Status = Intake

[ ] Step 3 — Triage + risk classification
    - 3 risk drivers tagged
    - tier assigned (Low / Medium / High)
    - EU AI Act check done
    - risk-appetite check done

[ ] Step 4 — Approval decision
    - right approvers signed off (per tier)
    - KPI defined
    - retirement criteria defined
    - Agent Owner + Builder named
    - Status = Approved

[ ] Step 5 — Agent Card written
    - 13 sections complete
    - committed to source repo
    - linked from registry

[ ] Step 6 — Security review (Medium+/High)
    - threat model (STRIDE + MITRE ATLAS + OWASP GenAI)
    - DLP plan
    - red-team scenarios planned

[ ] Step 7 — Responsible-AI review (Medium+/High)
    - 10-item checklist complete
    - signed and attached

[ ] Step 8 — Identity + access provisioned
    - unique agent identity in IdP
    - least-privilege credentials
    - revocation procedure tested

NOW YOU CAN BUILD:

[ ] Step 9 — Build (in dev only)
    - approved stack used
    - 3 guardrail layers wired
    - 5 control mechanisms wired
    - observability live from day one
    - runbook written

[ ] Step 10 — Evaluation
    - golden dataset run
    - red-team scenarios run
    - prompt-injection probes
    - bias probes (if applicable)
    - eval report signed

[ ] Step 11 — Pilot
    - limited users (1–5)
    - daily monitoring week 1, weekly weeks 2–6
    - 5 monitoring signals tracked
    - pilot success criteria met

[ ] Step 12 — Pilot-to-prod gate
    - 10-item gate checklist
    - CoE Lead signs off

[ ] Step 13 — Production launch
    - promotion through CI/CD
    - prod identity + rotated creds
    - dashboards live
    - launch communicated
    - 30-day review scheduled

ONGOING:

[ ] Step 14 — Continuous monitoring
[ ] Step 15 — Quarterly review
[ ] Step 16 — Retirement (when triggered)

Anti-patterns — what skipping each step actually looks like

What this gives us

If Part A is done once and Part B is followed for every agent, every agent in the company will be:

• Tracked — every one has a registry entry, an Agent Card, an owner.
• Tiered — risk-classified, with proportionate review depth.
• Owned — single named human owner with accountability.
• Identified — unique IdP identity with least-privilege scoped credentials.
• Reviewed — security and responsible-AI sign-off before any production launch.
• Governed at runtime — three guardrail layers and five control mechanisms enforced in execution, not in PDFs.
• Monitored continuously — five monitoring signals running live, not at quarterly audits.
• Measurable — KPI defined at approval, ROI tracked quarterly, retirement criteria pre-agreed.
• Reversible — kill switch, rotation, revocation, retirement procedure documented.

That is the operational definition of "complies with the framework." If a request can't pass this workflow, it doesn't get built. If a built agent can't keep passing this workflow, it gets retired.

Open questions / what this workflow does not yet cover

Same set as framework.md §33 — items deliberately not pinned down in v1:

• Multi-agent chains (one agent calling another). Treat each as a separate agent through Part B for now; a follow-on multi-agent workflow doc is needed.
• Prompt change management (Dev/Test/Prod for prompts vs. code-review style PRs).
• Cost-allocation models (showback / chargeback / central pool).
• Citizen-developer self-service path — what does a "low-risk Step 9" look like when the Department Champion builds it themselves on a CoE-blessed blueprint?
• Concrete templates: Agent Card, intake form, post-mortem, retirement checklist as separate files in this folder. Next deliverable.