A human can click. An agent cannot. Every part of my stack that only answers to a mouse is a part agents cannot reach, and that is now the same thing as a part that does not get worked on.
Author: James Phoenix | Date: September 2026
The Click Is the Bottleneck
I used to audit a stack for coupling, or test coverage, or deploy risk. Now I audit it for one thing first: how much of it can only be operated by a person moving a mouse.
The answer is always worse than I expect, and rarely because of the application itself. The app has an API. It is the edges that fail the test. The billing toggle in a vendor dashboard. The DNS record. The feature flag someone flipped in a web console at 2am. The migration that runs from an admin panel. The design token that only exists inside Figma. Each one was a reasonable decision made when a human was the only operator, and each one is invisible until an agent hits it and stops.
A capability that exists only behind a GUI is, from an agent’s point of view, a capability that does not exist. It cannot be composed, retried, tested, or reasoned about. It can only be requested from me, which turns every autonomous run into a run that pauses.
The Three Callers Test
The audit is mechanical. For each capability, ask whether three callers can reach it: a browser session, a script holding an API key, and an agent holding a token.
I have already written about what breaks when all three hit the same route in The Same Endpoint Now Has Three Callers. What I did not write down is the step before that one, which is finding out how many capabilities have only one caller at all.
Two failure shapes come out of this, and they are not equally dangerous.
The first is a capability with no non-GUI path whatsoever. Annoying, but honest. The agent stops, tells me, and I go click the thing.
The second is a capability with a non-GUI path that quietly skips checks the GUI was enforcing. That is the one that bit me: validation constants lived at the HTTP decode edge, the agent’s tool callbacks called the service facade directly, and so the agent path had no bounds checking at all. The second shape is worse precisely because it looks like success. When you delete a transport, you have to relocate everything that transport was silently enforcing.
Unity Just Made This Argument for Me
On 20 July 2026, Unity shipped a standalone Unity CLI: a single self-contained binary with structured JSON and TSV output, clear exit codes, non-interactive installs, and service-account auth for CI. It manages editors, projects, licences, headless builds, and test suites. It also ships unity command and unity eval, which run C# live inside a running Editor or Player with no project recompile or domain reload, which is a REPL into a live game.
Unity’s own framing is that “more and more of development happens in the terminal: in scripts, in CI, and increasingly in the hands of AI agents.” The gap they name is sharper than that: assistants could already generate code, but they “can’t run the tests to see if it works.”
Sit with what that is. A game engine, the most irreducibly visual and GUI-bound category of professional software there is, decided its editor needed a text interface, because otherwise agents could not verify their own work. If a 3D scene editor can be made headless, the excuse that your product is “too visual” for a CLI is dead.
The competitive read is mine rather than Unity’s, but it is hard to miss. Community MCP bridges for the Unity Editor appeared in March 2025 and the first-party CLI arrived sixteen months later, by which point the largest of those bridges had passed fourteen thousand stars. Godot has its own. A platform agents cannot drive gets routed around, and the routing-around is usually called a competitor. Unity did not ship this because terminal users asked nicely. They shipped it because the alternative was ceding the agent workflow to whoever did.
The Direction Is Toward MCP, Then Straight Past It
The detail I find most interesting is that Unity is replacing its in-Editor MCP server with the CLI. For any agent that can run shell commands, the docs tell you to prefer unity command and unity eval directly, because they are faster and use fewer tokens than MCP.
That is the same conclusion I reached in The MCP Abstraction Tax, arrived at independently by a company with far more at stake. The protocol layer buys discovery and costs fidelity and tokens, so once an agent already knows the surface, the wrapper is pure overhead.
Which sets the order of work. Headless does not mean “ship an MCP server.” It means the capability exists as a callable, scriptable, exit-code-returning thing, and MCP is one optional wrapper over it. Build the wrapper first and you have shipped a protocol with nothing behind it.
What I Deliberately Leave Human
This is not an argument for headless everything, and a note that stopped here would contradict how I actually work.
The point of making something headless is to remove a mechanical step, not to remove a decision. I keep the human review gate on merges, and I want to keep it. A stack that is fully headless and fully ungated is a dark factory, and I have argued at length in Lights-On vs. Dark Software Factories that the lights should stay on.
So the audit has two columns rather than one: can an agent drive this, and should it drive this unattended. Most things should be headless and gated, which is not remotely the same as manual. A deploy behind deploy --dry-run that prints a diff and waits for my approval is fully headless and fully gated. The click I removed was the mechanical one. The judgment stayed.
How I Run the Audit
- List every capability the product and its operational surface expose, vendor dashboards included.
- Mark each one GUI-only, scriptable, or agent-reachable.
- For anything scriptable but not GUI-equivalent, find what validation the GUI was quietly doing and re-home it below the transport.
- Rank the GUI-only ones by how many times in the last month an agent had to stop and ask me.
- Fix the top three. Ignore the rest until they earn a place in the ranking.
Step four is the one that keeps this honest. Most GUI-only capabilities are fine to leave alone forever, and a headless-everything crusade is how you spend a month building interfaces nothing calls. The frequency of interruption is the ranking function, not the elegance of the resulting CLI.
One Sentence
Audit your stack for capabilities that only answer to a mouse, rank them by how often they stall an agent mid-run, and give the top few a scriptable path with the GUI’s validation moved underneath it, because a platform agents cannot drive is a platform they route around.
Related
- Agent-Native Architecture - The parity principle this note turns into a retrofit procedure
- The Same Endpoint Now Has Three Callers - What breaks once browser, script, and agent share a route
- Rewrite Your CLI for AI Agents - How the scriptable surface should be shaped once it exists
- The MCP Abstraction Tax - Why the CLI comes before the protocol wrapper
- Own Your Control Plane - Owning the primitives you are making headless
- Lights-On vs. Dark Software Factories - The bound on how far to take this
- Backend-First Products - Why text-in, text-out surfaces get more agent leverage
