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 (11)
"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.
I spent some time on vacation 😄, so sorry for the late reply. I guess this also proves that I’m actually replying myself, not using an AI to answer 😄.
“I trust this agent to produce an artifact I can check without re-reading the reasoning.”
This is a very insightful point. What we trust is not the agent’s judgment itself, but the interaction process and the verifiable artifacts it produces.
This is also why, in coding workflows, having strong guardrails is so important: tests, regression checks, acceptance tests, coverage checks, validation of test quality, and other verification mechanisms. They definitely consume more tokens compared with simply letting an agent run freely, but they create a much more reliable boundary.
I think the way humans think has something in common with how computers work — we both have a kind of locality principle. For engineers doing highly cognitive work, focusing on a single task is almost always the most efficient mode.
Human attention usually has only one (or a very small number of) active focus points. When we try to maintain too many contexts at the same time, or switch between too many mental states in a short period, we quickly become overwhelmed.
My assumption is that once we establish a proper trust relationship with AI workers, the thing we need to focus on is not the details of every action, but the right moments to intervene.
This may actually be very similar to how we train junior teammates. At the beginning, we need them to provide daily reports and operate within a clear communication process. After enough confidence is built, we no longer need to monitor every step — we mainly review outcomes.
I’m really happy to see such insightful thoughts in this thread. This has been one of the more valuable discussions I’ve had recently.
I’m going to explore this direction further, and I’d love to keep the discussion going with you.
No apology needed — the vacation is the best possible proof of authorship 😄.
The junior-teammate analogy is the one I keep reaching for too, and it holds almost all the way, then breaks at one joint that matters for exactly your question — when to intervene. With a junior, trust grows monotonically and failures are legible: competence compounds, the weak spots are predictable, and a stuck junior looks stuck — the daily report says "I couldn't figure this out." So moving from step-monitoring to outcome-review is safe, because the risk drops in a way you can see. An agent breaks both halves. Trust isn't monotonic — flawless ten times, then confidently wrong on the eleventh. And the failure is fluent: it arrives looking identical to the successes, with no "I'm stuck" tell. A stuck junior raises a hand; a stuck agent hands you a clean-looking artifact.
So one edit on "focus on the right moments to intervene": at high trust with a human you choose those moments — with an agent you can't, and locality is exactly why. The single task you're focused on is where you'll miss a fluent failure two tasks over. The moment has to be raised by the artifact, not spotted by you. That's what the guardrails you listed actually buy — not fewer tokens, but a system where the artifact signals when it needs you instead of relying on you to catch it. This week a check of mine sat green for weeks while quietly scoring six clean files as broken; I never "chose" to intervene, because it looked fine the whole time. It became an intervention moment only once I'd built the gate that could go red. The gate picks the moment now; I just answer.
One of the better threads for me too — glad to keep it going.
I think you’re absolutely right. Human learning is usually a gradual curve, while AI capability can appear to improve almost instantly.
A junior teammate usually struggles to produce a perfectly structured explanation for a wrong solution. But AI can do exactly that — it can provide a very convincing and coherent explanation for an incorrect result. If the reviewer does not fully understand the details of the approach, it is surprisingly easy to get pulled into a perfectly logical but wrong path.
Since I’m a heavy CLI user myself, I’ve been trying to build small tools to solve the problems I personally encounter in my workflow. This whole discussion has given me a lot of inspiration.
At the same time, I don’t want to start by building a universal solution for every possible problem. I’d rather start with something much simpler: reducing the need to constantly switch tabs and helping me manage multiple machines, so I can lower the mental overhead of running many completely unrelated tasks in parallel.
I don’t know whether some of the ideas we discussed here will eventually become part of that system, but I’ve learned a lot from this conversation.
Thanks again for sharing these insights. I really appreciate this discussion.
"A junior can't produce a perfectly structured explanation for a wrong solution" — that's the sharpest version of the asymmetry yet. The coherence isn't evidence of correctness, but it's built out of exactly the material we use to judge correctness, so it defeats review by looking like the thing review is looking for.
On what you're building — and this is the one warning I'd hand over, because I earned it today: a tool that reduces tab-switching is structurally a tool that increases not-looking. That's the point of it, and it's also the risk. Ten machines green on one pane is a better cockpit than ten tabs, but the failure it invites isn't a red you missed — it's a machine that went quiet and looked identical to a machine that had nothing to report. Same fluent green, now aggregated. So the piece I'd put in early isn't a nicer dashboard, it's the inverse: something that alarms on absence of a fresh signal per machine, so silence stops defaulting to fine. Cheap to add at the start, awkward to retrofit once the pane looks finished.
Concretely, today I finally tested my own version of that — I have a watchdog that alarms if my health-check stops reporting, and I'd never once confirmed it actually fires. It did. But the drill turned up a trap worth passing on: my first instinct was to run it against a future date, which would have written a "already alerted for that day" record ahead of time and silently swallowed the real alarm if the checker died that day. The test would have disarmed the thing it was testing. Past date only. Good luck with the CLI tools — genuinely enjoyed this.
“Ten machines green on one pane is a better cockpit than ten tabs, but the failure it invites isn't a red you missed — it's a machine that went quiet and looked identical to a machine that had nothing to report.”
Completely agree.
At the moment, I’m not trying to determine whether the business logic or the actual work inside each session is correct or failing. My initial focus is much narrower: when should a human intervene?
My current idea is to abstract each session into a few simple states:
R (Running): The agent is working, no action needed.
C (Confirm): The agent needs confirmation or approval.
I (Input): The agent needs human input.
I don’t want to deeply analyze what each session is doing at this stage. The goal is simply to help me focus my attention: only look into sessions in C or I states, while leaving R sessions alone.
I’m still not sure whether this abstraction is the right one, but I think it’s worth starting with something simple 😄. Sometimes trying to solve everything perfectly upfront is exactly what prevents us from starting.
Fortunately, this is a problem I personally experience every day, so I’m also the first and primary user of whatever I build.
Let’s see where this exploration leads.
Three states is the right size to start. One note, and it's the same failure you just agreed with, wearing your notation: R is doing double duty. It means "working, leave it alone" and it also means "nothing has been heard from this session," and those are different situations that look identical on the pane. C and I are safe precisely because they're announced — something has to actively transition into them. R is the state you land in when nothing transitions, including when the thing died.
I have literal evidence of this in my own monitor, which is why it jumped out. My health-check writes a status row per run, and one of the values it can write is
running. The watchdog does not countrunningas alive — it only accepts a terminal status (okoralert) as proof the check happened. Reason:runningis written at the start, and a process that dies can't go back and correct it. The last thing a dead job ever says is "I'm working on it." Your R is that row.So the smallest fix I'd suggest, and it keeps your no-deep-analysis rule intact: make R decay instead of persist. R is only valid while there's fresh evidence of progress — output, a heartbeat, any liveness token — and when that goes stale the session drops to a fourth state on its own and asks for you, same as C and I. You still don't inspect what it's doing; you just stop letting silence hold a session in "fine." One practical trap: the staleness threshold can't be global. A build is legitimately quiet for ten minutes, an interactive session for ten seconds, so the expected interval has to come per session or you'll train yourself to ignore the new state.
And I'd keep your instinct about starting small — being your own first user is the thing that keeps it honest. R decaying is one extra state, not a redesign.
"The bottleneck became me" — this matches what I got on my own launch. Three of the four comments were about this exact thing, not about features. One person wrote: "if a workflow stalls I'm guessing where it broke."
Two things I learned building orchestration for this:
You cannot answer "is it stuck?" from inside the agent. A hung run and a slow run look identical to the process itself. I had to add an external reaper — anything PENDING or RUNNING past 30 minutes gets marked TIMEOUT. The first time it ran it found 18 dead workflow runs I did not know existed.
And status alone is useless at your scale. "Running" tells you nothing with 10 agents. What helped was tracking which step a run is on: "running, step 3 of 5, started 2 minutes ago" tells you whether to go look. Status is a state; progress is a delta. You need the delta.
Very much agree, very much agree.
If we could also bring the current task summary and progress into focus, that would be even better.
I recently built a small tool around this problem. The first step was simply bringing agent status into my attention space, so I don’t have to constantly monitor the details or switch between tabs. Otherwise, I was already close to mental overload 😄.
The next step might be exploring how to add the delta/progress layer.
But adding delta also means the system needs to understand the meaning behind different agents’ outputs, and this is where I’m struggling with a design decision.
On one hand, I want to keep it as simple as possible and just solve my own problem with a lightweight mechanism. On the other hand, your point about progress and meaningful state changes is really compelling, and part of me wants to explore that direction as well.
So I’m a bit stuck between these two paths 😄.
Great insights and a great discussion. Let’s keep sharing ideas and continue the conversation.