When I wrote about how I run multiple AI agents in parallel, I mentioned that I could already be mentally tired by lunch time. That was one of the reasons I built my tool Norns Companion. I have now used Companion for more than six months, and I still feel the same fatigue fairly regularly.
The tool does what I built it for. I can see which agents are waiting, I can approve without switching sessions, and no agent sits idle because I missed a decision that was waiting for my answer. But the fatigue seems to come from somewhere other than keeping track of the agents.
Am I alone in feeling this way?
Several surveys on the same thing came out this spring. Boston Consulting Group asked 1,488 employees in the US and calls the phenomenon AI brain fry, a mental fatigue that sets in when working with AI demands more than you can hold in your head. Those who oversaw AI tools to a high degree reported 12 percent more mental fatigue and 19 percent more information overload. The researchers separate it from burnout, which builds up over a long time. This is a more acute fatigue that affects your thinking and your ability to make decisions.
In May, Stack Overflow wrote about the same thing from a developer's perspective: the agents write the code faster, but the decisions about the code have multiplied. Reading it, I recognized a lot of myself in that article. I no longer write much of the code myself, but the decisions about how it should be designed and what counts as the definition of done are still mine.
What Companion solved and what remained
Companion solved the overview of the work. Knowing which agent is waiting for me no longer takes any real workload. What takes energy is what happens once I get there.
For me it comes down to three things. The first is the decisions. Every approval, every choice between two proposals and every question about whether the agent has understood the task is a small decision, and they keep coming all day every day. The second is reviewing code I didn't write myself. It takes more focus before I can send the whole thing further on to production. The third is switching between parallel sessions. Companion makes the switching there short, but getting into another project's current state still costs something, even when I know exactly where I'm going.
So why do I put myself through reviewing the code?
Code review is the part I find hardest to let go of, and I don't think I will ever let go of it completely. If something happens in the code, I want to be able to say that I have read it and understand it. I also want to see that the AI chose sensible ways to solve the task, that it doesn't invent new solutions where a working one already exists or make everything more complex than it needs to be to reach the goal. It shows most when the agent and I have built a whole page with new components, or changed legacy code where QA grows with the change.
There is some support for the idea that it's the reviewing that takes the strength and energy. In a study from CHI 2026, 60 participants solved programming tasks with and without an AI assistant. The AI lowered their workload and made them faster, but the stress and fatigue that grew from task to task was partly explained by the work of verifying the AI's output.
What I have tried
So what have I done to reduce the load?
I spent time learning auto mode and what needs to be right in the config for Claude Code to just keep going, and I have pre-approved the commands that always get approved anyway. The agent no longer has to stop and wait for me all the time. I don't get a stream of notifications calling for me, and I don't have to act at uneven intervals throughout the day. It actually takes a fair amount of the load off.
For code review, I run Codex and GLM 5.3 as reviewers in a separate session. I pass the feedback back and forth until I feel it's time to look for myself. But in the end I still read it myself, for the reasons above.
I have also tried letting Claude Opus lead a group of cheaper Sonnet 5 agents that do the actual building. In practice, a task that Opus and I solve the usual way could take twice as long. The agents got stuck in review rounds and fixes that a stronger model would have solved on its own. It created extra stress, not the magical feeling of just letting it run until the whole thing is done.
I have also changed the output style in Claude Code. There I can choose between Default, Proactive, Concise, Explanatory and Learning, where Concise answers briefly, leads with the result and skips introductions and narration.
For me, Concise seems to be the sweet spot. It still loads skills like brainstorming, but then decides for itself that some tasks can do without a bigger planning step first. That's nice on smaller tasks and saves both time and output.
What auto mode brought with it
Fewer interruptions don't mean there is less to deal with. When the agent gets to run longer without me, more text comes back: summaries, plans, explanations and documentation. To me it feels like the load has moved from approving to reading.
If I ask an agent to document something, it easily turns into two pages of documentation. Sending two pages to a PM who needs a short list to share with the client doesn't work. At the same time, the heavier documentation is exactly what the next agent needs to continue the work. It's the same content, but for two very different readers.
It shows most clearly in my memory vault, where the agents log the work in client projects. It's built so that the next agent can pick up where the last one stopped: one folder per client, frontmatter on every file and an instruction file that says how everything should be written. Since July it has grown from under 200,000 to almost a million words, across more than 450 notes. A typical support note is around 1,000 words, roughly two pages. For an agent, that's exactly the right material.
For me, when I need to answer a client or check in with a PM, it's more than I have time to read every time.
Lagom, the right output for the right reader
So I built a skill for the reading. I call it lagom, the Swedish word for just the right amount, because what is just right depends on who is reading.
It takes a text, a note or the agent's latest answer and makes a short version for one of two readers: me or a PM.
I can call it with /lagom, but it also loads when I just ask for a short version for the PM.
For me, it becomes a few bullet points with what I need to decide on first. For the PM, it becomes a short list with the current status, what we need from the client and what could go wrong, without file paths and technical explanations.
The source material is never touched. The heavy documentation stays for the next agent, and the short version is made from it.
Before I wrote lagom, I had agents without it shorten the same texts, to see what actually went wrong. The result is interesting to share. The content was already careful: another client mentioned in the material never made it in, the test environment and production were kept apart and no dates were made up.
What went wrong was the shape. A short version for the PM became just over 300 words and a finished letter to the client, with a subject line and a greeting. A 46-word status became an email of more than a hundred words, signed with my name.
With lagom, the same support note became five bullet points and around 95 words, and the already short status was left as it was.
I also compared it with Caveman, a popular skill that makes the agent answer in short fragments to save tokens. JetBrains measured it at 8.5 percent fewer output tokens in agent work, with no measurable loss in quality.
In my test it changed nothing for the PM, because its own rules say that text for other people should be written in normal prose. For me the answer was even longer than without a skill, because all the content was still there, just in shorter sentences.
So Caveman and lagom solve different things. One shortens the sentences, the other starts from who is going to read them.
This was a small test on made-up material, one or two runs per case. It shows the shape, not that the skill holds up in daily work.
Same pace without burning out
The simplest advice would be to run fewer agents at once. It's also the only thing I haven't tried. When I just sit and wait for an agent to finish, I get restless, and then it's tempting to start something else for another client. So parallel sessions aren't just something I put up with, they are also my way of dealing with the waiting.
It seems I'm not alone. In a new study from ETH Zurich and the University of Zurich, not yet peer reviewed, participants described the same two options while the AI generates: either you sit idle, or you switch tasks and pay for it when you come back. The researchers conclude that waiting in AI tools should be designed, not merely tolerated.
I don't want to lower the pace or how much I get done in a day either. What I'm looking for is a way to keep the same pace without burning out. Lagom is my first attempt at doing something about the reading. Whether it makes a difference day to day, I don't know yet. I'll come back to it once I have used it for a while in real projects.
