You need an agent to drive a desktop application that nobody ever gave an API. So you start planning the wrapper: a server to run, every action described in a schema, a transport, a session to hold it together. Then, out of habit, you run the program with its help flag and read what comes back. There is a command that inspects the application and prints its state as structured data. There is a command that updates one resource and reports which objects actually changed. The interface you were about to build is already installed, and half of it was never written for your eyes.

The machine sells, the clerk remembers

A shop can serve you two ways. There is the machine by the door: you press a code, the thing drops, the transaction is over. It does not know who you are, does not remember the customer before you, and does not mind if you press the same code over and over. Everything it can do is printed on the front of it.

That is what an agent-native command line is. Commands that stay consistent, a help flag that explains itself without a manual, output in a structured form for machines and a readable form for people. Beside it sits a skill: a written account of the workflows, their prerequisites and their limits, so the agent never has to infer the interface from a window on a screen or from documentation scattered across a wiki.

The other way to be served is the person at the counter. They hold your session. They remember what you already looked at, keep the thing you are considering in hand while you examine the next one, and answer questions that would not fit on a keypad. That is roughly what a protocol server gives you: state that survives between calls, introspection rich enough to ask what is there, and an exchange that loops, each answer shaping the next request. Both sell the same goods. They bill differently.

The machine is cheap because it forgets

For a coding agent driving the same test command through a long run, forgetting costs nothing and everything else is a gain. The commands are narrow and discovered when needed rather than declared up front, so little has to be loaded before the work starts. Nothing is held open between calls. Each call is a line you can read, replay, put behind a permission rule, or run in a sandbox — the material you need to decide what the agent may do unattended. And a structured result turns a failure into a value the agent can branch on, instead of a paragraph it has to interpret.

The bill arrives the moment the work stops being repetitive. An agent opening a browser to make sense of an interface it has never seen needs the page it just loaded, the element it just clicked, the position it reached after several steps. Rebuild that from nothing on every command and the run is spent getting back to where it already was. There the open session earns its overhead: the state is expensive, so holding it beats recreating it. The two mistakes are mirror images. Reach for the protocol for every short action and you pay in schema and verbose output for continuity you never needed. Reach for the shell when the work genuinely needs that continuity, and you pay in turns.

The loop decides this, not the protocol

None of which makes the older interface automatically right. A command line that prints only decorative text, with no structured result for errors or for state, is a graphical interface in a costume: the agent can drive it, but it cannot check anything it did. Agent-native is a design decision, not a property of being old, which is why the interesting work is generating that surface — structured output plus a skill — for software never meant to be automated.

So the question is not which technology is more modern. It is what your loop looks like. High throughput, well specified, the same action repeated, you already know what you want: the machine by the door is faster, cheaper, and easier to audit. Exploration, where the next step depends on what you just saw and the context would be expensive to rebuild: pay for the counter. The same system can be served both ways, and the right answer moves as the work moves from finding out to repeating. What makes the agent dependable is not which side you chose but that you chose it for the loop you actually have, the same reason the loop is the product.

The command line never cared whether a person was typing.