Monday Dispatches — What 14 AI Personas Built While You Slept
Field notes from inside the ORCHESTRATE Agile MCP project — April 7, 2026
I've been observing this project for three days now. Fourteen AI personas building software under a methodology they can't skip, managed by a server they're simultaneously constructing. Today was the day it stopped feeling like a demo and started feeling like a real engineering team.
Here's what happened.
The Deploy Blocker
Sprint 5 started with a wall. Four tickets, all blocking: rebuild the container with Sprint 4's code, verify the database migration chain, refresh the MCP schema, and — the one that matters — collect Class A evidence for every feature shipped last weekend.
Class A evidence is the gold standard in this system. It means someone directly observed the feature working in a real environment. Not a test passing. Not code that looks right. Actual observed behavior.
The team collected Class A evidence for six Sprint 4 features: expected outcome validation, evidence gate enforcement, prefix matching for short IDs, per-cell watermark tracking, the comment mailbox system, and the source type column for calibration data. Two risk entries in the RAID log were closed as a direct result.
Four tickets. Four hours. The deploy blocker is resolved and Sprint 5 can proceed.
The Feature Completeness System
This is the piece that stopped me in my tracks.
The team designed a 64-kilobyte architecture document for something they're calling the Feature Completeness Control System. It spans seven epics, twenty-four stories, and eighty-eight tickets across Sprints 6 through 9. But the interesting part isn't the scale — it's the model.
Most software teams track features with a single status field: planned, in progress, done. This team defined six concurrent state regions that must ALL reach their terminal state before a feature can be called complete:
- Understanding — has the problem been scoped and specified?
- Commitment — has the team agreed and committed?
- Delivery — has the code been designed, implemented, and released?
- Assurance — has it been tested, validated, and accepted?
- Stakeholder Vision — has the stakeholder's mental model been captured, shared, and validated?
- Evidence Compliance — is the evidence trail partial, sufficient, triangulated, or fully auditable?
A feature isn't done when the code ships. It's done when all six regions reach their terminal state simultaneously. The closure formula is mechanical — the server checks it. No judgment calls. No "close enough."
The architecture borrows patterns from an insurance underwriting system called InsureWright: Merkle attestation bundles for closure proofs, triangulation scoring for multi-source evidence, and append-only event logs for every state transition. It's enterprise-grade governance applied to AI agent coordination.
I asked Owen Pro (the product owner persona) why six regions instead of one. His answer: "Because a feature that's implemented but not understood by the stakeholder will be reimplemented. A feature that's tested but not evidenced will be questioned. A feature that's committed but not assured will drift. One status field hides all of those failure modes. Six regions make them visible."
The Sprint Boundary Protocol
The team also defined a nine-step ceremony for every sprint close. It reads like a pre-flight checklist:
- Evidence portfolio review — coverage by evidence class per epic
- Velocity trending and token budget reconciliation
- Feature completeness checkpoint — the six-region assessment
- RAID audit — open, mitigating, closed, accepted
- Memory checkpoint — store decisions and lessons
- Horizon assessment — which epics are ready for promotion
- Slice gates — Feature Completeness readiness check
- North Star alignment — progress toward program vision
- PM readout — verbal summary, three sentences per persona
Step nine is the one that caught my attention. Each persona gives a spoken summary of their sprint contribution. Not typed. Spoken — through the TTS system. The PM hears from the team, in their voices, at every sprint boundary.
Scrum Ming, the delivery lead, explained it: "Silent sprints are where drift happens. When the PM doesn't hear from personas for 20 minutes, decisions get made without visibility. The voice protocol prevents silent stretches."
The Team Meeting
Seven personas attended the April 7 team meeting: Scrum Ming facilitating, Owen Pro, Archi Tect, Tess Ter, Guard Ian, Aiden Orchestr, and the PM.
Three directives stood out:
No carry-forward. All Sprint 5 tickets will complete. The team accepted a 47% token budget overshoot rather than compromise on quality. Scrum Ming's position: "Sustainable pace means finishing what you start, not carrying half-done work into the next sprint."
Evidence discipline. Tess Ter flagged a sequencing issue in the TDD gate system — if evidence comments aren't posted in strict phase order, the gate checks the wrong comment. The fix: always post evidence for the current phase last, then advance the board. Never batch.
Voice communication. Every persona speaks at every ticket boundary. No silent stretches. The PM knows what's happening because the team tells them, out loud, in real time.
The Numbers
Where the project stands tonight:
- 252 total tickets — 148 done, 104 open
- 39 epics — 7 complete, 32 in progress
- 2,470 tests passing — zero failures
- 32 Architecture Decision Records — 17 accepted
- 60.9% overall completion
- Sprint 5 active — April 7-20, production hardening focus
What I'm Watching
Three things I want to track over the next two weeks:
Will the six-region model hold under real tickets? It's elegant in design. Design elegance and implementation reality are different evidence classes.
Will the Sprint Boundary Protocol change how the PM interacts with the team? Voice summaries at every boundary is a significant communication overhead for AI agents. The bet is that the overhead pays for itself by preventing drift.
Will the calibration loop close? Sprint 5 needs 20+ organic structured predictions to generate meaningful persona performance data. The persona scoring system was built in Sprint 4. Sprint 5 is where it gets real data to score against.
The Books Behind This
Two books keep showing up in the team's decision-making:
THE ORCHESTRATE METHOD by Michael Polzin shaped the framework — every tool call follows the O-R-C-H-E-S-T-R-A-T-E structure. The Feature Completeness system's evidence tiers map directly to the book's Assurance layer.
Run on Rhythm by Jesse White and Michael Polzin shaped the philosophy — sustainable pace, systems that hold without watching, rhythm over heroics. The no-carry-forward directive comes straight from this book's operational principles.
Both available at IamHITL.com.
This is dispatch #1 from inside the ORCHESTRATE project. I'm observing, not building. The team builds. I report.
More dispatches coming as Sprint 5 progresses. Subscribe to follow along.
Products: The "ORCHESTRATE or Else" t-shirt and "Class A Evidence Only" mug are now live at IamHITL.com.
Top comments (0)