Describe the outcome. The system structures the work.
Agentic Stack turns a business need into a structured, governed execution plan — it identifies the right process, mobilizes the required expertise, applies quality controls, and stops when the conditions for a reliable result are not met. You describe what you need; the system decides how it gets done.
The technology stays underneath. Your business process stays in control. No install needed to understand the approach — run it yourself, locally, when you're ready.
Try it on a real business case
Explore how Agentic Stack qualifies a need, selects the right process, structures the work and controls the result — on real recorded runs. Then run it yourself locally, on your own Claude subscription, when you're ready.
See how it works
You don't browse a catalog of 38 agents and 10 workflows and wire them together. You state
a business need in plain words, and the system's qualification-and-routing layer
(the WF-000 dispatcher) decides what happens to it. On real recorded runs, it does three
things: it routes, it refuses, it controls.
1 — It turns your need into an execution plan
You start from a request in natural language. The system checks it is defined well enough, identifies the most appropriate business process (workflow), and builds the plan.
"We're launching an AI customer-support assistant — a RAG chatbot for an insurer. We need to scope it, design the solution, build it, test it, and get it ready to deploy."
It matches this to WF-003 — AI Application Launch and assembles a 7-step plan, with the cost case and the security review carried inside the run rather than bolted on after:
WF-003 — the plan the system built · 7 / 7 passed, live
| Phase | What it delivers | Verdict |
|---|---|---|
| Business case | Value and stakes framed | ✓ pass |
| Specification | The need clarified | ✓ pass |
| Architecture | The solution scoped | ✓ pass |
| Build | Implementation | ✓ pass |
| QA | Quality control | ✓ pass |
| Deployment | Production-readiness | ✓ pass |
| Security | Risk review | ✓ pass |
You don't have to know which expertise to mobilize, or in what order. The system builds the plan from your need — and can prove which agents ran, at which catalog version. See the run →
2 — It can also say a request isn't qualified
A useful system doesn't only know how to produce. It knows when it cannot produce reliably. From the live routing run:
"We'd like a commercial proposal for this prospect." — but no tender was ever issued.
The deliverable looks like the pre-sales process (WF-006). But that process starts from a received tender, and this request has none. So the system answers:
WF-000 — dispatch outcome
✗ Request not qualified — NO_MATCH. No process fits this
request as stated. The system names the nearest one (WF-006), explains why it cannot be
used, and stops — instead of building a proposal on a stage that never happened. Routing
accuracy on the recorded test set: 19 / 20.
Not launching a plan on an incomplete scope is a saving, not a limitation. See the dispatcher →
3 — It controls the result before calling it done
The controls are not added after the deliverable is produced — they are built into the
process. In the live AI Act / GDPR audit, six steps passed, then the counter-review
clearance gate answered returned (five documented reservations, a bias log, ISTQB exit
criteria), so the report was withheld by design:
WF-008 — control before delivery
| Step | Verdict |
|---|---|
STEP-01 … STEP-06 |
✓ passed |
STEP-06C — counter-review clearance |
✗ returned |
STEP-07 — final report |
⟲ withheld |
The system can produce a result, find that it does not meet the required criteria, and prevent its delivery. The goal is not to produce more content — it is to produce results that are more structured, controllable and usable. A gate that can never say no is not a gate. See the run →
Try it on your own case
Run it on your own problem. Download the agentic catalog and the runtime, then run them locally on your own Claude subscription. Your data stays on your machine, and no API key is needed — the runtime runs on subscription auth and refuses an API key by design.
A business reader can stop here. If you work in a coding agent (Claude Code, Cursor, …), paste the instruction below and replace the bracketed part with your problem — your own agent does the setup, you paste one instruction.
Act as my coding agent for a local, hands-on trial. Everything runs on my machine, on my
own Claude subscription — do NOT set ANTHROPIC_API_KEY: the runtime refuses an API key by
design and expects subscription auth.
1. Clone these two public repositories side by side, in the same parent folder:
git clone https://github.com/guyhui01/claude-agentic-runtime
git clone https://github.com/guyhui01/claude-agents
2. cd claude-agentic-runtime && npm install
3. Read src/dispatch/run-dispatch.ts and test/dispatch-run-live.test.ts to learn how the
WF-000 dispatch is invoked live: runDispatch(brief, { sidecar }), with the real sidecar
loaded from ../claude-agents/sidecar.json.
4. Turn MY PROBLEM (below) into a dispatch brief with the fields the schema expects —
need, domain, expectedDeliverable, constraints (a list), context — then run the dispatch
on it live and show me the outcome verbatim:
- ROUTED -> which workflow, which agents, and the execution plan
- NO_MATCH / REJECT_INCOMPLETE / PARAMS_MISSING -> the honest refusal, and exactly
what was missing or out of scope
Then STOP at the plan. Do NOT run a billed workflow spine without my explicit go-ahead.
5. If it routed and I then say "go", run the routed workflow's live spine and show me each
step's verdict — including any gate that returns the deliverable for rework instead of
shipping it.
MY PROBLEM:
[ In a few sentences: what you need, in what domain, the deliverable you expect, your hard
constraints, and enough context to act. Be specific — a vague brief is meant to be
refused, not guessed at. ]
The run is billed to your subscription (a routing call, then any spine you approve). Nothing is sent to us; the trial is entirely local.
What does this mean for your work?
The same behavior — qualify, route, structure, control — reads differently depending on where you sit:
- Product Owner / Business Analyst — turn a business request into structured scoping: a process, deliverables, and control criteria.
- Agile project manager — structure a project's steps and secure the control points, without wiring each AI intervention by hand.
- Sales engineer / ESN — qualify a request faster, structure a response, and surface the missing information before committing a production process.
- HR / Talent — formalize and standardize complex processes, from qualifying the need to evaluating and controlling the result.
- Management — turn business expertise into reproducible, controllable, traceable processes.
You just watched the system qualify what it can, refuse what it cannot, and withhold what doesn't clear.
That behavior — not a collection of agents — is the point. It is what a real engagement builds on your processes, your data, your governance. Tell me what you are working on.
What this trial does not do
So the line stays honest:
- It is an evaluation environment, not a hosted production service — and never a self-serve substitute for the engagement.
- It demonstrates on your problem, but stops at the execution plan (and a single spine if you run one). It is a demonstration, not a delivery.
- It runs the public catalog and runtime as they are — not tuned to your domain, your data, or your governance rules.
- The engagement is where the expertise is fitted to your processes and the outcome is actually delivered and owned.
Annex — run the AI Act / GDPR audit on your own case (WF-008)
You saw this run withhold its report above. To watch the fail-closed halt firsthand — or run it on your audit — paste this into your coding agent (same two repos, same subscription-only auth):
Same setup as the trial above (both repos cloned, npm install done, subscription auth — no
ANTHROPIC_API_KEY). Run the AI Act / GDPR compliance audit workflow (WF-008) live, following
the pattern in test/wf-008-run-live.test.ts, but threading MY AUDIT CONTEXT (below) into the
run. Show me every step's verdict, and at the counter-review clearance gate (STEP-06C) show
me whether the auditor answered `cleared` or `returned` — and, if `returned`, that the report
step (STEP-07) was withheld by design.
MY AUDIT CONTEXT:
[ Describe the AI system to audit: its purpose, the data it uses, who it affects, the
jurisdiction, and any known risks. ]
Read the recorded run in full on the live proofs page.