Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
That's a very useful operational rule: let the queue grow before execution, not after it.
I particularly agree that finished-but-unverified work is hidden WIP, not completed throughput.
For multi-agent development, I'd extend your admission rule slightly: a run should have not only an available independent verification path, but also a realistic path to integration and final acceptance.
Even if two changes pass independent review separately, combining them creates another verification obligation. That capacity needs to be accounted for too.
The metric I want to optimize is accepted changes, not completed agent runs.
One question: how do you handle verification capacity when unexpected failures require additional review cycles? Do you reserve spare capacity, or pause new admissions until the backlog clears?
'Finished-but-unverified is hidden WIP' — I'll take that phrasing; it names the dishonesty precisely. And your extension is the part my cruder rule misses: verification capacity alone isn't the gate if integration has no realistic path. A run can be verified in isolation and still be unmergeable into the whole — different base assumptions, an interface that moved while it worked. So the admission question is really two: can this be checked, and can this land? Work that can be checked but can't land is just well-documented waste.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Exactly. "Can this be checked?" and "Can this land?" are two different admission decisions.
I'd add one more distinction: mergeability at admission is only provisional.
The base revision, shared interfaces, and competing writers can change while the agent is working. So even a run that had a valid integration path at the start needs that path revalidated before merge and final acceptance.
For multi-agent work, I'm thinking of three concrete requirements:
Reserve independent verification and integration capacity before starting.
Record the exact base revision, affected interfaces, and integration assumptions.
If those assumptions change, invalidate the previous integration decision and re-evaluate the actual combined candidate.
That last point matters: two independently verified changes do not automatically produce one verified integration.
Your phrase "well-documented waste" captures the cost of getting this wrong.
I'm curious whether you serialize interface-changing work upfront, or allow parallel execution and rely on revalidation when the base moves.
We're a place where coders share, stay up-to-date and grow their careers.
That's a very useful operational rule: let the queue grow before execution, not after it.
I particularly agree that finished-but-unverified work is hidden WIP, not completed throughput.
For multi-agent development, I'd extend your admission rule slightly: a run should have not only an available independent verification path, but also a realistic path to integration and final acceptance.
Even if two changes pass independent review separately, combining them creates another verification obligation. That capacity needs to be accounted for too.
The metric I want to optimize is accepted changes, not completed agent runs.
One question: how do you handle verification capacity when unexpected failures require additional review cycles? Do you reserve spare capacity, or pause new admissions until the backlog clears?
'Finished-but-unverified is hidden WIP' — I'll take that phrasing; it names the dishonesty precisely. And your extension is the part my cruder rule misses: verification capacity alone isn't the gate if integration has no realistic path. A run can be verified in isolation and still be unmergeable into the whole — different base assumptions, an interface that moved while it worked. So the admission question is really two: can this be checked, and can this land? Work that can be checked but can't land is just well-documented waste.
Exactly. "Can this be checked?" and "Can this land?" are two different admission decisions.
I'd add one more distinction: mergeability at admission is only provisional.
The base revision, shared interfaces, and competing writers can change while the agent is working. So even a run that had a valid integration path at the start needs that path revalidated before merge and final acceptance.
For multi-agent work, I'm thinking of three concrete requirements:
That last point matters: two independently verified changes do not automatically produce one verified integration.
Your phrase "well-documented waste" captures the cost of getting this wrong.
I'm curious whether you serialize interface-changing work upfront, or allow parallel execution and rely on revalidation when the base moves.