Ask a room of engineering leaders whether their teams use AI agents, and every hand goes up. Ask who can list the agents that ran last night, what they did, and what they cost, and the room goes quiet. The distance between those two answers is what this note is about.
The usage is real. The place for it is missing. In most organizations, agents run under individual user accounts, on individual machines, wired up by the people who needed them. The company has automation now, and no way to see it.
01 · How it happensNobody designed this.
Agent adoption went bottom-up because that’s how the tools ship: a seat on a team plan, a personal API key, a laptop, and an afternoon. A staff engineer wires an agent to triage the bug queue before standup. An analyst schedules one to pull numbers and draft the Monday report. An ops lead builds one that watches a vendor feed and files the exceptions. Each of these is a good idea, built by the right person, and each one runs in the only place that person could put it: their own account, their own machine, their own cron.
Multiply that by every capable person in the company and the dashboard view looks like success. Seats active, tokens flowing, adoption up and to the right. What exists underneath is a layer of business process keyed to personal credentials and scheduled by whichever laptops are open. We wrote about the tool-first version of this in Why tool-first AI rollouts stall; the agent version is the same story with higher stakes, because now the tools act.
02 · The billThe costs arrive quietly, and they compound.
Start with visibility. A company in this state can no longer inventory its own processes. “What’s automated here?” has become unanswerable, because the answer lives in a hundred personal setups nobody registered anywhere. Then monitoring: when a personal agent fails at 2 a.m., the process it ran fails with it, silently, and the first sign is usually a downstream complaint days later. Then measurement: the board is asking why the AI investment isn’t showing up in delivery, and part of the honest answer is that some of it is showing up, in work the organization pays for but cannot see. You cannot make an ROI case from a spend line and a stack of anecdotes.
The sharpest cost is continuity. The person leaves, IT wipes the laptop on schedule, and the automation dies. Often nobody knew the process existed until the work stopped. That’s a bus factor of one on work the business came to depend on. And underneath all of it sits governance: agents acting on company systems with personal credentials leave no audit trail the company owns. That should worry whoever signs the SOC 2 letter.
03 · The planeAgents doing business work are business infrastructure.
The fix is structural, and it’s the same move companies eventually made for code, for deploys, and for data pipelines: the work moves from personal machines into a shared, governed place to run. For agents, that means a central orchestration and execution plane. A harness wraps one agent. The plane runs all of them.
The properties matter more than any product name. Agents run under identities the organization owns, on infrastructure that doesn’t close its lid at 6 p.m. Their activity and their spend are visible while they run. Anyone with the standing to ask can see what’s automated, pause it, or audit what it did last Tuesday. And when the person who built an agent moves on, the agent stays, along with the context it works from, because both belong to the company rather than to a login.
The obvious objection is that this is a solved problem: put the cron jobs on a server, run them under a service account, and most of the bill above goes away. True, and worth doing this sprint. If your agents are scheduled scripts, a shared server is the plane at its simplest, intelligence zero. What it can’t do is supervise judgment. A cron job runs the plan someone wrote; an agent writes part of the plan every time it runs. It can retry, escalate, spawn a checker, or hand the work to a person, and it can be wrong with confidence. Supervising that takes more than an exit code: budgets, boundaries, a record of the decisions and not just the outcomes, and orchestration that adapts to what the work turns up. That is the part the server doesn’t give you, and the part we mean by a plane.
This is what Olympus, the agent plane in our platform, is for: teams of agents doing real work under governance, in full view, reading shared context instead of private memory. The argument stands without our software, though. Decide that agents doing business work are business infrastructure, then host them accordingly.
Experiments still belong on laptops, close to the person having the idea. The failure mode is the prototype that quietly became the process and never moved.
04 · Our own moveWe’re mid-migration ourselves.
Which is why this is a field note.
The always-on orchestrator agents we described in Working with Fable run in our own plane, and the numbers we published there, session counts, event volumes, dollars per week, came off its meters. The laptop agents are metered too; usage data is easy to collect, and we collect it. What usage data can’t tell us is what the work was. In the plane we can see each run: what the agent did, what it produced, where the output went. On the laptops we can see what the work cost, and little else. The gap matters most when you go looking for waste. A spend line can’t tell an agent doing real work from one that’s spinning, burning tokens without producing anything anyone uses. We found ours by watching the work. We can tell you precisely what our governed agents did last week, and only approximately what the ungoverned ones did.
Moving agents into Olympus has been slower than wiring them up locally, and the friction is informative. Migrating an agent forces you to write down what it actually does, what it touches, and what “working” means. That’s a spec, and most personal automations never had one. Some agents resisted moving because they were tangled with one person’s credentials in ways nobody had noticed. Every one of those snags previewed a failure we would otherwise have discovered the hard way.
05 · The ruleRead the list.
Here’s the Monday-morning version. Ask your team to list every process that stops if one person’s laptop stays shut for two weeks. Don’t fix anything yet. Read the list.
Whatever is on it already matters enough to move. If an agent does work the business depends on, it should run where the business can see it, meter it, and keep it alive. The laptop is where automation is born. It shouldn’t be where it lives.
Founder of r90
Writes about the method underneath modern software companies and engineering organizations. Read more →