AI coding agents changed the way I work.
When I started using them, the workflow was simple:
Give an agent a task → wait → review the result → continue.
Running one agent was easy enough.
Then I started running multiple agents in parallel.
At first, it felt like a huge productivity boost. Different agents could handle different tasks at the same time:
- 1. one agent implementing a feature
- 2. another fixing bugs
- 3. another exploring a technical approach
- 4. another reviewing code
- 5. another handling repetitive tasks
The limiting factor no longer seemed to be how fast I could write code.
Then something unexpected happened.
The bottleneck became me.
My current setup
My workflow usually involves more than 10 agents running at the same time.
They are not all the same type of agent:
- 1. Claude Code
- 2. Codex
- 3. Kimi
- 4. other task-specific agents
More than half of them are coding assistants, which means they consume a significant amount of CPU and memory.
Running everything on one machine is not practical, so I spread them across multiple machines and manage them remotely through terminal sessions.
On paper, this sounds like a good setup.
In reality, it creates a different problem.
The problem is not running agents. It is knowing what is happening.
When you have many agents running, the first question is no longer:
"Can this agent finish the task?"
The question becomes:
"What is every agent doing right now?"
I started noticing that I was spending more and more time checking sessions instead of making decisions.
Questions like:
- 1. Is this agent still working?
- 2. Did it finish already?
- 3. Is it waiting for my input?
- 4. Did it get stuck?
- 5. Is this session still relevant?
The agents were running, but my visibility was getting worse.
Context switching becomes the real cost
The biggest mental overhead comes from switching between sessions.
Every time I open another terminal tab, I need to reconstruct the context:
- 1. What was this agent working on?
- 2. Why did I start this task?
- 3. What decisions were already made?
- 4. What should happen next?
This is manageable with one or two agents.
With ten or more, it becomes exhausting.
The problem is not that the agents are not capable.
The problem is that humans are still limited by attention.
Multiple machines make it harder
Because coding agents are resource-heavy, many people cannot simply open 10 agents on one laptop.
My workflow requires multiple machines.
Remote terminal tools work well for connecting to those machines, but they mostly show the terminal itself.
They don't tell me:
- 1. which sessions are active
- 2. which ones are waiting
- 3. which ones finished
- 4. which ones need attention
So the only way to know is manually checking each tab.
Ten agents means ten context switches.
tmux solves a different problem
I have tried tmux and other terminal multiplexers.
They are excellent tools.
They solve an important problem:
How do I keep my sessions alive and organized?
But managing multiple AI agents introduces another problem:
How do I manage my attention across many autonomous processes?
Keeping everything visible is not always better.
A screen full of active sessions can become another source of distraction.
More information does not always mean more clarity.
I think we are entering a new workflow problem
For years, developers optimized their workflow around:
- 1. editors
- 2. terminals
- 3. build systems
- 4. CI pipelines
- 5. version control
AI agents introduce another layer:
Multiple autonomous workers running simultaneously.
The challenge starts to look less like traditional programming and more like supervising a small team.
Not because agents need constant supervision, but because humans need a way to understand their current state.
Curious how others are handling this
For people running multiple AI coding agents:
- 1. How many agents do you usually run at the same time?
- 2. Are you mainly using CLI tools, IDE extensions, or web interfaces?
- 3. How do you keep track of which agent needs your attention?
- 4. What breaks first for you: context switching, approvals, or simply mental overhead?
I’m interested in hearing how others are adapting their workflows.
Top comments (3)
"The bottleneck became me" is the whole future of this arriving early. I run a small team of AI agents too — planner, engineer, QA, security, deploy — and the moment I went parallel, the work stopped being "can the agent do it" and became "which of these six is waiting on me right now, and for what." The agents scaled fine. My ability to hold six live states in my head did not.
The reframe that helped: I stopped trying to read the agents and started making them report in a fixed shape. Each one has to end with what it did, how it verified it, and what's still open — not prose I have to parse, a structure I can scan. It doesn't reduce the number of agents; it reduces the mental cost per agent from "reconstruct what happened" to "read one status line." Supervising a team is exactly the right frame, and the thing every new manager learns is that the skill isn't doing the work — it's building the reporting that lets you not watch all of it.
The unsolved part you're pointing at — visibility across machines without drowning in it — is the real frontier. My hack is that idle agents cost nothing, so I'd rather have one waiting on a clear question than three half-running and ambiguous. Fewer live unknowns beats more throughput, at least for the one human in the loop. Great question to be sitting in; I don't think anyone's solved it yet.
This is really a mind-opening point. I think what we actually need is to build a trust boundary between ourselves and agents, rather than trying to understand every single detail of what every agent is doing.
Another great insight 😄. I agree that we probably only need to focus on a small number of important events and states. Ultimately, this comes down to building a trust relationship with AI workers, similar to how we build trust with junior team members.
We may need a new way of collaborating with AI that is designed around human attention and reporting mechanisms, rather than simply adding more agents or more information.
I have some ideas around this direction, but turning them into something that is actually practical and usable still feels like a long way to go.
"Build a trust boundary rather than understand every detail" is the right frame, and I want to push on one word in it, because it's the word I keep getting wrong myself: trust. The junior-teammate analogy is half right, and the half that's off is the important half. With a junior human, trust accrues and lets you delegate judgment — you stop checking because they've earned it. With an agent, trust can't attach to judgment the same way, because the thing you'd be trusting resets every session and respects enforcement, not intent. So the boundary isn't "I trust this agent's decisions." It's "I trust this agent to produce an artifact I can check without re-reading the reasoning." You're not delegating the judgment; you're delegating the work and keeping the receipt.
Which actually makes your instinct more workable, not less. You don't have to build the deep trust a junior earns over months — you just have to build the reporting shape that lets a shallow, per-session trust be enough. The clinical version I keep coming back to: I'd trust a nurse I've worked with for years, and I'd still expect the high-risk drug to get a second check — because trust reduces how often I supervise, it never removes the artifact on the paths where being wrong is expensive. Trust lowers the frequency of watching; it doesn't lower the floor of what has to be provable.
On attention-first design being the real frontier — agreed, and the one reframe that's helped me is that the scarce resource isn't the number of events, it's the number of judgment-type switches. Ten agents that all need the same kind of decision from me is cheap; three that each need a different kind is expensive, because the cost is reloading my context, not reading the line. So the reporting isn't just "surface fewer states," it's "batch the states that need the same shape of judgment." I don't have the practical version either — but I think that's the axis it lives on. Genuinely one of the more useful threads I've been in; you're asking the question the tooling hasn't caught up to yet.