Driving Coding Agents: Terminal UI or Protocol? A Deep Dive into Two Integration Paths

When developers try to run multiple coding agents at once inside a single unified application, the most intuitive approach is to spin up a pseudo-terminal (pty) for each agent and type commands into it just like a human user would. This idea works at first, but as task complexity and agent capabilities grow, its limitations surface quickly.

Why the Terminal UI Approach Breaks Down

Take Codex's terminal interface as an example: when it's busy executing a task, messages typed through the pty cannot be received, so you can't intervene or adjust direction mid-task. What's more, the screen output format changes between versions, making any logic that relies on parsing the TUI (text user interface) to determine an agent's state extremely fragile.

Determining whether an agent is waiting for input effectively becomes pure guesswork. You cannot reliably extract the signal "human intervention needed now" from a pile of ANSI escape sequences and dynamically refreshing text. For automation scenarios that require precisely orchestrating multiple agents, this uncertainty is fatal.

Pseudo-terminal (pty) is a kernel facility in Unix systems used to emulate real terminal devices; tools like SSH, tmux, and xterm all rely on it. When a program starts a child process through a pty, the child process believes it is connected to a real interactive terminal, and thus outputs ANSI escape sequences and responds to control keys normally. Because of this, pty is often used to "script" programs that only offer interactive interfaces.

But this approach has a fundamental mismatch: pty exposes a human-visual byte stream, not a program-oriented structured interface. To determine what state an agent is in, developers can only pattern-match against the text rendered on screen. And TUI applications typically draw their interfaces using full-screen refreshes, cursor positioning, color highlighting, and other techniques; the same logical state may correspond to completely different byte sequences across frames. This makes parsing logic both complex and prone to breaking with version changes, and is the root cause of the "guessing game" described in the article.

The Protocol Approach: Certainty Brought by Structured Events

Turning to each agent's own protocol interface, the situation is completely different. Claude Code streams JSON events, presenting every tool call, every question, and every turn's end as structured data. Codex provides codex app-server, which lets you send messages during an ongoing turn, enabling true real-time intervention. Gemini CLI and Cursor's agent adopt the ACP (Agent Client Protocol) protocol.

The core advantage of these protocols is that you no longer receive screen text that needs to be parsed by eye; instead you get explicit event types—tool calls, pending questions, turn completion. Programs can make deterministic logical judgments based on these events, without relying on regular expressions to "scrape" screen content. In one developer's words, this approach "doesn't require screen scraping."

ACP (Agent Client Protocol) is an open protocol designed for communication between editors/IDEs and coding agents, promoted by the Zed team, with goals similar to what LSP (Language Server Protocol) provides for language tooling. It defines a set of JSON-RPC-style request/response and notification messages covering session creation, prompt sending, tool-call authorization, file read/write, and other interactions, so that clients don't need to write a private integration for each agent.

Comparing ACP with the respective JSON event streams of Claude Code and Codex, the difference lies in the level of abstraction: the latter two are each vendor's own "native" interfaces, with fields and semantics evolving alongside the product; ACP attempts to define a neutral middle layer, with the agent side implementing the protocol server and the editor side implementing the client. If multiple agents all follow ACP, the client only needs to maintain a single implementation. Of course, whether the protocol can truly converge depends on whether enough agents adopt it, which is exactly the unknown emphasized at the end of the article.

The Cost: Fragmentation and Version Drift

The protocol approach isn't without cost. There is currently no unified standard in the industry, and each agent requires a separately written adapter. More troublesome is that the protocols themselves change almost in lockstep with agent iteration—an interface that works today may have field adjustments in the next version. This means ongoing investment in maintaining adapters is unavoidable.

This fragmented state is an engineering reality that all tool developers building on top of agent CLIs must face long-term. Choosing the protocol route means accepting higher initial development costs and a continuous maintenance burden, in exchange for runtime reliability and controllability.

The adapter pattern is a classic technique in software engineering for isolating interface differences: writing a thin wrapper for each heterogeneous data source or service, converting its unique API into the unified shape expected by the upper-layer system. In the context of this article, writing an adapter for each of Claude Code, Codex, Gemini CLI, and Cursor means the upper-layer orchestration logic only faces unified events like "tool call / pending question / turn end," rather than directly depending on any agent's raw JSON structure.

The adapter pattern can significantly reduce coupling in upper-layer code, but the cost is shifting complexity into the adapters themselves. When underlying protocols change frequently, each adapter must be independently updated and tested. Therefore, in practice, contract testing or record-and-replay mechanisms are often introduced: using fixed samples to verify whether adapters still parse correctly after protocol changes, keeping the risk of "version drift" within manageable bounds.

The Real Dilemma for Developers

In actual development, many teams may find themselves in a hybrid state: some agents driven through protocols, others still relying on terminal emulation. While this hybrid mode offers temporary compromise, it increases system complexity and inconsistency.

If you're building a tool based on agent CLIs, a key decision is: do you choose to stand on top of agents' own protocols, or stay at the terminal layer? Or wait for some unified standard to win out? Whether ACP, currently the only protocol with cross-agent tendencies, will become that convergence point remains an open question.

This discussion about integration approaches is essentially a trade-off for automation tools between "rapid adaptation" and "stability and reliability." The terminal UI path lowers the initial barrier but sacrifices runtime determinism and programmability; the protocol path demands more upfront investment but opens up possibilities for complex multi-agent orchestration.

One-line Summary

Comparing the trade-offs between terminal UI and protocol integration paths for coding agents.

Paragraph Summary

The article compares two integration paths for driving coding agents. The traditional approach uses a pty to emulate a terminal and type commands like a human, but when an agent is busy you can't inject messages mid-task, and TUI output formats change between versions, making state detection nearly guesswork and unsuitable for precise multi-agent orchestration. The protocol path has Claude Code streaming JSON events, Codex providing an app-server for real-time intervention within a turn, and Gemini CLI and Cursor adopting the ACP protocol, letting programs make deterministic judgments based on explicit event types and completely eliminating screen scraping. The cost is that there's no unified industry standard, each agent requires separate adaptation, and rapid protocol iteration brings ongoing maintenance costs. Developers therefore face the choice of standing on proprietary protocols, staying at the terminal layer, or waiting for ACP to converge—essentially a trade-off between rapid adaptation and stability and reliability.