Using an AI agent to run a command can seem ridiculous. If I want to list the files in the current directory, I can type:
lsOr I can tell an agent:
List the files in this directory.
The second option takes longer to type and spends LLM tokens, and the agent will probably end up running ls anyway. So what exactly did I gain? That was my knee-jerk reaction to using agents for simple command-line tasks.
Sure, agents save me from memorizing obscure commands and arguments. I can talk to my computer in plain English instead of remembering whether a particular option is --resource-group, --resourceGroup, -g, or something else entirely. Convenient? Absolutely. Worth putting an LLM between me and every command I run? I’m less sure. But that comparison assumes that everything goes right, and that’s where it falls apart.
A command is a step
Imagine that I want to accomplish something using a CLI. I figure out the command, type it, press Enter, and it works. Great. Had I asked an agent to do the same thing, it might have translated my request into exactly the same command. I’d have saved myself some recall, but probably not much time. Depending on the task, writing the prompt might even have taken longer than typing the command.
Now imagine that the command fails. Suddenly, I have work to do. I need to read the error and understand what it means. I need to figure out whether the problem is the command, my configuration, authentication, permissions, a missing dependency, an incompatible version, or something else entirely. I might need to search the web or the documentation, or run another command to inspect the current state. Then I change something, try again, hit another error and investigate that one. Eventually, hopefully, I get back to what I originally wanted to accomplish.
The command itself took a second, but recovering from its failure might take twenty minutes. That’s because when I execute a command, I’m asking the computer to perform a step. If that step fails, the computer has done its job: it tried to execute my instruction and reported what happened. The problem is mine again.
An agent can own the outcome
Now consider the same task delegated to an agent. I don’t need to tell it which command to execute. I can tell it what I want to achieve, and that’s usually closer to what I actually care about anyway. I care that the application is deployed and that the project builds. I care that the dependency is updated, the development environment works or the resource is configured correctly. The commands are merely means to those ends.
The agent figures out the steps. Maybe its first command works. Maybe it doesn’t, and even then the task hasn’t failed. For the agent, the error is just another piece of information. It can inspect the error, investigate the environment and consult the documentation. Then it changes its approach, runs another command, verifies the result and continues. What would have interrupted my work becomes part of its trajectory.
That’s a fundamentally different contract. When I run a command, everything that happens after I press Enter is up to me. When I delegate an outcome, the agent takes on the work of getting from its first attempt to the result I asked for. Commands execute instructions. Agents pursue outcomes.
A good contractor owns the problem
Suppose something in your house needs fixing. You could hire a contractor and give them a precise sequence of instructions: remove this screw, take off this panel, replace this part, put the panel back, tighten the screw. But that’s probably not why you’re hiring an expert. You tell them what’s wrong and what you want instead, and they figure it out.
Perhaps they remove the panel and discover that the problem isn’t what either of you expected. They inspect it and adjust their approach. They replace a different component, test it, discover another issue and fix that too, until they give you what you asked for. You hired them to own the problem, including the parts neither of you could see before the panel came off. Of course, that doesn’t mean they should disappear into your house, make arbitrary changes and eventually announce:
Done.
A good contractor communicates. If they discover something consequential, they tell you. If there are several reasonable approaches with meaningful tradeoffs, they explain them and ask you to decide. They use their expertise to determine what they can handle themselves and what requires your involvement. Agents should work the same way. When you delegate an outcome, the agent absorbs the mechanical work and still involves you when your judgment matters. And if there are decisions you always want to make yourself, you can say so upfront.
Failure changes the economics
It’s tempting to evaluate agents by comparing them with the individual actions they replace. Why ask an LLM to run ls when you can just type ls? On the happy path, that’s a perfectly reasonable question. There, the agent is a slightly more convenient but significantly more expensive interface to the exact same operation, and sometimes it’s outright wasteful. But that comparison puts an action next to an outcome.
When something goes wrong, the difference between doing the work yourself and delegating it becomes enormous. A command that succeeds immediately might save me ten seconds if delegated. A command that fails might send me into twenty minutes of reading error messages, inspecting state and checking documentation, trying fixes and undoing them, and then figuring out how to resume the original task. An agent can absorb most of that. And crucially, I don’t need to predict beforehand whether the command will fail. I’m delegating the uncertainty along with the work.
So the more uncertain the path is, the more interesting delegation becomes. If I know exactly what needs to happen, know the command will work and can type it faster than I can explain it, I’ll just run it. Sometimes ls really is faster than asking an agent what’s in a directory. That’s also why happy-path demos and individual command executions make agents so hard to judge. They show an agent performing a known action, while its value appears when the known action turns out not to be enough and the agent keeps going.
The command was never the job
For decades, we’ve expressed our intentions to computers as increasingly sophisticated sequences of operations. We learned commands and APIs, configuration formats and tool-specific syntax. Agents introduce another interface, where you describe the state you want to reach and let the system figure out how to get there.
A command says do this. An agent can be told make this true. The first delegates an action. The second delegates responsibility for navigating the path between where you are and where you want to be, including every failure along the way.
Maybe we’ve been looking at the extra tokens the wrong way. When an agent runs a command you could have typed yourself, you pay for more than the command. You pay for an agent that deals with whatever happens next.