How to Orchestrate Multiple Agents from the Terminal

Do Windows Matter Less Than Limited Human Attention?

With the increasing popularity of command-line interface (CLI) building for agentic projects, terminal interfaces are seeing something of a rebirth in software development. However, as more developers utilize agentic tools, and increasingly, multiple agents at once, they’re turning to terminal multiplexers to give each agent their own separate pane that segregates and preserves the work of each across sessions.

But what happens when you start utilizing so many agents at once, and have to have so many terminal windows open that it becomes difficult to keep track of everything? Open-source creator Gaurav Gosain noticed this limitation and began building his project TUIOS in response. On the surface, TUIOS acts as a multiterminal orchestration tool, but as he explains below, it’s ultimately a way to address one of the trickiest new bottlenecks in software: The limited attention of a human user.

TUIOS helps users orchestrate agents across multiple terminals. Image courtesy tuios.dev

From Multiple Terminals to Multi-Agent

Gosain notes that the project started from pursuing a better terminal experience. “I live in the terminal for pretty much everything, and while tmux is great, it always felt stuck in a world of memorized key chords and config files.” The creator points out that while the project was initially about all-in-one window management UX, it soon highlighted a deeper need.

“A multiplexer sees every program you run, its output, its title, the folder it's in, and yet it never really did anything with any of that. Once I started running coding agents in my panes, that became the part I actually cared about. I didn't need help arranging my windows anymore, I needed something to tell me which one of them was waiting on me.”

As Gosain started running several agents in parallel, arranging panes stopped being the problem. Knowing which agent needed him became the problem. “An agent would hit a permission prompt, draw it once, and then just sit there.” Different screens that were in different project states looked identical at a glance, and would sit waiting for a human thumbs up. “It was a pretty silly way to lose time.”

“TUIOS already owned every one of those panes, so it felt obvious that it should be the one keeping track.” For the creator, giving cues to help agentic power users like himself was becoming increasingly important (though the project still offers an ‘agents-off’ feature for those who just want a better multiplexer).

Where Do Agent-Plus-Human-in-the-Loop Systems Break?

Gosain suggests that there’s more to any agentic job than simply how many agents are in play. “I don't think there's a linear curve like five, then 10, then 100 [agents being a breaking point]. It depends on the work. Ten agents doing well-defined changes against a good test suite is honestly easier to manage than two agents doing open-ended design work.”

“What breaks first, at least for me, is attention. Spinning up agents is the easy part now. Every lab ships some way to run them in parallel, and some can kick off hundreds of subagents in one go. But producing a hundred results is cheap, and figuring out which ten are actually good is not. If you can't review it, running more of it doesn't really help you.”

The creator suggests that the project evolved to help human users spend their limited attention span more wisely. “Agents report what state they're in and the ones that need you [get floated] to the top.” The project collects questions and approvals, and agent turns get saved at git checkpoints to make fixes easier, with cheap verification being something to work on in the future.

The creator suggests that the bottleneck in human-plus-agent systems is still, from his perspective, human attention and decision-making. “I think that's how it should be. I don't want an agent deciding on its own to force push or delete something important.

“But I also don't think the answer is asking the human about everything. If you get asked a hundred times an hour, you stop reading and just hit yes.” Gosain suggests that major AI labs are trending in the direction of letting classifiers handle routine approvals, which is probably for the best.

The creator suggests that his approach is about streamlining the decision process to fewer, better questions with the assumption that the routine stuff can and will run on its own. “And when something does reach you, it comes with enough context that you can decide in a few seconds.”

“I also think the bottleneck moves over time. ‘Can this agent run this command?’ will mostly get automated away. ‘Is this actually the right change?’ won't, at least not soon. So review doesn't disappear, it shifts from reading every line to looking at evidence, like whether the tests pass or how two attempts compare.”

Where Terminal-Level Orchestration Fits in the Big Picture

Gosain is frank about why he decided to keep the project as something that sits on top of other harnesses, rather than trying to also build his own coding agent. “The harnesses get better every week, and the teams behind them are a lot bigger than one person working on an open source project on the side. I also just don't think another agent is what people need. Most people have their favorite, and a lot of them use two or three depending on the task.”

“Something I noticed this year is that pretty much every lab shipped its own ‘which of my agents needs me’ view, and each one only knows about its own agent. That's fine if you only use one tool, but most people I know don't. TUIOS recognizes 24 agent CLIs right now, and anything it doesn't know still runs fine as a normal terminal program.”

The creator clarifies that his goal wasn’t to create a defensible moat around a single, winner-take-all harness that outcompetes all other labs’ harnesses. “[This] is exactly why a neutral layer is useful. We also saw how fast access can change, when a lab decided to cut off [access to its tools].” Rather than depend on any one vendor’s roadmap, the project was built to work with multiple tools as well as to be directly compatible with tmux through a tmux shim.

“Pretty much every lab shipped its own ‘which of my agents needs me’ view, and each one only knows about its own agent. That's fine if you only use one tool, but most people I know don't.” - Gaurav Gosain/Creator, TUIOS

Failstates, Agent Reliability, and Learning Job-to-Job

The creator notes that he specifically built a fan functionality to parallelize task execution across multiple agents, each in its own worktree, partly as a learning aid, but mostly to compare approaches. “Different models fail...and succeed in different ways. If I give the same problem to three agents, I'll often get three reasonable approaches, and seeing them side by side helps me think about the problem. Agent time is cheap and mine isn't, so it's a pretty good trade.”

“The part I care about most is comparing.” The creator explains that fans let you run your own checks on every attempt, compare the results side by side, and diff the attempts against each other. To help users improve on their own processes, the project allows for annotation that can be shared with agents, effectively giving users the final say based on specific evidence pulled from each agentic run.

According to Gosain, learning from agents on the job is valuable, but only within the bounds of limited autonomy. “The rough rule I ended up with is that agents can do the work and agents can say no, but only a person gets to say yes to something risky.”

“In practice, that means only you can answer an agent's permission prompt. Another agent can deny a risky request if you've allowed it to, but it can never approve one. An agent can't give itself more access, and it can't give a helper more access than it has. Even if an agent edits the config file to give itself more, nothing changes until you apply that change yourself from outside TUIOS.”

Gosain suggests that agents generally don’t go astray because they’re inherently malicious. “They go wrong because they're confident and fast. We've all seen the stories of an agent wiping a production database because it found a token lying around. That's what I worry about, an agent being completely sure about something it really should have asked about.”

The creator also points out that his project has its limits, controlling what an agent can do through its multiplexer, but not everywhere else. “The ‘ask a human’ path has to be quick and painless, otherwise people just turn it off.”

Managing Agents Via Terminal: Identity and Loopholes

Gosain points out that the project has built-in identity management for jobs specifically run through the project itself. “Every pane in TUIOS has grants that say what the program inside it is allowed to do through TUIOS: Read its own session, type into it, start other agents, answer prompts, or do everything. The daemon checks every single call against them, no matter how it comes in. So if I want a reviewer agent that can look but not touch, I just start it with read-only.”

The creator explains that while his project focused on least privilege rather than full-blown identity management, teams will likely need IAM systems for both human engineers and agents in the future (and major identity vendors are already hard at work building them).

“Building grants taught me a few things agents need that most systems don't have yet. Access should be tied to a task rather than a person. It should only ever be passed down, so an agent can give a helper less than it has but never more. You should be able to take it away while the agent is still running. And you need a clear record of which agent did what, and on whose behalf.”

Gosain adds that untrusted text remains a potential loophole, as agents will read anything from anywhere and potentially interpret what they read as instructions. Text hidden in PR titles, invisible characters in Unicode, and others. “That kind of labelling really needs to become standard everywhere.”

The Future of the Terminal: Long Horizon and Org-Wide Projects

While the terminal remains popular for individual devs, Gosain isn’t sure it will scale for major projects across an entire organization. “I think the terminal is the right place for agents to run and for you to step in, but not where you'd set goals and budgets for a whole department."

“When an agent gets stuck I want to see exactly what it sees, type into its session, and take over if I need to. That's really natural in a terminal and pretty awkward from a dashboard. It's also where agents already do their work anyway, with the shell, git and tests.”

For long-horizon runs, the creator points out that sessions require a different layer underneath that supports persistent sessions beyond a laptop close. With a significant amount of time and effort, the creator was eventually able to implement a much-requested daemon to restore sessions post-restart into this project, but larger orgs will presumably need more.

“For bigger organizations, I'd expect higher-level tools on top that handle goals, ownership and cost, and TUIOS is built to sit underneath those. Pretty much everything it does is available as a command, as JSON, as an event stream and through MCP, so something else can drive it while a person can still jump into any agent whenever they want.”

Lessons Learned: Testing, Ownership, Docs, Community

The creator shares many important lessons learned while building the project. “Testing is the big one. Early on I literally wrote in an issue that I was still trying to figure out how to test TUIOS properly, because testing a TUI with real shells inside it is way harder than it looks. Now the tests I trust most start the real binary, attach a real client and read what's on the screen. I even ended up building a separate tool for it.”

“The other half of that lesson is that a test that can't fail is worse than no test at all, because it makes you feel safe. I found three tests that had been green for months and could never go red. Now every bug fix needs a test that I've actually watched fail with the fix removed.”

“Second, figure out early who owns what. A lot of the hardest bugs came from two parts of the system both thinking they owned the same data. One fun one was a full scrollback costing 232MB per pane, and paying it twice, once in the daemon and once in every client.”

“Third, write things down. I've written more than 40 posts on the TUIOS blog, mostly about bugs I got wrong the first time. It's made me a better engineer, and I think people trust a project more when it's open about its mistakes.”

“And listen to your users. Copy mode, custom keybindings, and the daemon all started as issues people opened. Not everyone will like every choice either. Some people think mouse support in a TUI defeats the whole point, and that's fine, keyboard-first is still the default.”

“A test that can't fail is worse than no test at all, because it makes you feel safe. I found three tests that had been green for months and could never go red. Now every bug fix needs a test that I've actually watched fail with the fix removed.”

The Future of Orchestration (From the Terminal or Otherwise)

Gosain reflects on what will happen to projects like his in the future: Will they become less necessary as individual agents become more competent and easier to manage? Or more necessary as more teams onboard larger swarms of agents?

“I think both things happen at the same time. Agents need less babysitting every few months, which means people will run more of them, on longer tasks, across more machines. The total amount of agent work is going to grow way faster than the number of decisions one person can make in a day.”

“So I don't think tools like TUIOS go away. I think the job changes. Today it helps you keep an eye on a handful of agents. Next it has to tell you when to look, show you the evidence when you do, and let you jump in at any moment. And honestly, a lot of TUIOS today gets built by agents running inside TUIOS, so I'm motivated to get that part right!”