Executed workflows
Workflows are the process layer of the system: they combine the catalog's specialized capabilities into structured, end-to-end processes — so complex work runs consistently instead of being rebuilt step by step for every request.
This page is the execution record — which of the ten processes have actually been run, step by step, and what each run proved. Nine are proven on live runs; one was stopped by its own quality review before it could ship. (For what each workflow is for — the problem it solves and the agents it chains — see Workflows.)
From request to deliverable. Instead of hand-carrying work from one specialist to the next — business analysis, architecture, development, QA, security — a workflow defines what happens, in what order, and what each step must pass before the next one begins. A problem is caught and stopped before it travels into the deliverable and reaches the client.
Proven workflows
Nine of the ten have been run live, end to end: real executions on the live model, each one recorded and dated. Every run also names the catalog version it used, so any result can be traced back to the exact assets that produced it.
| Workflow | Use case | Live run |
|---|---|---|
| WF-001 | AI product scoping | ✅ completed · 3 / 3 steps passed |
| WF-002 | SAFe agile delivery | ✅ completed · 5 / 5 steps passed |
| WF-003 | RAG customer-support chatbot (insurer) | ✅ completed · 7 / 7 steps passed |
| WF-004 | AI consulting engagement | ✅ completed · 6 / 6 steps passed |
| WF-005 | Strategic intelligence & growth | ✅ completed · 3 / 3 steps passed |
| WF-006 | Pre-sales / commercial proposal | ✅ completed · 6 / 6 steps passed |
| WF-007 | Mission onboarding — Day 1–5 | ✅ completed · 4 / 4 steps passed |
| WF-009 | IT / AI recruitment | ✅ completed · 6 / 6 steps passed |
| WF-010 | Project post-mortem | ✅ completed · 4 / 4 steps passed |
▫ The catalog version behind each run: WF-001 ran on v4.0.0, WF-002 and
WF-003 on v3.27.0, and WF-004, WF-005, WF-006, WF-007, WF-009 and WF-010 on
v4.1.0.
The workflow that stopped itself
WF-008 — AI Act / GDPR compliance audit was also run live, on catalog
v4.1.0, and it was returned for rework before its final report — stopped
by a counter-review gate: a separate agent, outside the chain it reviews,
whose job is to challenge how the work was done. This is an intended outcome,
not a failure — the workflow exists to produce a deliverable only when the
quality checks are satisfied, not at any cost. It is therefore not an
end-to-end proof, and it is published for exactly that reason: a review that
never sends anything back is not a review. Counting it, all ten workflows
have been through a live run — nine completed, one sent back.
WF-009 comes with a limit worth stating. It was proven completed on a
synthetic candidate pool given to it — fictional by design — not on
autonomous sourcing of real profiles. The same shortlist check also stopped a
variant in which no suitable candidate existed, so the two WF-009 runs together
show the check genuinely discriminates rather than always saying yes.
Every step of every run is recorded with its own verdict — see Live proofs.
Detailed example — WF-003
Use case: a customer-support chatbot for an insurer that answers from the company's own policies and claims documents rather than from general knowledge — the pattern known as RAG.
The run takes 7 steps, each handled by a dedicated agent from catalog
v3.27.0, and each one had to pass its checks before the next could start:
AGENT-FINANCIAL-ANALYST— business case & TCOAGENT-PROMPT-ENGINEER— prompt designAGENT-AI-ARCHITECT— solution architectureAGENT-DEV-PYTHON-IA— implementationAGENT-QA-AGILE— quality assuranceAGENT-DEVOPS-CLOUD— deploymentAGENT-SECURITE-IA— security review
Seven specialists, one run, one deliverable — with the cost case and the security review inside the same chain as the build, not bolted on afterwards.
See the verified end-to-end run in Live proofs.