I run Arc & Anchor as a solo managing director, and I have a team. Just not in the conventional sense. My team is a set of AI agents — one for the inbox, one for intelligence, one for finance, one for compliance, one for content, a few others. They draft, summarise, sweep, and brief. I am the only human in the loop.
I built this expecting to feel a productivity boost. What I actually feel, most days, is a different problem entirely. The agents can produce more than I can review. The constraint on my work is no longer how fast I can think or write — it is how fast I can read what was written for me and decide whether it is right.
That shift in constraint is the whole story.
What changed for me
When my PA agent drafts a reply to an inbound email, she does it in seconds. The reply is usually 90% right. The remaining 10% is where she has confidently misread the relationship history, invented a commitment I did not make, or used a tone that fits her training data but not this specific recipient. That last 10% is the part where I have to sit and read carefully — and the cost of missing it is paid in a real human relationship.
The pattern repeats with every agent. My intelligence agent produces a 1,500-word brief in under a minute. The brief is plausible, well-structured, and will occasionally cite a source that does not exist. My content agent drafts a blog post faster than I can outline one. The post will sound like me — if you do not know me well. If you do, the seams show.
The throughput gain is real. So is the new bottleneck: review capacity is now the limiting factor, and judgment is the only thing that catches the failures.
Three datasets pointing at the same shift
The data has been catching up to this for a while. Three independent surveys this spring all gesture at the same observation, even when the framing differs.
The Pragmatic Engineer’s April 2026 survey of 906 developers found agent users are roughly twice as positive about their work as non-users. Staff engineers and tech leads are adopting at 63.5%. Claude Code became the most-used tool in the space in under eight months — driven almost entirely by senior adoption. The wave is not leaving anyone out. It is being driven hardest by the people who already have the depth of context to evaluate what the agents produce.
Opsera and Shift published productivity differentials the same month. Across thousands of developers, the gap between senior and junior engineers using agents is 5× — and it widens with seniority. Their explanation tracks mine: more context means more effective evaluation of the output. Less context means more time iterating on confident-sounding work that is wrong in ways that take a while to surface.
ICLR 2026 gave the failure mode a name. “The Reasoning Trap” examined what happens when RL-trained reasoning models interact with tool use. The finding is uncomfortable: training a model for deeper reasoning increases the rate of hallucinated tool calls. Models that look more capable in benchmarks are more likely to invent plausible-looking but wrong API calls, function signatures, or file paths. The output is more confident. The errors are harder to catch.
All three converge on the same point. The bottleneck has moved. It used to sit at production — how much code, how many drafts, how many briefs you could generate in a day. Now it sits at evaluation — how much of that output you can read carefully enough to catch what is wrong.
The reviewer is the constraint
I used to think of judgment as polish — the thing you applied at the end. In an agent-native workflow, judgment is the work. Production is mostly free. The expensive, scarce, irreplaceable activity is the act of reading agent output and knowing when it is wrong.
This is not an argument against agents. I would not give them up. The leverage is real. But the leverage compounds against a fixed amount of review capacity, and that fixed amount is what determines actual output — not the speed of the agents.
The question to ask of any agent-native workflow is no longer “how much more can we produce?” That question has become trivial. The question is “how much can we evaluate well?” And the answer to that depends entirely on the depth of judgment available to read the output.
What this means in practice
Three things have stuck for me from running this experiment.
Treat review time as the scarce resource. Setting up an agent to draft emails, briefs, or code does not save time until there is a plan for the review step. Most productivity claims for AI tools quietly assume review is free. It is not. In my own work, the review step is now where most of the day actually goes.
Invest in judgment, not just tools. Adding more agent capacity against a fixed review capacity buys you nothing — and possibly costs you, because more output means more chances for confident failures to slip through. The thing worth investing in is the part of the work that catches errors: domain knowledge, the muscle of reading critically, the ability to feel where the seams are in a piece of work.
Measure the right thing. Throughput metrics — words drafted, code produced, tickets moved — all inflate in an agent-native workflow regardless of quality. They are no longer signal. The metrics that matter are about outcome quality: how often you have to fix something downstream, how many late escalations come from earlier output that was confidently wrong, how often you trust the output and should not have.
The shape of the next few years
We are heading into a period where production is functionally unlimited and judgment is the binding constraint. The people who do well in this period will recognise that the bottleneck has moved and design around it. The ones who do not will keep producing more and more output of progressively lower quality, wondering why the leverage never seems to pay off.
I built this AI team partly as an experiment in what that future feels like. From inside it, the answer is clear. The agents are not the constraint. They never will be again. The constraint is me — my attention, my context, my judgment — and the discipline I bring to using them.
That is true at every scale. The bottleneck moved. The work now is to design for that.