The Failure This Stage Prevents
They do not collapse. They decay quietly.
How these programmes actually die
The Operating Cadence
| When | What | Who |
|---|---|---|
| Every change | Knowledge Update writes back. Memory diffs reviewed in the PR like code | Author + reviewer |
| Weekly | Rejection log reviewed. Recurring rejections become pattern or instruction fixes | Agent maintainers |
| Weekly | CI gate health: pass rate, flaky tests quarantined not ignored, build time | Tech lead |
| Monthly | Metric pack against the original baseline. Cycle time, rework, escaped defects, bus factor | Tech lead |
| Monthly | Steward forum — what memory is missing, what agents keep getting wrong | All stewards |
| Monthly | Access review — credentials, agent scoping, audit log spot check | Security owner |
| Quarterly | Governance review — autonomy levels, restricted-zone register, disclosure position, retention | Leadership + domain owners |
| Quarterly | Golden dataset refresh — new scenarios from real defects found that quarter | Domain owners |
| Quarterly | Kill-switch and rollback drill, actually run | Release manager |
Health Signals
Four leading indicators, each with a defined response
Acceptance rate falling
Drafts increasingly rejected. Almost always stale memory, not a worse model. The codebase moved and the patterns file did not. Response: memory audit on the affected modules.
Rework rate climbing
Drafts arrive fast and cost more in review. Response: find the agent, replay recent failures, demote to L1 until it is fixed.
Review agent catch rate falling
Human reviewers finding things it should have caught. Response: feed those comments back as new rules. The review agent should get stricter over time, not looser.
The gate getting skipped
The clearest early warning. Someone is under pressure and the gate is in the way. Response: find out whether the build is too slow. Usually it is. Fix that.
Take the skipped gate most seriously
Every gate here will be inconvenient at exactly the wrong moment eventually. When someone routes around one, the useful question is almost never “why did they break the rule.” It is “what made the rule unaffordable that day.” A gate that is too slow gets skipped whatever the policy says.
Where It Goes Next
Options once the fleet is stable, roughly in value order
- Sibling products — n.prime, n.image, n.feed. Different stacks mean adapting the fleet, not copying it. The memory structure carries over directly
- Vector-indexed memory — once the Markdown base is big enough that retrieval, not authorship, is the constraint
- Performance regression in the pipeline — for n.tasc, correct but slower is still a defect
- Client-facing release notes — the UAT pack is most of one already. Some clients will want it
- Regulatory horizon scanning — extend the Regulatory Watch Agent from reacting to circulars to flagging drafts and consultations early
- Debt paydown as a standing lane — the Stage 0 non-blocking backlog, worked through with the fleet now that there is a test net under it
Success at twelve months
A requirement arrives. Any available engineer — not a specific one — can spec it, see what it touches, build it with the fleet, prove nothing regressed, and hand a complete UAT pack to a tester. The cycle time is a number you can quote to a client. Generated code clears the same gate as hand-written code, and everyone knows what that gate is.