AI-Assisted Delivery Protocol — Case Study

A delivery process that cannot be skipped

Every consultancy has a delivery methodology. It lives in a wiki, it is taught during onboarding, and it is quietly abandoned the first time a deadline gets tight. Discovery gets compressed, the architecture decision never gets written down, tests get promised for "after the release."

This protocol makes that failure mode structurally impossible. The Architect's commands stay locked until a signed charter exists on disk. The Builder's stay locked until the solution document is approved. Not a reminder, not a checklist item — the tooling refuses to run.

Process discipline you cannot skip beats process discipline you have to remember.

Three plugins, one gated chain

Each plugin carries its own skills, tools and commands. Work moves down the chain only when the previous phase has produced a signed artifact.

The gate is not a checklist item. The Architect's commands do not run until a signed charter exists; the Builder's do not run until the solution document is approved.

Account Manager

Phase 1 · discovery

Stakeholder mapping, minutes of meeting, a working-backwards PR/FAQ, then the project charter. Ends at sponsor sign-off, which is the gate.

Architect

Phase 2–3 · solutioning

Feasibility check, functional design, architecture-pattern selection, infrastructure pattern, and an ADR behind every decision that closes off alternatives.

Builder

Phase 4 · build

Ticket-driven TDD. Each ticket becomes a build brief assembled from the solution document and the ADRs that govern it.

Skill library

Shared · versioned

Semver'd and eval-gated, so a change to shared behaviour is a release with a test result behind it rather than a surprise across every project.

Four sub-personas inside one ticket

The build loop is where AI-assisted development usually goes wrong: the model writes the code, then reviews its own code, and agrees with itself. Splitting the loop into adversarial roles is what stops that.

1QA writes the tests first. From the ticket's acceptance criteria, before any implementation exists. The suite must fail on first run — that failure is the gate to the next step. A passing test against no implementation is a broken test.

2Dev writes the minimum that passes. Nothing beyond the ticket. Scope creep is caught here rather than at review.

3Docs ship in the same PR. Never a follow-up commit that never comes — user docs, API docs and changelog move with the code that changed.

4A reviewer gates the merge, checking TDD order was genuinely followed, scope stayed inside the ticket, and coverage held.

Why tests must fail first

If the model writes tests after the implementation, it writes tests that pass — describing what the code does rather than what the ticket asked for. Requiring a failing run first is the cheapest available proof that the test encodes the requirement and not the implementation.

Five narrow reviewers rather than one broad one — each misses less inside its own lens, and running them concurrently costs the wall-clock time of a single review.

Five specialist reviewers then run in parallel on the diff, each with a single lens: missing permission checks, SQL injection vectors, personal data leaking into logs or responses, unsafe public endpoints, and untranslated user-facing strings. Critical or high findings block the merge.

Splitting them was deliberate. One reviewer asked to check everything checks nothing thoroughly; five narrow reviewers each miss less within their own lens, and they run concurrently so the wall-clock cost is one review, not five.

Drift is surfaced, not absorbed

The commercial failure mode of services work is not bad engineering. It is absorbing a hundred small unbudgeted asks until the margin is gone and nobody can point at when it happened.

A weekly sweep compares live work against the locked charter and drafts a change request when a ticket, a PR or a client ask exceeds the agreed scope. The judgement stays human — the detection does not depend on someone remembering to look.

Gates are cheap to add and expensive to retrofit

The phase gates went in after the plugins already existed, which meant reverse-engineering what each phase was supposed to produce before it could be locked. Building the artifact contract first — what does this phase emit, and what proves it is done — would have made the gates fall out naturally instead of being fitted afterwards.

The other lesson is about trust. Every agent here starts in draft-and-approve mode and only earns autonomy on the steps where a mistake is cheap and reversible. That ordering is not caution for its own sake; it is what makes the system usable on real client work rather than a demo.