Hey there,
My productivity started going backwards three sessions before I noticed. I did not know that at the time. What I knew was that July had gone well. I had my hands back in the work after a long stretch of not, and everything moved faster with me inside it rather than beside it. So I ran more. Several sessions at once on different parts of the agent fleet, and I moved between them while they worked.
Then the plans started getting longer. Ask for a piece of work and what comes back for approval is a bigger document than it was a month before. More steps, more files touched, more time to produce and more of my time to read before anything could start. Six of those running at once and most of my attention was going on holding in my head what each session thought it was doing. Some weeks I lost the thread entirely and had to go and reconstruct it. By the back half of the month I was tidying up after myself more than I was building. A few days ago I stopped mid-afternoon with nothing left to think with and took the rest of the day off, which I do not often do.
Two suspicions came out of that, and I went after the wrong one first.
The Suspicion I Started With
The plans getting longer is what made me think about money. These tools are paid for by the token, and a longer plan is a longer bill before a line of it gets built. They also have a reliable habit of handing you more than you asked for. Extra dependencies, structure for a case that will not arise, two hundred lines where fifty would have done. So I wondered whether the over-delivery was less a flaw in the machine than a feature of the business.
There is real work on this. A paper from the spring shows that the tokenisation of a piece of text is not unique. You only ever see the count the provider reports, so a provider's return is tied to the length of the sequence it chooses to report. Checking it is NP-hard, which puts verification out of your reach at any sensible price. The authors also prove that pricing on characters instead of tokens removes the incentive, and that a provider could switch while holding its margin. The fix exists, it is published, and nobody has taken it up.
I am glad I looked, and I am leaving it there. It says nothing about anyone's conduct. The bill I paid in July was not denominated in tokens.
Three Is the Number
The other suspicion was the one worth having. Longer plans did not only cost more to produce. They cost more to hold, and holding them was my job. That has a name and a literature. Boston Consulting Group, with researchers at UC Riverside, surveyed just under fifteen hundred workers and called it AI brain fry: mental fatigue from the use, interaction with and oversight of AI tools beyond what a person can carry. Fourteen per cent of workers using AI report it outright. The ones who have it show a third more decision fatigue and thirty-nine per cent more major errors. A third of them are thinking about leaving their jobs.
Two findings rearranged how I read my own month. Productivity gains plateau after about three simultaneous AI tools and then go backwards. Not level off. Go backwards. I was running six and congratulating myself on the throughput. Three is not a fixed ceiling either. It assumes some weight per session, and as the plans grew each session got heavier, so my real ceiling was coming down while my count went up. The second finding is the one that makes this causal rather than atmospheric. Where AI replaced routine work, burnout scores fell by fifteen per cent. The damage does not come from the AI. It comes from supervising it.
The machine has the same curve. Anthropic call it context rot. Put more into a context window and the model's ability to recall from it accurately drops, so a bigger context is not just dearer, it is worse. Two substrates, one shape. Past a certain load both the person and the model stop improving and start degrading. In both cases the fix is the same. Keep the working set small and let structure hold the rest.
Building the Limit Into the Tooling
That changes what our harness is for. We had been hardening it so the machine follows the discipline: git hooks that run whether or not anyone remembers them, coverage gates that measure what the tests reach rather than asking the work to mark its own homework. The harness has a second job I had not been giving it. It has to protect the person supervising it. Both jobs want the same controls, which is how I know they are the right ones.
The largest lever is what gets read. Agents spend about seventy per cent of their token budget working out where things are rather than answering the question, so scoping the reading beats compressing anything afterwards. Fetch by path when the work needs it instead of loading the world up front. Give a specialist a clean context, let it do the exploring, and have it hand back a page instead of a transcript. That one does double duty, because a page is also what I can read without emptying myself out. The way we already hold our library, one core with everything pointing at it and nothing copied, turns out to have been a token optimisation the whole time. We built it for tidiness.
Then the gate. Make the agent produce a read-only plan before it writes anything, above some threshold of files touched, and approve the plan instead of the diff. Planned work lands in roughly a third of the time that code-then-discover-then-undo takes. What I approve is a paragraph instead of a sprawl. And the plan gets a size limit, which is the part I would have missed a month ago. If what comes back cannot be read in a few minutes then the work is too big and wants splitting, and a plan is a much cheaper place to find that out than a diff.
And the plateau becomes a setting. Three concurrent sessions, because that is where the curve turns, enforced by the tooling rather than by my judgement at four in the afternoon, when my judgement is worst.
None of which I can tune without measuring it. We already log what our agents decide and where they get blocked, because an auditor will want to see it. That log is also the only honest view I have of my own consumption, session by session, and the only way to find out which of these controls earns its keep. A record built to satisfy somebody else turns out to be the instrument I need for correcting myself.
A Control That Weakens Under Load
This is not a note about working habits, and here is why.
We build AI agents for cybersecurity compliance. What we tell clients is that human behaviour belongs inside risk management rather than beside it. That argument has just arrived with an effect size attached. An operator supervising more agents than they can hold makes thirty-nine per cent more serious mistakes. In our line of work a serious mistake is a misconfigured control, a risk left untreated, an incident nobody logged.
Look at the structure and it is worse than an ordinary human factor. The control is human review. The load on that control is the volume of AI output. So the more you deploy, the more review you need, and review is the thing that fails as volume rises. The control degrades as a function of the thing it controls. Anywhere else we would call that unacceptable and design it out. I have not seen it in a single risk register.
So it goes in ours, and it goes into what we build. Not as a wellbeing initiative. As a control with a threshold, an owner, and something that trips when it is breached, the same as any other.
I do not know yet how much of the load will move. Some of it plainly will. Whether the work in front of me is the right work is not checkable by a hook, and that was the part that emptied me out. There is also a version of this where I build a better harness and then run more sessions through it, arriving back at the same afternoon by a longer road. That is the one I want to be watching for.
With care, Ben