Under the Hood

Same delivery engine, walked through one stage at a time — and this time, the reasoning is attached. Every diagram has a row of drawers under it. Open one and it answers the question a reviewer would actually ask.

The bind this answers

Cut cost and risk. Don't cut the team. Do it with AI.

The board wants delivery cheaper and faster. Risk wants fewer surprises and less technical debt sitting on the books. Neither is asking you to let go of the people who understand this business — that understanding is the one thing AI can't replace. The brief isn't "replace the team," it's "make the team you already trust produce dramatically more, with shorter feedback loops and near-zero accumulated debt, without losing anyone who knows why things are built the way they are." Everything from here on is the mechanism for that.

Time-to-launch

Parallel review instead of a queue — most of what used to wait in line now happens at the same time, off one design.

Feedback loops

QA checks against real existing scope before anything is built, not three sprints in — a sprint-long loop becomes a design review.

Technical debt

Every decision, every exception, every "why we did it this way" is on record — nothing gets rebuilt twice because nobody remembered the first time.

Prefer the narrative version first? Read The Bulletproof Delivery Team. Want the precise diagrams instead of drawers? See the Delivery Team Schematic.

These aren't hypothetical FAQs. Every question below is one that came up while this thing was actually being designed — why doesn't this go straight to the PO, what if the Architect and PO disagree, who's allowed to change this. If you're reviewing this as a PO, BA, Architect or QA lead, these are very likely your questions too. Click to open.

Before the walkthrough

Eight roles, one human

One Product Owner, seven agents. Teal is the human. Ink is an agent working alongside the team. A dashed border means it's isolated — it never sees the pitch, only the artifacts. A diamond is a real fork, not a formality. Every diagram from here on uses exactly this code.

Product Ownerhuman

Business Analystagent

UX Architectagent · conditional

Architectagent

QAagent · isolated

Risk Architectagent · isolated

Data Architectagent

Ask about the team

Why does domain knowledge stay with some roles and not others?

Because it's genuinely two different jobs. PO and BA carry the business vocabulary — what a request means, who's eligible, what the exceptions are. UX needs enough of it to design a journey a real user recognizes. QA needs enough to write a test that matters, and Risk needs enough to know what an attacker in this industry actually goes after. The Architect and Data Architect work one layer down, in features and capabilities — the same shape whether the domain is fintech, e-commerce, or utilities. That split is what makes the team reusable across every product, not just one.

Is the Architect completely domain-blind, then?

Not quite — it doesn't need business vocabulary, but it still needs the domain's constraint profile: compliance regime, consistency guarantees, latency and scale envelope, safety criticality. A financial reversal needs strict idempotency and an immutable audit trail; a utility change tolerates eventual consistency but can't fail silently. The Architect doesn't need to know what a "claim" means — just that this domain demands a 7-year audit trail before it designs anything.

Why is Risk drawn as more domain-aware than the Architect?

Threat models genuinely differ by industry — fraud vectors, data-breach vectors, and safety-critical failure modes aren't interchangeable. Risk sits closer to QA than to Architect and Data on the domain-awareness spectrum, even though all three are technical roles.

Before this ships to a team

Who's allowed to change the machine itself

Everything above governs how a request moves through the team. This governs how the team itself gets edited, once it's real people — POs, Architects, QA leads — training these agents by using them.

This is also where the headcount question actually gets answered. Every skill here has a human owner — not a supervisor rubber-stamping its output, the person who used to do this work full-time, now training the agent that represents it. The job doesn't disappear. It moves from doing the work to continuously making the system that does the work better — which is also the only reason this keeps improving instead of quietly calcifying the day it's switched on.

Role	Can edit	Can suggest	Validated by
Business Analyst	its own skill only	anyone, about anyone	automated — does it cover the vision completely — plus PO
UX Architect	its own skill only	anyone, about anyone	PO review
Architect	its own skill only	anyone, about anyone	PO review
QA	its own skill only	anyone, about anyone	manual — QA reports how it handled a case, PO reads and judges
Risk Architect	its own skill only	anyone, about anyone	PO review
Data Architect	its own skill only	anyone, about anyone	PO review

This is a maturity model, not a permanent restriction The ideal end state is fully decentralized — anyone can validate anyone's skill, peer-review style. That's not being built yet, because at low maturity it gets dangerously messy: a Risk agent's skill "validated" by someone with no risk judgment isn't validation, it's noise. Level 1 is human-gated — broad suggestion rights, narrow edit rights, the PO as backstop. Later levels loosen that as trust in the system builds.

Ask about governance

What stops a skill update from quietly making things worse?

The same regression risk that applies to any config drift: an edit that reads like an improvement but softens a real check. That's exactly why validation is required before an update goes live, and why it's manual for roles like QA — a report the PO actually reads, not a self-certifying agent.

How does versioning avoid the same bloat problem as an unmanaged CLAUDE.md?

Every update is a full rewrite of the live skill file — never an appended patch. The previous version is archived intact, referenced but out of the way, so the current skill never becomes a palimpsest of strikeouts where the real operative scope is buried under years of edits.

What happens when the PO starts a new request while agents are still finishing an old one?

That's fine — a human proposing new work will always outpace a multi-stage agent team finishing old work, and nothing here builds a locking or cancellation system to prevent it. If a newer request actually conflicts with one still in flight, that surfaces through the same Zone D escalation path as any other finding that changes the ask — not a new mechanism.

Does this actually work without a chat-only interface for non-engineers?

Technically, yes. Practically, it doesn't ship without one. Right now, using this means being comfortable inside a session — for a PO or Risk Architect to use it daily and confidently, the chat-driven front end is a need-to-have, just still sequenced for later in build order.

Has any of this been tested — a real Hook, a real isolated agent?

Not yet, deliberately. The mechanism is sound on paper and unverified in practice. The plan is step by step, foundation first — validating the base before adding floors, not rushing to build something that looks finished before the underlying trigger mechanics have actually been fired once.

Before this touches real cost

What stops this from running away

Everything so far explained the shape of the system — who does what, in what order. This is the layer underneath: the guarantees that make it safe to actually let Hooks fire agents against real files, unattended, at cost. In agentic-RAG terms, these are the parts that don't show up in a routing diagram but decide whether the diagram is trustworthy.

Tool contracts

Every artifact type has a schema, not just a folder — required fields, a fixed status enum. A write that doesn't conform never fires the next Hook. It sits invalid until fixed, never routed around.

The orchestrator

The Hook + status-field mechanism you've already seen through every zone is the orchestrator. "Why this agent, next" always has a one-line factual answer — a field changed value — never a guess about a model's reasoning.

Idempotency

Writes are keyed by ID and overwrite — never duplicate. Before doing anything, a skill checks whether its own output for this ID already exists. A retried Hook can't create a second, competing artifact.

Termination conditions

Every loop is bounded — 3 unresolved cycles on the same ID and it stops auto-looping, flags to the PO as stuck. That's the system recognizing it needs a human, not the system failing.

Pipeline evaluation

A clean final decision doesn't prove every stage was sound. Each write gets checked for groundedness, relevance, completeness, latency/cost, and schema accuracy — not just whether the PO approved it at the end.

Ask about reliability

Isn't a folder convention basically the same thing as a schema?

No — a convention says where something goes. A schema says what's required to be in it, and what happens when that's missing. capabilities/<id>.md requires id, traces_to, status, owner, last_updated — a write missing any of those, or using a status value outside the fixed enum, is a failed write. It doesn't fire the next Hook, and it doesn't get silently accepted as close enough.

Why call a Hook mechanism an "orchestrator" instead of building a real LLM router?

Because a state-triggered orchestrator is auditable in a way an LLM router isn't. An LLM router's answer to "why did you call QA next" is a probabilistic explanation you have to trust. This system's answer is always the same shape: technical-design/CAP-04's status became ready-for-review, and three Hooks watch for exactly that. No judgment call to second-guess.

What actually happens if the same Hook fires twice for one write?

Nothing duplicates. Every write is keyed by its artifact ID and overwrites that ID's file rather than appending a new one — there's no CAP-01-2. Before a skill does its work, it checks whether its own output for that ID already exists at the target status; if it does, the second firing exits without redoing anything. Even decisions/, the one append-only log, carries a unique decision_id so a retry can't log the same decision twice.

Why 3 cycles as the termination bound, and not some other number?

Honestly — it's a starting default, not a measured value. Nothing has run for real yet to justify a different number. The plan is to revisit it once real cycle-count data exists: if capabilities that eventually succeed mostly resolve in 1–2 cycles, 3 is generous; if legitimate cases routinely need 4 or 5, the bound is cutting off work that would have converged. That data falls out of decisions/ and the per-stage latency tracking on its own — nothing extra needs building to capture it.

How do you actually measure something like "groundedness" for a QA finding?

The schema requires it directly — every qa-regression/ and risk-findings/ entry carries a citation field naming the exact artifact and section a finding is grounded in. A finding with no citation, or one whose citation doesn't actually say what the finding claims, fails groundedness — regardless of how plausible the finding reads on its own.

That's the full mechanism. For the version you can actually share — The Bulletproof Delivery Team — or the precise diagrams on their own, the Delivery Team Schematic.

Step 1 of 8