The Agent Orchestration Landscape: Where Callipso Fits in April 2026

Six months ago, "AI coding agent" meant one thing: a single assistant in your editor. Today it means five Claude Code sessions rewriting your backend in parallel while you review diffs over coffee. The tooling around this shift is exploding — the design choices diverge sharply, and new entrants appear every week.

We mapped every orchestrator we could find. Terminal multiplexers written in Go. Desktop apps that replace your IDE entirely. Cloud platforms running hundreds of agents headlessly. Voice controllers on iOS. We looked at what they build, what they skip, and what trade-offs they make.

This is not a product comparison — we are obviously biased. It is a landscape survey from the perspective of builders who had to make their own architectural bets. We will be honest about where those bets are ahead and where they are behind.

The Core Problem

The workflow is straightforward: you have three features to build, a bug to fix, and tests to write. You want five AI agents running simultaneously, each in its own git worktree, each making progress while you review.

The naive approach — five terminal tabs, manual branch management, copy-pasting prompts — breaks down fast. You lose track of which agent is doing what. Branches collide. You send a prompt to the wrong session. The cognitive load of managing the agents exceeds the work the agents are doing.

Every tool in this space exists to solve that problem. They disagree on how.

Three Philosophies

After studying the landscape, we see three distinct approaches. Each reflects a different bet about how developers will work with AI agents.

Philosophy 1: Replace the IDE

Intent (Augment Code), OpenAI's Codex App, and to some extent Conductor (Melty Labs) take the boldest position: build an entirely new environment designed around agent orchestration from the ground up.

Intent introduces a coordinator-implementor-verifier pipeline. A planning agent uses Augment's Context Engine to understand your task and propose a plan as a living specification. You review and approve. Then implementor agents execute in isolated git worktrees while a verifier agent checks results against the spec. When requirements change, updates propagate to all active agents. It is architecturally coherent — and it explicitly markets itself as an IDE replacement.

Since our first version of this post, Intent shipped a bring-your-own-agent (BYOA) model — you can now run Claude Code, Codex, or OpenCode inside Intent's workspace. This is a meaningful change: you are no longer locked into Intent's agent. However, the environment lock-in remains. You are still running those agents inside Intent. Your existing iTerm2 tabs, your Ghostty windows, your Cursor terminals — Intent does not see them. BYOA means "bring your own agent into our house." It does not mean Intent comes to yours.

OpenAI's Codex App takes a similar approach. Threads of agents run in parallel, each with isolated code copies, managed through a purpose-built desktop surface. It runs on both macOS and Windows. Multi-agent workflows spawn specialized sub-agents, with Codex handling orchestration across threads.

Conductor from Melty Labs provides a dashboard of all agents — "who is working on what" — with real-time code review, trace logging, and automated PR creation. Each agent gets its own worktree. Checkpoints provide automatic snapshots with rollback. The free tier shifts costs to the AI services themselves — BYOK.

The upside of this approach is deep integration. When you control the entire environment, specs can update automatically, agents share context natively, and the UI reflects agent state in real time.

The downside is environment lock-in. You abandon your existing workflow. Your Cursor keybindings, your iTerm2 profiles, your Ghostty config — gone. Even with BYOA softening the agent lock-in, you still have to move your work into their environment. The switching cost is high when most developers have spent years customizing their setup.

Philosophy 2: Multiply Terminals

Claude Squad, Plural, and the Composio Agent Orchestrator take the opposite approach. They are lightweight multiplexers — spawn N agents, each in a tmux pane or its own worktree, manage them through a terminal UI or framework.

Claude Squad is the most well-known, written in Go. It supports five different AI CLIs: Claude Code, Aider, Codex, OpenCode, and Amp. Each agent runs in a tmux session with its own git worktree. The TUI shows all sessions at a glance. Single binary, works anywhere tmux runs.

Superset is an open-source terminal for running 10+ parallel AI agents, now supporting eight CLI agents: Claude Code, Codex, Gemini CLI, OpenCode, Aider, Copilot, Cursor Agent, and Superset Chat. Each session gets its own git worktree. A persistent daemon survives crashes and app restarts, so long-running tasks continue even when you close the window. Apache 2.0 license, zero telemetry, SOC 2 compliant.

Agent Deck is a Go + Bubble Tea TUI with a distinctive feature: Conductors. These are persistent Claude Code sessions that monitor and orchestrate all other sessions — watching for agents that need help, auto-responding when confident, escalating to you when they cannot. Socket pooling shares MCP processes across sessions via Unix sockets, reducing MCP memory usage by 85-90%. Optional Telegram and Slack integration for remote control.

ittybitty takes the simplest approach: specify a task and it spawns a Claude instance in a tmux virtual terminal. Agents can recursively spawn sub-agents. Minimal surface area — just a shell script and tmux.

myclaude treats Claude Code as an orchestration layer rather than the sole agent. It coordinates multiple AI backends — Codex, Gemini, OpenCode — from within Claude Code, keeping you in a single terminal context instead of switching between tools.

Plural focuses on forking sessions and broadcasting prompts across branches and repos. It can import issues from GitHub, Asana, and Linear, then dispatch them to parallel agents.

Composio Agent Orchestrator is a framework rather than a UI. It manages fleets of agents with a Planner layer (task decomposition) and an Executor layer (tool interaction). Each agent gets its own worktree, branch, and PR. When CI fails, the agent fixes it. When a reviewer requests changes, the agent addresses them.

The upside is low adoption friction. Claude Squad is a single Go binary. Superset is a single install with a daemon. No Electron, no server, no extension to install.

The downside is that these tools live entirely inside the terminal. If you are working in VS Code or Cursor, you context-switch between your IDE and the TUI. There is no awareness of which terminal belongs to which IDE window. The orchestrator cannot see your IDE terminals — it only knows about the tmux sessions it created.

Philosophy 3: Work With Everything

This is where Callipso sits. Instead of replacing your tools or living inside a terminal multiplexer, it floats as a transparent overlay on top of whatever you are already using.

The core idea: discover terminals across every IDE and terminal app on your machine and provide a unified control surface. Say "fix the auth bug, please one" and the transcribed text routes to terminal 1, regardless of whether it lives in Cursor, VS Code, Ghostty, or iTerm2.

No new IDE to learn. No tmux dependency. Your existing workflow stays intact. You get a command layer on top.

The Landscape in One Table

Where Callipso Is Ahead

Cross-Platform Terminal Discovery

This is our strongest differentiator. Callipso discovers terminals across nine platforms simultaneously:

IDE Adapters (via extensions):
  ├── VS Code
  ├── Cursor
  ├── Windsurf
  └── Antigravity

Terminal App Adapters (via native macOS APIs):
  ├── iTerm2      (event-driven Python API + AppleScript)
  ├── Terminal.app (AppleScript automation)
  ├── Ghostty     (AX watcher + kernel TTY injection)
  └── Kitty       (env-safe session registration)

Terminal Multiplexer Adapters:
  ├── tmux        (detached session detection)
  └── cmux

Built-in:
  └── Embedded Terminal (xterm.js + node-pty)

Every competitor assumes a homogeneous environment. Claude Squad only sees tmux sessions. Intent only sees its own workspace — even with BYOA, it cannot discover your existing terminals. Codex App only runs its own agents. Warp Oz only runs in Warp. Superset runs agents in its own terminal. Agent Deck manages its own tmux panes. Paperclip orchestrates autonomous agents with no IDE awareness at all.

Real developer setups are not homogeneous. You might use Cursor for the frontend, Ghostty for infrastructure scripts, and iTerm2 for quick debugging. Callipso sees all three, assigns a global terminal index, and routes to any of them through one interface. Nobody else does this.

The Adapter Problem: Ghostty vs iTerm2

The reason nobody else attempts cross-app terminal discovery is that every terminal application exposes a different level of programmatic control — or none at all. There is no standard API for "list your terminals." Each application requires its own adapter, and the engineering ranges from trivial to absurd depending on what the application gives you to work with.

The two extremes in our adapter set are iTerm2 (full API) and Ghostty (no API). The contrast illustrates why this problem is hard and why a generic approach does not exist.

iTerm2: The Gold Standard

iTerm2 ships a Python API with async event monitors. Callipso runs a long-lived Python daemon that maintains a persistent connection to iTerm2 via ~/.iterm2-socket:

Electron App (Node.js)
  → iTerm2Adapter (TypeScript)
    → iTerm2DaemonClient (process manager)
      → Python Daemon (iterm2_daemon.py)
        → iTerm2 Python API (iterm2 module)
          → iTerm2 Application via Unix socket

The daemon subscribes to native event monitors — FocusMonitor, SessionTerminationMonitor, EachSessionOnceMonitor, LayoutChangeMonitor. Events arrive immediately when sessions are created, destroyed, or focused. No polling lag. The daemon queries session variables (CWD, job name, PID, TTY) directly. Terminal IDs are native UUIDs in the format iterm2:{window}:{tab}:{session}, stable across focus changes and reorders.

Sending text is a single API call: session.async_send_text(text). Focusing a session: session.async_activate(). Creating a tab with a specific working directory: window.async_create_tab(profile_customizations). No focus stealing, no clipboard manipulation, no keystroke simulation.

If the Python daemon fails to spawn (wrong Python version, missing module), the adapter gracefully degrades to it2api, iTerm2's built-in JSON-RPC CLI tool. Same operations, polling-based instead of event-driven. The fallback chain ensures iTerm2 terminals are always discoverable.

Ghostty: Engineering Without an API

Ghostty, created by HashiCorp co-founder Mitchell Hashimoto, has no scripting API, no extension system, no socket, no RPC interface. Yet it is one of the fastest-growing terminal emulators — 2ms key-to-screen latency — and developers are adopting it rapidly. We had to support it.

The solution stitches together four macOS primitives:

GhosttyAdapter (AppAdapter interface)
  → GhosttyManager
    ├─ GhosttyPoller
    │   ├─ Process tree scanning (ps + pgrep)
    │   ├─ Accessibility window enumeration (System Events)
    │   ├─ AX event watcher (compiled helper binary)
    │   └─ Shell-to-tab matching (CWD heuristics)
    │
    └─ GhosttyClient
        ├─ ghostty-bridge (kernel TTY injection)
        ├─ Clipboard paste fallback (Cmd+V)
        └─ AXPress tab switching (no focus steal)

Discovery: pgrep -x ghostty finds the main process. ps -e -o pid=,ppid=,tty=,command= builds the process tree. We walk descendants to find shell processes with real TTYs — each TTY is one terminal tab. Then the Accessibility API queries Ghostty's window hierarchy for tab counts, selected tab indices, and radio button labels (tab titles). The hard part is matching shells to visual tab positions: a three-pass heuristic compares CWD basenames against AX tab titles, then foreground process names, then falls back to PID order.

Control: A compiled ghostty-bridge binary writes directly to TTY devices using kernel injection — text appears in the terminal without Ghostty needing focus. For tab switching, the bridge sends AXPress on specific radio button elements identified by window position and tab index. Without the bridge, everything falls back to clipboard paste (Cmd+V) and keystroke simulation (Cmd+N for tab switching), which steals focus.

Event detection: A compiled ax-watcher helper binary observes Accessibility notifications (AXCreated, AXUIElementDestroyed, AXFocusedWindowChanged, AXSelectedChildrenChanged) and emits JSON events to stdout. The poller debounces these into immediate re-polls — sub-50ms detection latency, comparable to iTerm2's event-driven model.

The contrast:

Both adapters implement the same AppAdapter interface — poll(), sendText(), focusTerminal(), createTerminal(). The TerminalStoreManager does not know or care which adapter produced a terminal. A Ghostty terminal and an iTerm2 terminal are both TerminalEntity objects in the normalized store, routable by UUID.

This is why the adapter pattern matters. The complexity of controlling ten different platforms is contained within nine adapter implementations. The rest of the system — the store, the session manager, the voice router, the overlay UI — operates on a clean, uniform data model. Adding support for a new terminal app means writing one adapter, not modifying the core.

Voice Routing by Terminal Index

Callipso has two voice routing modes — magic word commands and hotkey routing. The magic word is the primary mode for most users.

Magic word "please": Say "fix the auth bug, please one" and the transcribed text routes to terminal 1. Say "add dark mode, please three" and terminal 3 gets it. The keyword parser extracts the destination from natural speech — no hotkeys, no switching windows, no clicking. The word "please" followed by a terminal number (or name) is all it takes.

The magic word also supports special commands:

• "please new" — creates a new terminal
• "please commit" — triggers a scoped commit
• "please resume auth bug" — resumes an archived session by name

Hotkey routing (alternative mode): A clipboard-based state machine for users who prefer keyboard shortcuts.

Stage 1: Clipboard Detection
  STT engine transcribes speech → text lands in clipboard
  → Callipso detects the change, stores text with 30-second expiry

Stage 2: Destination Selection
  User presses Cmd+Opt+F1 (or F2, F3, F4)
  → Callipso routes stored text to that terminal index

State Machine:
  IDLE → TEXT_WAITING (clipboard stored)
       → DESTINATION_WAITING (hotkey pressed)
       → ROUTE_READY (both exist) → IDLE (text sent)

The state machine handles timing edge cases: speaking before pressing the hotkey, pressing the hotkey before speaking, or pressing a new hotkey before the previous route completes. A sticky destination mode keeps the target terminal active for 20 seconds, so consecutive voice commands go to the same place without re-pressing the hotkey.

VoxHerd is the only other tool doing voice seriously — an iOS app that routes spoken commands to agents via WebSocket with on-device recognition. But it routes by project, not by terminal index. You cannot say "please three" to target a specific terminal in a specific IDE window.

Non-Invasive Overlay Model

This is a design philosophy, not a feature. Callipso does not replace your IDE. It does not ask you to learn a new environment. It does not require abandoning tool configurations you have built over years.

The overlay floats on top of your desktop with click-through transparency. Terminal list, task status, recording controls — all visible at a glance without switching windows. You interact with your existing tools exactly as before. Callipso adds a control layer; it does not replace anything.

Intent explicitly says "the IDE is dead." We disagree. The IDE is not dead — it is just missing a conductor.

Session-Isolated Routing

When multiple Claude Code sessions run in the same Cursor window, they share the same CLAUDE_CODE_SSE_PORT. Naive routing based on the port sends your prompt to the wrong session.

Callipso solves this with session_id — a UUID generated per Claude Code invocation via the hooks system. The SessionStore maintains bidirectional maps between SessionId and TerminalUUID. Routing uses session_id for disambiguation, eliminating cross-pollination entirely.

This is subtle infrastructure, but it is the difference between "parallel agents work sometimes" and "parallel agents work reliably." Tools that rely on tmux or their own terminal implementation sidestep this problem by design. Tools that need to work across existing IDE terminals — which only Callipso does — must solve it explicitly.

Real-Time 3D Codebase Visualization

The Space tab renders your codebase as a 3D star field using Rust, WebAssembly, and WebGPU. AI agents appear as ships navigating between files. When an agent reads a file, the ship moves toward it. When it writes, the node pulses.

No other orchestrator has visual debugging at this level. It is experimental, it is optional, and it is the feature that makes people stop and watch. The Space Tab: Behind the Scenes post covers the Rust/WASM architecture in detail.

Where Callipso Is Behind

We would rather be honest about our gaps than have users discover them.

CLI Support Is Expanding but Not Equal

Callipso's deepest integration is with Claude Code — hooks, session IDs, task state, timer tracking, token usage, git diffs. Gemini CLI hook integration is now supported as well, but not at the same depth.

Claude Squad supports five CLIs. Superset now supports eight. Composio works with any MCP-compatible client. VoxHerd supports Claude Code, Codex, and Gemini CLI.

Our adapter architecture is extensible — adding deeper Gemini CLI or OpenCode support is engineering work, not a design problem. The gap has narrowed since our first version of this post, but if you run a mixed fleet across many different CLIs, some will have richer integration than others.

No Autonomous Planning Layer

Intent's coordinator-implementor-verifier pipeline is genuinely powerful for large tasks. You write a spec, the coordinator decomposes it, specialist agents execute in parallel, a verifier checks results. The spec updates as agents learn. It is a self-correcting system.

Composio's Planner-Executor architecture does something similar: high-level decomposition with correction loops when tools fail.

Callipso is a routing orchestrator. You decide what goes where. The system routes your voice, manages sessions, tracks state — but it does not decide how to decompose a large task into parallel subtasks. That planning remains with the human (or with the AI agent's own sub-agent spawning).

Both models have merit. Autonomous planning is more powerful for large, well-specified tasks. Human-in-the-loop routing is more flexible for exploratory work where the developer is actively steering. We chose the latter, and we think it is the right default for how most developers work today. But the planning layer is where Intent and Composio are ahead.

macOS Only

Callipso uses macOS-specific APIs extensively:

• AppleScript for iTerm2 and Terminal.app control
• NSWorkspace for application monitoring
• Accessibility APIs for terminal discovery

The Codex App already runs on macOS and Windows. Claude Squad is cross-platform (Go + tmux). Warp Oz is cloud-based. Our addressable market is limited to macOS developers — which is a large audience (most AI-first developers are on Macs) but not the full market.

No Cloud or Headless Mode

Warp's Oz runs agents in persistent cloud environments, triggered by cron jobs, webhooks, GitHub Actions, or Slack messages. Composio can manage 30+ agents headlessly. These tools enable team-scale automation where agents run overnight, process issue backlogs, and create PRs without a human at the keyboard.

Callipso requires an active desktop session. It is a developer productivity tool, not a CI/CD agent farm. For solo developers and small teams working interactively, this is not a limitation. For organizations wanting to scale agent execution across a team, it is.

No Automated CI Feedback Loop

Conductor and Composio close the loop: agent pushes code, CI fails, agent reads the failure log, agent fixes and re-pushes. This cycle can repeat autonomously until tests pass.

Callipso has git worktree support, commit buttons, and merge-to-main UI. But the CI-failure-to-fix cycle is still manual. You see the failure, you tell the agent to fix it. The routing is fast, but the human is still in the loop for error recovery.

The Autonomous Orchestrators and Platform Plays

Several tools deserve separate mention because they operate at a fundamentally different level — headless, autonomous, dashboard-driven. You set a goal and walk away. No terminal windows, no real-time interaction, no voice.

Warp Oz is a cloud platform for running coding agents at enterprise scale. Agents run in persistent cloud environments with cron, webhook, and API triggers. Multi-model support (Claude, Codex, Gemini). Every agent run generates a shareable audit trail. Multi-repository support enables cross-repo changes. Self-hosted option for enterprises. Oz now writes 60% of Warp's own PRs — they are eating their own cooking.

Paperclip exploded onto the scene in April 2026 with 42,000+ GitHub stars and a provocative tagline: "open-source orchestration for zero-human companies." You build an org chart of AI agents — CEO, managers, workers — assign goals, and agents execute via headless CLI processes (claude --print with stdin piped, stdout captured). No terminal windows. No IDE awareness. No visibility into running processes. A heartbeat scheduler wakes agents at intervals, they check for assigned work, execute, and report results to a React dashboard. Agents communicate through an issue tracker database, not direct conversation. Paperclip is a back-office orchestrator: you define work, check the dashboard later. It is closer to Warp Oz than to Claude Squad — the agents run headlessly in isolated git worktrees under .paperclip/worktrees/, not in terminals you can see or interact with.

GitHub Copilot Agent can be assigned GitHub issues directly. It spins up an ephemeral dev environment via GitHub Actions, implements the fix, and creates a PR. No local environment needed. This is the zero-setup end of the spectrum.

New in April 2026: GitHub Copilot /fleet shipped a /fleet command that decomposes tasks into parallelizable sub-tasks and dispatches subagents. Each subagent gets its own context window with a shared filesystem. Available to all paid Copilot tiers. This is GitHub bringing multi-agent orchestration directly into its ecosystem — significant because of the distribution advantage. Every Copilot subscriber gets it for free.

These tools solve a different problem than Callipso. The metaphor: Paperclip and Warp Oz are like assigning tickets to a remote team and checking Jira in the morning. Callipso is like sitting in mission control watching every screen. They are for teams that want agents running autonomously at scale, or for developers who want orchestration without real-time interaction. Callipso is for developers who want to sit in front of their terminals, talk to their agents by name, and watch the work happen live.

VS Code's Built-In Multi-Agent Mode

Worth noting: VS Code shipped multi-agent orchestration in February 2026. You can run multiple Copilot agents in the same editor, each working on different files, with a coordination layer that prevents conflicts.

This is native, free, and deeply integrated. Combined with Copilot /fleet, VS Code developers who use only Copilot now have a fairly complete multi-agent story without installing anything. The limitation is scope: it only works within VS Code, only with Copilot, and only within a single editor window. Cross-IDE, cross-terminal, and cross-CLI orchestration are out of scope.

The Positioning Map

             Autonomous ──────────────────────────── Human-in-Loop
                  │                                       │
                  │  Intent (BYOA)                        │
        Replace   │  Codex App                             │
        IDE       │  Conductor                             │
                  │                                       │
   ───────────────┼───────────────────────────────────────┼──────
                  │                                       │
        Headless/ │  Warp Oz       Claude Squad            │  Callipso
        Single    │  Paperclip     Plural                  │
        Platform  │  GitHub Agent  Superset                │
                  │  Copilot /fleet Composio               │
                  │                                       │
              Multi-IDE ──────────────────────────── Multi-IDE

Callipso occupies a unique quadrant: multi-IDE support with human-in-the-loop voice routing. The space has gotten more crowded since March — Paperclip and Copilot /fleet are significant new entrants — but they sit firmly on the autonomous/headless side. Most competitors are either headless and autonomous (Warp Oz, Paperclip, Copilot /fleet), single-environment and human-controlled (Claude Squad, Conductor), or environment-replacing (Intent, even with BYOA). Nobody else sits in the multi-IDE, human-in-the-loop quadrant.

The question is whether that quadrant grows. We believe it does — because developers use multiple tools, and the tools that meet them where they are will win over the tools that ask them to move.

What We Are Watching

Three trends are shaping this space right now:

Agent-to-agent communication is shipping. Claude Code Agent Teams now has dedicated hooks — TeammateIdle, TaskCreated, TaskCompleted — with agent_id and agent_type fields for subagent tracking. Anthropic's Claude Code Review deploys agent teams on every PR, jumping their internal code review coverage from 16% to 54%. This is not theoretical anymore. When agents coordinate without human mediation, the orchestrator's role shifts from routing to monitoring. Callipso already tracks subagent file edits and shows them in the diff badge — but deeper integration with Agent Teams is on our roadmap.

MCP as a standard. Model Context Protocol is becoming the lingua franca for agent-tool communication. Composio already supports any MCP client. As more CLIs implement MCP, the adapter-per-platform model (which Callipso uses today) may give way to a single MCP integration that works everywhere. We are watching this closely — if MCP matures to the point where every terminal app exposes a standard interface, the hard adapter engineering we did for Ghostty and iTerm2 becomes unnecessary. That would be a good outcome for developers, even if it commoditizes our advantage.

The landscape is splitting into cockpits and back offices. Warp Oz, Paperclip, and Copilot /fleet are back offices — headless, autonomous, dashboard-driven. You define work, agents execute, you review results. Callipso, Claude Squad, and VoxHerd are cockpits — real-time, interactive, you are in the loop while agents work. These are fundamentally different interaction patterns. Paperclip's 42,000 stars prove there is enormous demand for the back-office model. But developers who want to watch their agents work, talk to them by voice, and steer in real time — that is a different market, and it is ours.

Our Bet

We believe the orchestration layer should be additive, not replacive. Developers should not have to abandon their IDE to gain multi-agent capabilities. The orchestrator should meet them where they are — in Cursor, in Ghostty, in VS Code, in iTerm2 — and provide a thin, powerful control surface on top.

The tools that ask you to replace everything are betting that agent-first development is so different it needs a new paradigm. Maybe they are right eventually. But in April 2026, developers are still working in IDEs they have customized for years, still using terminals with specific configurations, still switching between tools that each do one thing well. The landscape has gotten more crowded since we first wrote this post — but the new entrants reinforce our thesis. They are all either building new environments or living inside tmux. Nobody else is meeting developers where they already are.

An overlay that connects all of them — with voice routing, session isolation, and real-time visibility across ten platforms — that is the bet we are making. "Fix the login flow, please one." Terminal 1 gets it. Keep everything else exactly as it is.