When a company decides it needs agents, the reflex is to go find a developer. That instinct is wrong, and it is going to cost companies a year and two hundred thousand dollars to learn it.
I built an agent studio this weekend. The first agent it runs is mundane on purpose: pull revenue from a Google Sheet every morning and post it to a Slack channel. The interesting part is not the task. It is who gets to change it. When someone decides the number should go to the general channel instead of the revenue channel, they do not file a ticket. They edit the instruction, hit send, and a coding agent generates a pull request against that agent's file. A human reviews it. Done in minutes.
That loop is the whole argument. The most expensive thing about traditional software development is the gap between the person who knows what the system should do and the person who can make it do that. You say "it should just do this," and the engineer says "do what, exactly?" and you burn a week in translation. The operator who owns the process does not have that gap. They are the requirement.
This is why individual agents belong to operational thinkers, not developers. The ops person already writes the procedures, already knows why the integration is misbehaving, already understands the change-management reality of the business. Handing them a coding agent does not turn them into a programmer. It turns them into a supervisor of one. They contribute at a higher level than an end user and a more grounded level than an offshore dev who has never met the customer. I argued a version of this in the case that review is a primitive, not a screen: approval is where the operator's judgment lives.
Developers do not disappear. They own the common machinery: the integrations, the runtime, the level-two support when an API stops behaving. But the agent that posts your revenue, flags your expenses, or triages half your inbox should be owned by the person who lives in that workflow. This is the forward-deployed model applied to operations, not engineering.
Stop hiring a nerd to build your agents. Hire an operator and give them a factory.
Key takeaways
- Individual agents should be owned by operational thinkers who understand process, not by developers who own the underlying machinery.
- The painful back-and-forth between a business owner and a software engineer disappears when the operator can change the agent directly.
- Developers are still needed for level-two support of the common infrastructure, but not for editing each agent.
FAQ
Doesn't building agents require a software engineer?
It requires a coding agent and a clear thinker. The operator writes the spec and supervises the change; the coding agent writes the code. A developer is only pulled in when the shared infrastructure or an integration breaks.
What makes an operations person a better agent owner than a developer?
Agents automate process work. The person who already owns the process, writes the procedures, and debugs why something is not working is closer to the requirement than a developer who has to translate vague instructions into code.
Related Essays
The Agent Owner Is a New Job, and It Is Not Engineering
Enterprises need agent owners, not more prompt engineers. Maintaining a fleet of agents is mechanic work, and the people closest to the work can do it on the right fabric.
Agent Leverage Needs an Owner
Most engineering orgs have hit baseline coding agent adoption and stalled. The reason is organizational, not technical. No one owns making the agents better.
The Single Pane of Glass Is a Custom App, Not a Chat Window
Enterprise agent interfaces need more than chat. The real interface is a custom micro app where agents surface context and humans take action.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.