The Approach — The Worked Example

How a Change Flows

One real requirement, walked end to end through all fourteen agents

The Requirement We Will Follow

A realistic n.tasc request, in the form it usually arrives

As received — a call note from a client operations team

“When a single client's transactions for the day cross a set value limit, our operations team wants to know straight away. Today they only find out from the end-of-day exceptions report. They want it flagged on the live screen and an email to the operations desk. The limit should be configurable per client group, not hard-coded.”

That is a normal request. It touches a business-critical rule engine, the alerting path, the React screen, a backend API and a configuration table. It is a good example because it is neither trivial nor a rewrite — it is the kind of change that fills most of your sprints.

?
Days today — measured in Stage 0
14
Agents involved
6
Human gates
0
Steps where an agent decides alone

The Route, Before We Walk It

Fourteen steps, six gates. Orientation before the detail.

Where the agents fire and where a person decides

1 Spec ✓ PO 2 Regulatory (idle here) 3 Architecture 4 Contract ✓ Tech lead 5 Backend 6 UI 7 Data 8 Review ✓ Developer 9 Charact. 10 Test 11 Critical logic ✓ QA + domain 13 Release Steps 12 and 14 run alongside: Bug Triage and Knowledge Update Six gates. A person decides at every one, with their name on it. Blue = agent · Indigo = review agent · Teal = human gate · Red = restricted zone

Step by Step

Each agent, what it gets, what it produces, who signs it

1

Spec Agent

agent

Reads the call note plus .ai-memory/. Writes a spec: what changes, why, and acceptance criteria in testable form. Flags what it does not know rather than filling the gap.

Produces: a spec with 7 acceptance criteria — limit configurable per client group, evaluation on every new transaction, flag appears on the live screen within N seconds, email to the mapped operations desk, no duplicate alert inside a cooling window, behaviour when the client has no transactions yet, behaviour when the upstream feed is stale.
Open questions raised: what is the cooling window? Does the flag clear when the value falls back under the limit, or stay until acknowledged?
✓

Gate — Product Owner

human

Answers the two open questions, adjusts one criterion, approves. Ten minutes on a draft instead of an hour on a blank page. The answers get written back to memory, so the next alerting request starts from them.

Result: approved spec, 8 acceptance criteria, no unknowns left open.
2

Regulatory Watch Agent

agent — not used here

Idle for this request. It runs when the trigger is a circular rather than a client ask: it reads the circular, states the obligation, and maps it to the n.tasc modules that implement that area today. Same pipeline from step 3 onward.

When it does run: obligation summary, impacted modules, draft spec, and the compliance deadline tracked from the day the circular lands.
3

Architecture & Impact Agent

agent

Reads the approved spec against the real solution. Produces the change map: exactly which backend services, API endpoints, React components, database logic and config tables are in scope, and what stays untouched.

Produces: the limit-check service gains a limit-driven branch · new rule row in the alert rule table · the alert rule evaluator extended · the alert dispatcher email template · the daily-value query returns the client's running total · one React component on the live screen · one config screen.
Flags: RESTRICTED ZONE the limit calculation is business-critical logic inside the restricted area. Step 11 becomes mandatory.
4

API Contract Agent

agent

The React screen reads through the API, so the contract gets designed before anyone writes an implementation. It diffs the proposed shape against what exists and says whether anything breaks.

Produces: two additive fields on the existing alerts payload, one new query parameter. Verdict: additive, non-breaking. No consumer needs to change.
✓

Gate — Tech Lead

human

Reads the change map and the contract. Adds one thing the agent missed: the existing cooling-window helper in the alerting module should be reused rather than a new one written. Approves.

Result: approved change map. The reuse note goes into memory as a pattern, so the agent applies it next time without being told.
5

Backend Agent

agent

Implements on a feature branch, following the conventions already in those projects. Reuse first: it has to find the existing cooling-window helper and the existing evaluator interface before adding anything new. It cannot touch a file the change map did not authorise.

Produces: limit branch in the limit-check service, API field additions, evaluator extension, dispatcher template binding, config binding — on a branch, with a written note of what it did and what it deliberately left alone.
6

Web UI Agent — React

agent

Works in the React conventions already in the codebase: existing components, hooks, state management, routing and the screen's refresh pattern. Follows the screen's own conventions for alert prominence, because an operations user under time pressure reads it.

Produces: alert component on the live screen, limit config screen, the hooks and state wiring, the route for the new screen.
7

Data & Migration Agent

agent

Writes the schema and database logic changes as migration scripts. It reads the live schema, so it never guesses a column name. It never runs anything against any environment.

Produces: forward migration for the limit config column, rollback script, the updated daily-value query, and a note on the index this query now needs.
8

Code Review Agent

agent

Reviews the branch before a human opens it. Checks it against your standards, ESLint on the React side plus the backend's linters and static analysis, the change map, and a security pass. This is the step that makes the phrase “production-ready” mean something.

Found: a null dereference on the no-transactions-yet path · a limit comparison using > where the criterion says “crosses” (should be >=) · the email template not HTML-encoding the client name.
Result: three fixes applied, re-checked, then handed to the developer.
✓

Gate — Developer

human

Reads every line. Rewrites the dispatcher binding because the agent's version, while correct, does not match how the team wants that layer structured. Commits under their own name. The code is theirs.

Result: committed branch. The structural preference goes into memory as a pattern.
9

Characterization Test Agent

agent

The limit-check module had thin coverage. Before the change is trusted, this agent pins the module's existing behaviour so any unintended change shows up as a failure.

Produces: 34 approval tests over the module's current outputs.
Also raised: one existing behaviour that looks wrong — the daily total currently counts an amended transaction twice. Sent to the steward as a finding, not frozen into a test.
10

Test & QA Agent

agent

Writes a test per acceptance criterion, plus the cases n.tasc needs and people forget under deadline pressure.

Produces: 8 criterion tests · boundary tests exactly on the configured limit, just under and just over · empty data set · missing and stale upstream feed · expired limit records · duplicate suppression inside the cooling window · a Playwright journey for the on-screen alert · synthetic test data for all of it.
11

Critical-Logic Verification Agent ⚠

agent — restricted zone

Triggered automatically because step 3 raised the restricted-zone flag. Re-runs the golden datasets against the changed limit-check code and reports every difference from the frozen reference. It cannot mark anything as passing.

Produces: divergence report. Six scenario families identical. One shows a difference in the daily total for a client with amended transactions — traced to the double-count behaviour flagged at step 9.
✓

Gate — QA Lead + Named Domain Owner

human

QA adds two exploratory cases the agent did not think of. The Domain Owner rules on the divergence: the double-count is a pre-existing defect, not caused by this change, so this change ships and the defect is raised separately. That call is a person's, with their name on it.

Result: approved. One new defect raised. The golden datasets get a new scenario family for the double-count case.
12

Bug Triage Agent

agent

Picks up the defect raised at the gate. Locates the likely code, drafts a reproduction, and writes the ticket in the shape your team already uses. It does not fix anything — that is a separate, prioritised piece of work.

Produces: a defect ticket with suspect files, a failing test that reproduces it, and a severity recommendation for QA to confirm.
13

Release & UAT Pack Agent

agent

Assembles the release in the standard shape. What changed and why, what to test, known limitations, the rollback plan, and the migration scripts to run. Then the pipeline deploys to your UAT.

Produces: UAT pack — change summary, the 8 acceptance criteria as a tester checklist, the new config screen walkthrough, the known double-count defect noted as out of scope, rollback steps including the down migration.
✓

Gate — Release Manager, then UAT

human

Approves the pack. The tester opens a UAT environment already knowing what changed and where to look, instead of working that out first. Sign-off has a name on it.

Result: UAT signed off. Ready for the client's own acceptance on their schedule.
14

Knowledge Update Agent

agent

Writes back everything the run taught the fleet, so the next request starts from a better position than this one did.

Writes: the cooling-window reuse rule · the dispatcher structure the developer preferred · the two PO answers on cooling windows and alert clearing · the new golden dataset family · the limit-check module doc, now that it has been read properly.

What Actually Changed About the Work

Read down the right-hand column. The human decisions are all still there.

The same request today
  • PO writes the spec from a blank page, misses the stale-feed case
  • Developer reads code for half a day to work out the blast radius
  • Contract designed while implementing, so it changes twice
  • Code written by hand across four layers
  • Review waits for a free reviewer, then catches two of the three defects
  • Tests written if the deadline allows. Boundary cases usually not
  • Limit-logic change verified by reasoning, not against a reference
  • Release notes written by hand the evening before
  • Nothing learned is written down anywhere
→
The same request through the fleet
  • PO edits a draft and answers two questions. Stale feed is a criterion
  • Change map is computed and reviewed in minutes
  • Contract agreed and signed before implementation starts
  • Four layers drafted, then read line by line by the developer
  • Review agent catches three defects before a human opens the PR
  • Boundary, zero and stale-feed cases generated as a matter of course
  • Golden datasets catch a real pre-existing defect nobody had found
  • UAT pack assembled in the standard shape
  • Five things written back to memory for next time

The honest reading of this walkthrough

Every gate is still a person making a decision, and the developer still rewrote part of the generated code. That is the design. What moved is the work either side of the decisions: the drafting, the searching, the boilerplate, the routine test cases, the release paperwork. On this kind of change that is most of the elapsed time — but we will not know your split until Stage 0 measures it.

The step that surprises people

Step 9 and step 11 found a defect that had nothing to do with the requested change. That happens often when you first put a net under untested business-critical code. Budget for it: the first characterization pass on a module usually turns up things nobody had a reason to look at.