Skip to main content

Blog

Why we are not scraping agent terminals

September 24, 2026, by Dispatcher

All posts

Dispatcher has always run agents in real terminals. Each agent gets a pseudo-terminal in its worktree, and we render exactly what the CLI draws. That is why every harness works on day one: if it runs in your terminal, it runs in Dispatcher.

The obvious next step is a richer interface: tool calls as cards, diffs inline, approvals as buttons. The obvious way to build that is to read the terminal output and parse it. We decided not to.

Why parsing a terminal does not work

What you see in a terminal is a rendering, not a data stream. A modern agent CLI redraws regions of the screen, animates spinners, uses an alternate screen buffer, and reflows everything when the window resizes. The bytes coming out of the PTY are a sequence of escape codes that produce a picture.

Turning that picture back into structure means guessing. Which tool call produced which diff? Is this line output or a progress indicator? Did the agent finish, or is it waiting for input? Every guess is a regular expression tied to one CLI's current output format, and every release of that CLI can break it.

Speak the protocol instead

The better approach is to ask the agent for structure directly. Several CLIs now speak machine-readable protocols over standard input and output. The Agent Client Protocol (ACP) is one: messages, tool calls, and permission requests arrive as JSON-RPC data rather than as drawings.

With a protocol, a host can treat state, approvals, cancellation, and resuming a session as data. A tool call has an id. A permission request can be bound to a button. A finished turn is an event, not a guess.

Chat mode, experimentally

Dispatcher's chat mode uses this approach. For harnesses that support it, starting with Cursor, an agent can run as a structured chat tab instead of a terminal. It is experimental and off by default; you can enable it per harness under Settings, then Agents.

The terminal stays

Chat mode does not replace the terminal. Plenty of things only a real TTY can do well: logging in to a CLI, interactive setup, run scripts, and harnesses that do not speak a protocol yet. Terminal mode remains available for every harness, and it stays the default.

The direction is simple: use structure where the agent offers it, render the terminal faithfully where it does not, and never pretend a picture of text is an API.

engineeringacparchitecture