The Delivery Loop, an agent pod for client delivery
Client engagements run on a weekly rhythm. Sync, decisions, a week of execution, next sync. The work between meetings is the actual product, and most of it translates into discrete, verifiable tasks.
The delivery loop is an agent pod, consultant, PM, and engineer roles, built around that rhythm. The weekly sync transcript goes in. Prioritized, executed, and tested work comes out, along with a draft of the next meeting's deck. Human approval gates sit wherever the work carries risk.
Sense. The pod reads the sync transcript and routes what was said, never inventing. Commitments become work items with source quotes. New asks route to change control. Musings park for the next deck's conversation slide. Every item traces back to the words that created it.
Decide. A tier system splits the queue. Safe tasks earn AUTO and execute without ceremony, anything touching risk waits for review, and deterministic rules beat agent judgment on every conflict. Task shaping runs through a PM playbook, definition-of-ready gates, effort classes, three Musts per week maximum.
Execute. The engineer agent works one task at a time in an isolated worktree. It checks whether the work already exists before writing a line, implements against tests, and stops at a local commit for review. It never touches main.
The trust ladder is the governing idea. Autonomy is earned per capability from an eval record, never granted. The pod started at local-commit-only and earns push access as outputs prove consistently trustworthy. Trust is also per instance, a record earned in one repo transfers to no other.
- →Blind-tested before touching real work: pointed at a task secretly already finished, it found the unpushed commit, cited files and line numbers, verified 20 of 20 tests, and refused to re-implement
- →First real feature shipped with all 707 tests passing, stopping cleanly at an infrastructure boundary instead of hacking around it
- →Spec to production on a live client engagement in two days
- →A second mode runs without a transcript, from an intent note plus a backlog, for internal builds
Delivery stops scaling with headcount. The pod does the work of a consultant, a PM, and an engineer while one operator supervises, and the gates are what make it deployable on real client work rather than a demo.
The best first test for an agent is a task where you already know the answer. An agent that re-does finished work is worse than no agent, and the blind test is how you find out which one you have before production does.