Agent orchestration, when what you actually have is too many tabs open

orchestration

Agent orchestration means two unrelated things. In the frameworks that own the term, it’s the code that decides which agent runs when, inside a program you are writing. For most people who search it, it means something plainer: several coding agents are running right now, and you can’t tell which one needs you. Those problems have different fixes.

Worth sorting out which one you have before you go shopping, because the search results only answer the first one.

where the word comes from

“Orchestration” arrived here from software you write, not software you use.

Look at what the top results actually are. LangGraph describes itself as “a low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents.” You build a graph, add nodes and edges, define a shared state object, and the framework runs it. CrewAI gives you Agents, Tasks, and a Crew, with a sequential or hierarchical process deciding execution order. Microsoft Agent Framework, which absorbed AutoGen and Semantic Kernel in October 2025, does the same job for .NET and Python.

These are excellent tools. They are also all libraries. You import them, you write Python or TypeScript or C#, and the thing you produce is an application that contains agents. Orchestration there is a programming concern: routing, state, retries, who gets called next.

There’s a second, older meaning sitting in the same search results. Airflow, Prefect, Dagster, and Temporal are workflow and data orchestration tools, built to run scheduled task graphs reliably. Several of them now market toward agents too, which muddies the word further.

Neither meaning is about the thing on your screen.

what you actually have

You are running agents like Claude Code or Codex, in a terminal, on repos that already exist. You didn’t build them. You started them. Four in one project, two in another, one you opened yesterday and forgot.

Nothing needs routing. Each agent already knows what it’s doing. What’s broken is much dumber:

  • One of them stopped ten minutes ago waiting for you to approve a git push, and it looks identical to one that’s still thinking.
  • One finished. You don’t know which.
  • Two of them are editing the same file in the same working directory, and you’ll find out at commit time.
  • You have no idea which tab belongs to which repo, because tabs are named after your shell.

That’s an attention problem, not a control-flow problem. No graph library fixes it, because the graph isn’t missing. You are the graph, and you’re the part that’s overloaded.

the three questions

Strip it down and supervising running agents is three questions, asked constantly:

  1. Which one needs me right now?
  2. Which one is finished?
  3. Which two are about to collide?

Every genuinely useful thing you can do about “orchestration” at this level is an answer to one of those.

answering them without buying anything

Start here, because a lot of the pain is fixable in an afternoon.

Make finished and blocked make a noise. Claude Code fires hooks on lifecycle events, and the two worth wiring first are Notification (the agent wants your input) and Stop (the turn ended). In ~/.claude/settings.json:

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"needs you\" with title \"agent\"'"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"done\" with title \"agent\"'"
          }
        ]
      }
    ]
  }
}

Check the current hooks reference before you copy that, since the event names and payloads do move. The point stands either way: a blocked agent should reach you, rather than waiting for you to go looking.

Name the tabs after the work. Most terminals let a program set the title. Put the repo and the task in it, so tab-hunting becomes reading instead of clicking.

Give collision-prone agents separate working copies. Two agents in one directory is the single most common way a good session turns into a bad afternoon. Git worktrees are the fix and they’re built in:

git worktree add ../myapp-auth -b feature/auth
git worktree add ../myapp-tests -b chore/tests

Each agent gets its own checkout on its own branch, and they merge back when they’re done. Our git worktree guide has the full mechanic, and two agents on the same repo covers what breaks when you skip it.

Cap the number. Three or four agents you can actually read is more output than nine you can’t. How many agents can you actually run works through where the real ceiling sits, and it isn’t your CPU.

That set gets a lot of people most of the way. What it doesn’t fix is the part that scales worst: every one of those answers still arrives as text, in a stream, in a window you may not be looking at.

where the tooling has to change

A terminal treats every session as the same undifferentiated stream of characters. It cannot tell you which tab is blocked, because it doesn’t know what “blocked” is. That’s the ceiling on the DIY version, and it’s structural.

crystl is built on the other side of that line. Sessions are structured records rather than pixel streams, so the state of each agent is something the system knows rather than something you infer. What falls out of that:

  • Approval requests float as panels color-coded by project, so question one answers itself. They also push to your phone.
  • Sessions are grouped by project as gems and shards instead of a flat row of tabs, and the agent activity panel shows every agent’s live state across every project in one view.
  • Isolated shards are git worktrees created for you, so question three stops being your job.
  • Any CLI agent counts. Claude Code, Codex, and others run side by side, which no single agent vendor will ever do for you.

None of that is a graph library, and it isn’t trying to be.

if you actually are building agents

Then the search results were right and this post isn’t for you. If you’re writing an application where an LLM has to hand work to another LLM under conditions you define, use a framework. LangGraph if you want explicit control over state and edges. CrewAI if role-and-task modeling fits how you think. Microsoft Agent Framework if you’re already in .NET or Azure. OpenAI’s Agents SDK if you want the smallest surface area. Those tools exist because that problem is real and unpleasant to hand-roll.

The mistake is only in the crossover: reaching for an agent-building framework when what you needed was to know which of nine terminals is waiting on you.

the shape underneath

There’s a third question hiding behind all of this, which is how the agents should relate to each other once you do have several: one lead handing tasks down, or peers talking sideways in a shared channel. That’s a genuine design question with real research on both sides, and we wrote it up separately in roundtable agent orchestration.

For the tools that do the seeing, see the best AI agent orchestration tools for coding.

But it comes second. First you need to be able to see them. A team you can’t watch isn’t orchestrated, it’s just running.

crystl is free. Sign up at crystl.dev/login.