AI in the terminal — the agent's true home.

For most of computing, the terminal has been the surface where things actually happen. The browser is the world; the editor is the workshop; the terminal is the operating theatre. If we want AI agents that do things — not just chat about doing them — the terminal is where they belong.

The body problem

A common framing: an agent needs a body. A model alone is a brain in a vat — it can reason, but it can't act. Bodies are what let agents change the world. The question is which body.

Browser-as-body has a structural problem: the browser is a sandbox by design. It can't write to your filesystem, can't open ports, can't talk to your shell, can't even resolve localhost without an end-run. Every "browser agent" is an elaborate dance around that sandbox.

Editor-as-body is closer. An editor can write files. But an editor by itself can't run them, can't deploy them, can't kubectl logs the deployment that just failed. Every interesting agent verb ends up shelling out — and once you shell out, you're back in the terminal.

Terminal-as-body has none of these problems. The terminal already owns the PTY, the shell, the filesystem, and every cloud CLI ever written. The agent inherits all of it.

Why "real PTY" matters

Most "AI terminal" tools aren't terminals. They're transcripts — a textarea that pipes to a subprocess. Real shells need a pseudo-terminal device: programs check isatty() and behave differently. htop doesn't run in a transcript. ssh doesn't ask for a password in a transcript. tmux doesn't exist in a transcript. kubectl exec, half of git, every modern CLI with colored output — all of them want a real PTY.

AZMX AI ships portable-pty on the backend, xterm.js with WebGL on the frontend, shell integration via OSC 7 (cwd) and OSC 133 (prompt boundaries + exit codes) on Unix and a wrapped PowerShell prompt function on Windows. The agent can read the live buffer because it's a real terminal underneath, and the agent can run a command because it has the same PTY any shell has.

The "one window" claim

Tab-swapping is friction. Every time you context-switch between an IDE, a terminal, a Slack window, and a browser to do one task, the cost is taxed against the work. Most coding agents in 2026 still ask you to live across at least three surfaces.

The terminal-native agent collapses this. The shell is here. The editor is here. The agent is here. They share the buffer, the cwd, the open file. The agent doesn't have to ask "what's happening" — it's looking at the same screen you are.

The trust calculus

A terminal-native agent is also a security claim. Your terminal already has access to your keys, your SSH config, your AWS credentials, your kubectl context. An agent that lives there doesn't need new permissions — it inherits the ones you already gave the shell. That's good and dangerous in equal measure. Good because it removes the "paste another token" failure mode. Dangerous because the agent now sits in the most privileged surface on your machine.

The mitigation is the approval gate. Reads run automatically; writes pause for a human. Every shell command shows the exact command before it runs. A deny-list refuses .env, .ssh, credentials by default. This is the only safe shape for a terminal-native agent.

What you get when it all clicks

A failing test in the terminal becomes an explanation in the agent panel becomes a per-hunk diff in the editor becomes a commit you understand — without ever leaving the window. The loop closes in seconds. The thing that used to take ten minutes of context-switching takes ten seconds of attention.

That's the bet. The terminal was the first interface. It will be the last to fall. And when the agent shows up, it shows up here.

Read the full vision · Try AZMX AI