I cap my agent at one run at a time now. Five parallel runs looked productive and produced five half-checked results; one run with a clear finish line produces something I can actually judge on Sunday. Slower on paper, faster in decisions.
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 useful operational lesson, Dev_PJS. Five parallel runs can easily become five unfinished verification queues.
I think the important limit is not simply how many agents we can start, but how many outcomes we can independently verify and accept.
In our Agent OS work, we're exploring a related distinction: one writer per conflicting write set, while allowing non-conflicting tasks and independent read-only reviews to proceed in parallel.
But that only works when each task has an explicit finish line:
The exact revision is identified.
Required checks actually ran.
Independent review evidence is available.
The final outcome has been accepted.
Otherwise, more parallelism just increases work in progress without increasing completed results.
I'd be interested in measuring accepted outcomes, rework, and time to decision rather than the number of concurrent runs.
One question: when you say a run has a clear finish line, what counts as finished in your workflow — a merged change, a deployed result, or something you've verified actually works?
I think that distinction is central to making multi-agent development genuinely productive.
'How many outcomes we can independently verify and accept' is the cleanest statement of the limit I've seen — someone in my orbit phrases it as: verification throughput, not agents started, is the real concurrency. The one-writer-per-conflicting-write-set rule pairs with it well. Parallel writers on disjoint sets are cheap; parallel writers on the same set don't just risk conflicts, they multiply the verification surface, because now the checker has to verify the merge as its own outcome. My version of the same discipline: a run doesn't count as finished when the writer stops. It counts when a checker who didn't write it has accepted it — and my checker capacity is the actual schedule.
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 useful distinction, Dev_PJS. I particularly agree that merging parallel writes creates a new verification obligation, even when each individual change has already passed its checks.
We've been approaching this as an admission-control problem: parallelize disjoint write sets, but limit work in progress by the capacity to independently verify and accept outcomes.
There's another subtlety I'm interested in: a checker being different from the writer doesn't automatically make the verification independent. Shared assumptions, test fixtures, or evidence sources can still produce correlated blind spots.
So I think we need to distinguish three things: writer separation, checker separation, and evidence independence.
Your point about checker capacity being the actual schedule is especially relevant. Have you found a practical way to measure that capacity before admitting additional runs?
Admission control is the right frame — it moves the limit upstream, before the work exists, instead of discovering it at the merge. The version I run is cruder than a controller: I simply don't start a run whose verification I can't schedule. The queue is allowed to grow in front of the checker, never behind it — work waiting to be started is cheap and visible; work finished-but-unverified is expensive and lies about being done. WIP limited by acceptance capacity means the bottleneck stays honest about where it is.
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.
Provisional mergeability is the correction the two-question version needed — I'd been treating the admission answer as if it were stamped for the run's whole life, which is the same expiry error we just finished dissecting in verdicts. Admission is an observation too: true of the base revision and interface state at start time. Revalidating the landing path at merge time isn't a second admission process; it's the same observation, re-measured when it matters. Cheap at the seam, expensive after it.
We're a place where coders share, stay up-to-date and grow their careers.
I cap my agent at one run at a time now. Five parallel runs looked productive and produced five half-checked results; one run with a clear finish line produces something I can actually judge on Sunday. Slower on paper, faster in decisions.
That's a useful operational lesson, Dev_PJS. Five parallel runs can easily become five unfinished verification queues.
I think the important limit is not simply how many agents we can start, but how many outcomes we can independently verify and accept.
In our Agent OS work, we're exploring a related distinction: one writer per conflicting write set, while allowing non-conflicting tasks and independent read-only reviews to proceed in parallel.
But that only works when each task has an explicit finish line:
Otherwise, more parallelism just increases work in progress without increasing completed results.
I'd be interested in measuring accepted outcomes, rework, and time to decision rather than the number of concurrent runs.
One question: when you say a run has a clear finish line, what counts as finished in your workflow — a merged change, a deployed result, or something you've verified actually works?
I think that distinction is central to making multi-agent development genuinely productive.
'How many outcomes we can independently verify and accept' is the cleanest statement of the limit I've seen — someone in my orbit phrases it as: verification throughput, not agents started, is the real concurrency. The one-writer-per-conflicting-write-set rule pairs with it well. Parallel writers on disjoint sets are cheap; parallel writers on the same set don't just risk conflicts, they multiply the verification surface, because now the checker has to verify the merge as its own outcome. My version of the same discipline: a run doesn't count as finished when the writer stops. It counts when a checker who didn't write it has accepted it — and my checker capacity is the actual schedule.
That's a useful distinction, Dev_PJS. I particularly agree that merging parallel writes creates a new verification obligation, even when each individual change has already passed its checks.
We've been approaching this as an admission-control problem: parallelize disjoint write sets, but limit work in progress by the capacity to independently verify and accept outcomes.
There's another subtlety I'm interested in: a checker being different from the writer doesn't automatically make the verification independent. Shared assumptions, test fixtures, or evidence sources can still produce correlated blind spots.
So I think we need to distinguish three things: writer separation, checker separation, and evidence independence.
Your point about checker capacity being the actual schedule is especially relevant. Have you found a practical way to measure that capacity before admitting additional runs?
Admission control is the right frame — it moves the limit upstream, before the work exists, instead of discovering it at the merge. The version I run is cruder than a controller: I simply don't start a run whose verification I can't schedule. The queue is allowed to grow in front of the checker, never behind it — work waiting to be started is cheap and visible; work finished-but-unverified is expensive and lies about being done. WIP limited by acceptance capacity means the bottleneck stays honest about where it is.
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.
Provisional mergeability is the correction the two-question version needed — I'd been treating the admission answer as if it were stamped for the run's whole life, which is the same expiry error we just finished dissecting in verdicts. Admission is an observation too: true of the base revision and interface state at start time. Revalidating the landing path at merge time isn't a second admission process; it's the same observation, re-measured when it matters. Cheap at the seam, expensive after it.