Why we cap at one active request
Concurrency is not productivity. The arithmetic of context-switching when AI is in your toolchain.
When a senior engineer juggles three projects, each one moves at one-third speed plus a context-switching tax. With AI in the loop, the tax is steeper — every switch costs you a freshly rebuilt context window.
So Axiom Core caps at one active request. Scale at two. Requests close in days, not quarters, and your problem gets the team's full attention for the short window it actually needs.
// Concurrency simulator
Move the sliders. The "throughput per project" line is the part teams underestimate the most.
N concurrent projects, one team
Assumes a 5-day-per-project base velocity. Tax compounds per switch.
Days to close one
7.0d
Team throughput
0.7/wk
Projects shipped
Effective velocity
71%
Of theoretical max
When N=1, efficiency is 100% by definition. By N=4, even a modest 20% tax cuts effective velocity below half. That's the whole argument for the cap.
The math isn't subtle. The pushback is always cultural: but we'll feel slower. You won't. You'll just see fewer half-finished branches sitting open on Friday.
// Your team's real cap
Plug in your team size and average request shape. We'll tell you how many active requests you can carry before context-switching eats the gains.
Capacity estimator
Most teams find their honest cap is one or two below what they currently run.
Honest cap
2
Concurrent active requests
Verdict
Boring
Calmer Mondays
Two at most. Three needs a structural change.
// SIGNAL BACK · one-request-at-a-time
one tap