Journey to Cairn

The terminal stopped being one place

I did not set out to build an agent orchestrator. I was trying to make ordinary coding work less lossy.

A terminal used to be a place I could hold in my head. One repository, one shell, one train of thought. Even with several tabs, position acted as memory: server on the left, tests on the right, risky experiment on another desktop.

Coding agents changed that relationship. A terminal could now contain work that continued without me: reading a repository, changing files, running tests, stopping for approval, or finishing while I looked elsewhere. The terminal remained the right execution surface, but screen position no longer described the work well enough.

The first response was to open more terminals, name them carefully, and isolate attempts with worktrees. That increased capacity and increased the state I had to remember. Returning became harder than starting. Which session needs a decision? What changed? Is it safe to collect? Can I resume the exact conversation rather than create a second copy?

Claude Code made the loop credible

The important thing about the first useful terminal agent was not the chat. It could participate in the development loop.

When Anthropic introduced Claude Code in early 2025, it could inspect a repository, edit files, run commands and tests, and work with Git from the command line. That crossed my delegation threshold. I could describe an outcome, let the agent encounter the real project rules and failures, then review an attempted change.

The terminal also gave the work durable coordinates. Processes, directories, SSH connections, worktrees, and command output were already legible to other tools. An agent could join that environment without inventing a separate document model for the repository around it.

One useful agent quickly became the smallest stable unit. I wanted another to investigate, one to review, and one to run a focused test. Current Claude Code has broader parallel mechanisms, but my earlier pressure was simpler: the terminal agent worked, so I started giving more work to terminal agents. The next constraint was the harness around them.

pi made the harness malleable

Pi changed what I thought I was configuring. The assistant was no longer the product boundary. The harness was.

Pi describes itself as a minimal terminal coding harness. Its core stays small while extensions, skills, prompt templates, packages, providers, and programmatic modes let the user shape the loop. Instead of negotiating with a fixed product, I could compose a worker for a specific job.

That felt like malleable software in practice: adapt the tool when a need appears, then return to the work. I built spawn commands that created a specialist, started it in an isolated worktree, placed it in a visible pane, and recorded a small handoff. Upstream pi did not claim that orchestration opinion; it was a local extension built from pi's primitives.

The freedom moved complexity outward. A composable harness needs durable naming, permissions, isolation, visible state, and a path from a result back to the terminal that produced it. It also needs project context that survives the individual conversation. Repo guidance can restore what an agent should know; the remaining problem was restoring where the human should return.

The lasting lesson was not that one harness should contain every workflow. It was that trustworthy primitives should remain concrete: terminal, workspace, session, worktree, evidence, and handoff.

cmux made parallel work visible. tmux made it durable.

Starting workers was no longer the interesting problem. Keeping a coherent relationship with them was.

cmux arrived at the right moment. Native workspaces, splits, vertical tabs, notifications, and a command interface turned custom pi workers into visible places. Parallel work went from a diagram in my head to something I could watch and steer.

Visibility solved a real problem, but a screen full of excellent panes was still a screen full of panes. As more work moved to always-on remote machines, Ghostty plus tmux became the durable arrangement. A session could survive an SSH disconnect, remain on its host, and be reattached later.

Together, those experiments clarified three separate properties that had looked like one problem:

1. Capacity: launch several workers without making them interfere.
2. Visibility: see the output and state of each worker.
3. Continuity: return later and recover the exact work, context, and decision.

Git worktrees handled filesystem isolation. Notifications surfaced moments. By late summer, Codex subagents made explicit ownership and parallel verification part of the same local loop. Across tools, the pattern converged: agents could work separately, but the operator still had to reconstruct which sessions belonged together, which result had been reviewed, and where a response should go.

Attention became a state, not a notification

A useful signal should remain true whether it appears in a tab, workspace summary, attention queue, or terminal.

Early notifications were local events: a bell, badge, color, or message attached to one pane. They helped, but they did not form a reliable model. Output could stop because an agent needed approval, had finished, had failed, or had lost its connection while the underlying remote session continued.

Cairn treats run state as evidence with confidence. Supported integrations can report lifecycle events directly. Process and screen evidence can provide a weaker inference. Stale or contradictory signals stay distinct rather than being promoted into certainty. An attention queue is useful only if it does not train the operator to ignore it.

The practical vocabulary stays small: running, waiting, needs a human response, done, or suspended. The labels may look different in each view, but they should project one canonical state. Change the example below and watch three views remain coherent.

The departures board became the useful metaphor. A station does not show a live thumbnail of every train. It compresses identity, destination, state, recency, and exceptions into a surface designed for scanning. Cairn applies that principle around the terminal: show the operational facts at a glance, then let the operator dive into the concrete session.

What Cairn is now

Cairn is a native, persisted operations workbench built around real terminals.

It began from the conviction that terminal fidelity was not negotiable. The visual container changed repeatedly, but three commitments survived:

• Keep execution honest: local shells and SSH work remain ordinary terminal sessions, with worktrees providing real filesystem isolation.
• Keep identity durable: repositories, workspaces, terminal tabs, and supported Claude Code, pi, and Codex sessions stay related so re-entry can use each tool's verified resume or fork command.
• Keep attention shared: live state, needs-you signals, activity, and history describe the same work at different altitudes.

The dock is closer to an airplane panel than a universal canvas. A user can split, resize, replace, and persist first-party instruments around the active workspace. That is bounded malleability: the arrangement can change without making the terminal, workspace, session, and evidence model vague.

The terminal remains the center because it is still the most honest place to inspect the work. Cairn's job is to make that terminal findable, contextual, and recoverable when the number of active stories exceeds working memory.

More agents require more compression

Scale is not a reason to render every session as a live terminal. It is a reason to separate inventory, attention, and engagement.

Only the sessions a person is actively using need expensive live terminal rendering. Everything else can remain lightweight identity, state, evidence, and history until it becomes relevant. That is how an interface can grow from several agents to dozens or hundreds without turning each worker into an equal thumbnail.

Thousands of agents remain a design horizon, not a present usage statistic. Reaching that horizon requires aggregation, delegation, permission boundaries, provenance, and review. The hierarchy must compress: agents into sessions, sessions into workspaces, workspaces into projects or hosts, exceptions into an attention queue, and decisions back into the exact terminal where they belong.

Later products show the same pressure

Kiro Crew and Grok Bot arrived after Cairn's earlier interface experiments, so they are not origin points for this story. They are useful evidence of convergence: persistent workers, explicit state, activity, approvals, handoffs, and a way to return from another surface.

Once agents persist and work in parallel, chat history stops being the primary object. The roster, state model, permission boundary, and return path become first-class. Cairn's answer remains terminal-first and native: start from a high-level signal, then descend into the real process, files, worktree, and session behind it.