A CLI-first workspace manager for developers running multiple AI coding agents
In my previous article, I wrote about running multiple AI coding agents in parallel.
The surprising conclusion was:
The bottleneck was not AI anymore.
It was me.
The agents became faster and more capable, but my own workflow started breaking down.
I had too many things to track:
- Which agent is working on what?
- Which one is waiting for my input?
- Which one finished?
- Which terminal session belongs to which project?
- Which machine is running that agent?
The problem was no longer:
"How do I make AI code faster?"
The problem became:
"How do I effectively work with many AI agents at the same time?"
After experiencing this problem repeatedly, I started building a small tool for myself.
That tool became WaitAgent.
GitHub:
https://github.com/kikakkz/wait-agent
After hundreds of iterations, I finally feel comfortable releasing the first public version:
WaitAgent 0.1.0
This Started As A Personal Tool
I did not initially plan to build another developer tool.
I just wanted something that solved my own daily workflow.
My current development environment is quite different from a traditional IDE workflow.
I usually work with:
- terminal
- SSH
- multiple machines
- multiple repositories
- multiple AI coding assistants
A typical day might look like:
Machine A
└── Claude Code
└── backend refactoring
Machine B
└── Codex
└── frontend implementation
Server C
└── another agent
└── experiments
Everything works.
Until it doesn't.
The Problem Was Not Running Agents
Running multiple agents is surprisingly easy today.
The difficult part is keeping track of them.
After a few hours, my environment looked like this:
I found myself repeatedly asking:
Where is that agent?
What was it doing?
Did it finish?
Does it need me?
Which machine was it on?
The agents were productive.
But my attention was becoming the bottleneck.
Then My Network Failed
This was another problem I didn't expect.
Imagine:
You have several agents running on remote machines.
Everything is working.
Then:
- Wi-Fi disconnects
- VPN changes
- laptop switches networks
- SSH connection disappears
The agents are still running.
But your control connection is gone.
Before WaitAgent, recovery looked like this:
Reconnect VPN
SSH machine A
Find tmux session
Remember what agent was doing
SSH machine B
Find another session
Try to recover context
The frustrating part was not reconnecting.
The frustrating part was rebuilding my mental context.
The hardest part was not restoring the terminal connection.
It was restoring the developer's state of mind.
Existing Tools Solved Only Part of The Problem
tmux is great, but it doesn't understand agents
I have used tmux for years.
It solves an important problem:
Keep terminal sessions alive.
But tmux only knows about terminals:
- window 1
- window 2
- pane 3
What I needed was something closer to:
Backend Agent
Claude Code
Running
Frontend Agent
Codex
Waiting
Research Agent
Completed
The terminal became the workspace.
But I needed a layer that understood my workflow.
I didn't need another AI framework
There are already many excellent AI agent frameworks.
But I was not trying to create:
- another autonomous agent system
- another workflow engine
- another coding assistant
I wanted something much simpler:
A better way for humans to supervise many agents.
Introducing WaitAgent
WaitAgent is a CLI-first workspace manager for developers running multiple AI coding agents.
The idea is simple:
Developer
|
|
WaitAgent
/ | \
Agent A Agent B Agent C
Claude Codex Other CLI Agent
WaitAgent does not replace your agents.
It helps you manage the space around them.
Why CLI First?
I intentionally built WaitAgent as a CLI-first tool.
Not because GUI is bad.
It is simply because this is how I work.
I have always been more comfortable working in the terminal. I use IDEs occasionally, but most of my daily workflow happens through:
- terminal
- SSH sessions
- command-line tools
- remote machines
When I started using multiple AI coding agents, this workflow became even more natural for me.
The terminal is where I usually:
- start agents
- check their progress
- review changes
- run tests
- inspect logs
- switch between projects
So I built WaitAgent for the environment where I already spend most of my time.
What WaitAgent Does Today
1. A Single View For Multiple Agent Sessions
When running multiple AI coding agents, the first problem is simple:
Where are all my sessions?
Before WaitAgent:
Terminal 1
Claude Code
Terminal 2
Codex
SSH Terminal
Another agent
The problem was not that these sessions disappeared.
The problem was remembering where everything was.
WaitAgent provides a sidebar where you can see your sessions in one place.
For example:
Sessions
> bash@local I
claude@192.168.31.125 R
kimi@10.235.6.45 R
codex@192.168.31.133 R
2. Multi-Machine Session Management
My agents do not always run on the same machine.
Sometimes they run on:
Laptop
|
Server A
|
Server B
The challenge is not starting these sessions.
The challenge is keeping track of them.
Without a session manager:
ssh server-a
find session
ssh server-b
find another session
WaitAgent allows me to manage sessions from different machines through the same interface.
3. Recover Sessions After Network Interruptions
This is one of the reasons I built WaitAgent.
When working with remote machines, network interruptions are inevitable.
Maybe:
- Wi-Fi changes
- VPN disconnects
- laptop sleeps
- SSH connection drops
The agents may still be running.
But the developer loses the connection.
Without a session manager:
Network lost
Reconnect
Find machines
Find sessions
Recover context
With WaitAgent:
Network lost
Reconnect
Continue from existing sessions
The goal is simple:
A temporary connection problem should not destroy your development flow.
The Design Philosophy
While building WaitAgent, I kept coming back to one simple idea:
Developers need visibility before automation.
When many agents are running, the first challenge is not making them more autonomous.
It is knowing:
What sessions exist?
Where are they running?
What state are they in?
Which one needs my attention?
WaitAgent focuses on making this information visible and reliable.
The future workflow may look like:
1 developer
+
10 AI agents
+
multiple machines
The challenge is not only making agents smarter.
It is helping humans stay productive while working with many agents.
What Comes Next?
WaitAgent 0.1.0 is still an early version.
Some things I am exploring:
- better session state tracking
- easier session switching
- richer remote workflows
- notifications
- integrations with external tools
But I want to keep the core idea simple:
Help developers stay connected with their AI coding sessions.
I Want To Hear From Other Developers
I built WaitAgent because I had this problem myself.
But my workflow might be unusual.
I would love to hear from developers experimenting with multi-agent workflows:
- How many AI coding agents do you run at the same time?
- Do your agents run on multiple machines?
- How do you manage sessions today?
- What information do you want when switching between agents?
If you are running multiple AI coding agents, I would love your feedback.
Repository:
https://github.com/kikakkz/wait-agent.git
Final Thoughts
AI coding agents are becoming more capable every month.
But when one developer starts running many agents, a new problem appears.
Not intelligence.
Not execution.
Continuity.
How do we keep our context when our work is distributed across many sessions and many machines?
WaitAgent is my first attempt to explore that future.
Top comments (0)