For about six months I was sure I was working with agents in a WRONG way. The reason? Cognitive overload.
My usual Claude Code setup is one tab per product I work on, and each tab split into about four panes.
Each tab contain different theme of work, like different repos or products that require my attention.
It looks like parallelism, but mostly it isn’t. At any given moment one, maybe two of those agents are actually working - the rest are parked on a question, waiting for me to come back and answer it. The panes are open. The work is idle.
I tried to run it as controlled chaos, and for a while that felt like a skill I was building. But every time, after a stretch, my brain would flatten out and my focus would go with it. I kept losing the track of: “wait, where were we?”
My eyes were spinning, my memory was full of holes.
I assumed I was the problem. My feed is full of screenshots with 16+ agents running on one screen, and no mention of cognitive load anywhere - the conclusion was simple: the technique existed and I simply hadn’t learned it yet.
So I checked.
I went looking for how people actually use multiple agents, because I was about to release a tool built on the assumption that workflows like mine are a common pattern.
The results surprised me.
Parallelism is popular - just not how we think about it.
The very core finding is, that parallel agents give way better results and do it faster, than any single agent running - and to be precise, a lead agent with subagents outperformed a single agent by 90.2%.
It comes from Anthropic’s June 2025 write-up of how they built their multi-agent research system.
But there is a trick in this. It’s about research system.
This is about relative improvement on open-ended research tasks - the kind of question where you want breadth, where subagents can each go off and read different things and come back.
THIS IS NOT ABOUT:
90% fewer bugs.
90% less time.
In above workflow, a lead-agent is the orchestrator. It spawns agents, and merge results. This is where the workflow is efficient and works well.
AI concludes and goes back to you with precise, short answer:
In the same post, though, a few paragraphs on, the authors write this:
...domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.
And then, less ambiguously:
most coding tasks involve fewer truly parallelizable tasks than research
And this is where it gets tricky. Because, for many tasks in my professional job, and when running my business too, this will NOT work as such anymore.
At the end, I’ll become an orchestrator. And here is what it brings.
Both of these are parallel
The workflow is oriented around the orchestrator-worker. A lead agent plans the work, spawns subagents, and merges what they bring back. The lead agent is the load-bearing part. Keep a note of this, because that will be important later.
Here is my one pane on a Tuesday evening:
I ask for a code review.
The agent comes back with a list of issues.
I say: spawn an agent per issue found, verify or debunk each one, give me what survives.
I read one answer.
That is six or ten agents running at once. It is also one thread, one question, and one thing to hold in my head. The fan-out happened below me, and it collapsed before it reached me.
BUT, here is the other shape, that better reflects what I do to earn for living.
Team of 7 people, each creating pull requests.
Pane one - review a pull request.
Pane two - review a different one.
Second tab - implement the next thing on the roadmap. This thing consists of 10 tasks, two running at once.
Third Tab, run load tests for the upcoming major versions we’re releasing.
Some of the tasks will use separate agents underneath. But at the end, I’ll have 4-5 things to react two at any given moment.
Nothing collapses. Every pane comes back with its own question, in its own context, on its own schedule, and the merge step is a human who has already worked a full day.
Both of those are parallel. But the second is real, and the second produces cognitive load that our brains had never a chance to get used to.
In the workflow that was measured on, the thing that plans and merges is a model.
In the grid on my screen, it is me.
But there is more, something that came out more recently, and it is the one that changed my mind about myself.
Almost nobody is doing it
In June 2026, researchers including economists from Wharton, Columbia and Duke published usage data from OpenAI’s Codex. This wasn’t a survey of what developers say they do - a track of what they really did.
67.4% of organizational users and 63.9% of individual users never ran concurrent turns at all.
Not rarely. Zero. Yes, if agent automatically decided to spawn few subagents, that’s different story.
Then the part that reframes the whole discourse:
inside OpenAI, only 10.7% of users stuck to a single workflow, and 28.6% ran five or more agents concurrently.
What does it implies?
The heavily parallel workflow being sold to the rest of us is mostly practised by the people who work at the labs building the tools.
You think it’s conspiracy? NO!
It is the ordinary thing where the people closest to a capability adopt it first and hardest, and what is normal for them, becomes and aspiration to everyone else. Dogfood your own product! Make trends instead of following them! This is what’s happening here!
But it does mean the gap you feel between your setup and what you see in your home feed, is very much misleading.
Two-thirds of developers never run two turns at once.
Four panes with one or two live agents in them is not a failure to keep up - that is roughly the shape of the distribution, and the setup I was measuring myself against is a minority practice concentrated among the people who build the tools.
This told me, that I was not behind on the technique, but something else was the case.
So what actually breaks
When I eliminated the agent count as the problem better question was left with me: when developers say they lose control of AI coding work, what specifically goes wrong?
There are three different things that get merged into one complaint, and separating them is most of the work.
1. The model loses context inside a session.
This is the thing documented to death, independent on how you work, and this is the thing every big AI company is racing to fix with bigger windows and memory systems.
This is not a workflow problem.
2. Agents collide on shared files.
This one is real, and the receipts are ugly.
The Claude Code issue tracker contains a report, where a cleanup agent deleted source files a second agent was still using. That was 22 files, around 7,400 lines, described by its author as unrecoverable.
Ach, if that’s not enough, another report contains worktree cleanup destroying a .git directory and most of a working tree.
Worktrees and isolation are the answer here, and they work well. Copy your notes. Allow agents to work separately, never touching the same file instance together.
Resolve conflicts on pull request merges.
Not much to say here - keep your files backed up... So let’s check the last reason.
3. You lose the thread.
Not the model. You.
In my setup that has a specific shape: every pane sitting on an unanswered question is an open loop I am holding in my mind, and I am the only thing routing between them.
Add a new tab or window and you have not added throughput - you have added something new to remember about.
That third one is what I keep hitting, and it has better witnesses than I expected.
Simon Willison wrote in February:
“I reached the stage of parallel agent psychosis where I’ve lost a whole feature - I know I had it yesterday, but I can’t seem to find the branch or worktree or cloud instance or checkout with it in.”
Addy Osmani, in April, calls the standing cost of it the ambient anxiety tax - it never appears on a task list, but it draws from the same reservoir as everything else.
Someone filed a Claude Code feature request describing himself as the user as message bus, copy-pasting between five sessions.
No survey exists
But here is the uncomfortable part.
Those examples above are just anecdotes. Excellent, well-observed anecdotes from people who experienced similar issue I did. BUT there is no survey. There is no number for how often developers lose track across agent sessions, how long it costs them, or how many sessions is too many.
The nearest hard figure anyone reaches for is a 2018 study of general human task-switching, which found that 29% of interrupted tasks are never resumed. That study has nothing to do with AI, yet still sounds suspiciously familiar to what I describe here.
The honest summary is: widely discussed and never measured.
But I built something for it anyway. Just to solve my problem, and hopefully improving the daily work of my team - and maybe your too!
What I built
mindskein brief. This is one command, three sections, answering the question I was asking Claude by hand every morning: what are my priorities, what is running elsewhere, and where did we leave off.
It hooks into Claude Code, keeps a registry of sessions and what state they ended in, writes a handoff per session, and reads my priorities out of my own notes. It runs locally, makes no network calls by default, and the core is open sourced.
The thing it fixes, is that when I open the laptop at 20:30 on a Friday, to continue work I left last time at 21:50 on Sunday, then the first fifteen minutes go to reconstructing where I was.
Multiply by five evenings.
What someone else shipped, two weeks before I released
I had a lot of fun working on this project, and it became useful immediately. I feel calmer now, I stopped loosing the context when my computer restarts because of the obligatory system update.
But the game of life is not as easy.
On 7 August, Claude Code shipped cross-session messaging. Sessions can now find each other and send text - the migration finished, the column is added, your rebase is safe. It closes the “user as message bus” complaint directly, from inside the tool, for free.
I am not going to pretend that didn’t take a bite out of my premise. I tried what’s possible now, and still had complains.
What is left in mindskein is narrower than what I thought I was building, and I think it is still real: Claude’s messaging connects sessions that are live, in the moment, while you are watching.
The thing I need is recall the next morning, across sessions that have already ended, joined to what I decided mattered this week.
Pull from notes.
Pull from jira if configured
Pull from github for review requests or new feedbacks.
My goals progress
Claude, Codex saves sessions.
Something to wrap it all up in: “This is where you’re now, and where you’re heading this week”
The point
So, was I the problem? NO, I just worked on wrong assumptions!
I thought I would find out whether four panes is too many. What I found is that the number of panes was never the variable.
Remember the load-bearing part? A lead agent plans the work, spawns the workers, merges what comes back. This is what brings efficiency. But every time I split another pane, I built exactly that architecture. With myself sitting in the lead agent’s seat.
A model in the orchestrator seat keeps its state between turns. I don’t, and neither you.
I close the laptop at 21:50 on a Sunday. I sleep. I spend eight hours at a different job. I come back on Friday holding maybe a third of it.
The orchestration didn’t fail. The orchestrator went offline.
In that whole diagram, the human is the only component with no persistence layer.
So what was the “something else” I promised you?
Storage.
And it has a price you can actually count, even if nobody surveyed it. Fifteen minutes of reconstruction. Five evenings a week. That is an hour and a quarter, every single week, that you’d spend on remembering instead of doing.
Most of one of my working sessions - gone forever, every week.
What can you do?
There are two moves here, and they are different jobs.
Where the work can fan out below you, let it. Ask for the review, let ten agents check ten things, read ONE answer. That shape scales. It is the one the research was ever about. I haven’t found a ceiling on it yet.
Where it can’t - different repos, different products, a feature that spans a week - you are the merge step. No amount of restraint changes that.
Then the question was never how many agents you can run but whether anything is holding the thread while you sleep.
That is the whole system. Delegate what I can, and catch what is left when I can’t.
Now, do I know if the second half is a problem anyone else has? Honestly... no. There is no survey, so I am making one myself.
The tool is live and the core is open: github.com/swilgosz/mindskein
The Mac OS desktop app is being built, all my paid subscribers have early access and discounts on everything I build, feel free to join!
If it turns out to be something only I needed, I would rather find that out in public.
How many open loops are you holding right now?