The Parallel Agent Problem

Last week I had six terminal windows open. Claude Code in one, fixing an authentication bug. Codex in another, writing tests. A third terminal running Gemini, generating documentation. Three more handling various subtasks.

I realized I had no idea which agent was doing what.

This is the parallel agent problem. And it's why I built Rithm.

The Shift from Assistant to Agent

Something changed in AI coding tools over the past year. They went from assistants—answer a question, generate a snippet, move on—to agents. Agents run autonomously. They explore codebases, make decisions, execute multi-step plans. Claude Code can work for 15 minutes straight without you touching the keyboard.

This is powerful. It's also a coordination nightmare.

When I was using a single AI assistant, I could hold the context in my head. One conversation, one thread of work. But once I started parallelizing—delegating different tasks to different agents—the cognitive overhead exploded.

Which terminal has the auth fix? Did that test agent finish? Is Codex waiting for my input or still thinking?

I found myself constantly switching windows, scanning terminal output, losing the mental model of what was happening where.

Context Is the Bottleneck

Here's the insight that drove Rithm's architecture: context is the bottleneck, not capability.

Claude can write code. GPT can write code. Gemini can write code. The hard part isn't getting output—it's giving the right input. And for agents working in parallel, the human has to maintain context for all of them simultaneously.

Chat interfaces make this worse. They're ephemeral. Each conversation is isolated. You finish one task, close the window, and that context is gone. Tomorrow you're starting from scratch.

Tasks don't work that way. A task persists. It accumulates context: the description, the files involved, the terminal history, what the agent tried, what worked, what didn't. Come back a week later and everything is still there.

One Task, One Terminal, One Workspace

Rithm's core architecture decision: each task gets its own dedicated terminal session.

Not a shared terminal. Not a new terminal every time. A persistent workspace bound to that specific task. The shell state survives—environment variables, working directory, command history. Close the app, reopen it tomorrow, and your task's terminal is exactly where you left it.

This sounds simple, but the implications are significant:

1. Spatial memory works again. Task A is in row 1. Task B is in row 2. Your brain can map position to context without reading.
2. History is preserved. What did the agent try last time? Scroll up. It's all there.
3. Parallel work becomes manageable. Five agents working on five tasks? Five terminals, each tied to a specific unit of work.

The terminal isn't just an output window. It's the task's working memory.

The LED Status System

But binding tasks to terminals only solves half the problem. You still need to know what each agent is doing without constantly checking each window.

I borrowed a metaphor from hardware: the status LED.

Every device has LEDs that communicate state at a glance. Power on. Network activity. Disk I/O. You don't read anything—you recognize patterns instantly.

Rithm applies this to agent management. Each task has a colored indicator:

• Gray: Idle. Nothing happening.
• Purple (pulsing): Working. Agent is thinking or executing.
• Amber (pulsing): Clarification. Agent has a question for you.
• Red (pulsing): Permission. Agent needs approval for an action.
• Green: Complete. Ready for your review.

Glance at the task list. See which LEDs are purple. That's where the work is happening. See an amber LED? That task needs your input. Red? Something needs your approval.

No window switching. No terminal scanning. Ambient awareness.

Why This Matters Now

The timing isn't accidental. Agent-based coding is becoming the default. Claude Code, Codex CLI, Gemini CLI—these aren't experiments anymore. Developers are using them daily for real work.

And the trend is toward more parallelism, not less. If one agent can ship a feature, five agents can ship five features. But only if you can manage them.

The tooling hasn't caught up. We're using the same terminal emulators and window managers we used before agents existed. The human coordination layer is missing.

Rithm is that layer.

The Takeaway

When I started building Rithm, I thought the hard problem was terminal integration or agent APIs. It wasn't. The hard problem was giving humans a way to stay oriented while multiple agents work in parallel.

The solution wasn't better chat. It was better coordination primitives: tasks that persist, terminals that remember, and status indicators you can read at a glance.

The future of AI coding isn't a single brilliant agent. It's an orchestra of agents, each handling a piece of the work, with the human as conductor.

You can't conduct what you can't see.