Across 15 projects between 15 April and 19 August 2026, my agents generated 3.70 billion tokens while my team typed 193,169. That is roughly one human token for every 19,000 the agents produced. If you are weighing ai agents for business and you want a single number that tells you where this is headed, that is the one. The work is no longer waiting on me.
For two years, my agents lived on my laptop. They only worked when I did. Lid down, nothing moved. On a flight, in a meeting, asleep, the whole operation was asleep too.
Then one morning I closed the lid on the way to the airport, and my newsletter still went out. Nobody touched it. The draft was written, formatted, and sent while I was somewhere over the Rockies with the wifi off.
That was the day my agents grew up.
The question nobody asks before they build
Most founders standing up an agent team ask the wrong first question. They ask what the agent should do. The better question is where it should run.
Where an agent runs is not a technical footnote. It decides what the agent can reach, how much damage it can do, and whether you can sleep while it works. I did not understand that until I had lived on both sides of it.
The scale is what forces the decision. Across those 15 projects, 1,768 hours of human oversight steered about 2.1 million agent tokens per human hour. On the Edge8 web platform, our own operating system, it was tighter: roughly 100 hours of human direction against 394 million agent tokens, about 3.95 million agent tokens per human hour. When one hour of your attention moves that much output, where each agent runs stops being a preference. It becomes the whole game.
Let me put those two numbers next to each other, because the gap matters. On client projects, one human hour moved 2.1 million agent tokens. On our own platform, where the direction was sharper and the guardrails were tighter, one human hour moved almost double that: 3.95 million. Same humans, same models. The difference was how deliberately we placed each agent. Tighter placement, more leverage per hour. That is not a coincidence. That is the return on getting this decision right.
What moved to the cloud
there's not that many skills that I really need on my laptop
The content agents went first: the writer, the designer, the email marketer. Their job is simple to describe. Take a brief, produce the work, hand it back.
They never needed to sit next to me. Nothing they touch is dangerous. The worst case is a bad draft, and a bad draft costs me five minutes of editing, not a production outage. So they moved.
Now they run in the cloud on a schedule. The drafts are waiting when I land. My presence is not the bottleneck anymore, and that is the entire point of the move. That newsletter that went out while I was over the Rockies? That is not magic. That is a produce-and-hand-back agent doing exactly the job I gave it, in the exact place that job belongs.
This is where most of the industry conversation sits right now. The big platforms are all pushing hosted, always-on agents. For produce-and-hand-back work, they are right. That work belongs in the cloud, and if it is still stuck on your laptop, you are paying for your own presence with your own time.
Where ai agents for business have to stay close
My developer and DevOps agents did not move, and they should not.
They touch my code. They run my builds. They can push to production. When an agent can change your systems, the blast radius is real. A hallucinated line of content is a typo. A hallucinated deploy is an incident. One costs you an edit. The other costs you a night and a customer's trust.
That work has to happen close to the environment it changes, and close to me. I want a human hand near the deploy button. Not because local is the training-wheels option, but because proximity is the safety mechanism. Distance is not maturity. Distance is just distance, and distance from a deploy is exactly what you do not want when something goes sideways.
Here is where I part ways with the loudest voices in the room. The pitch right now is autonomous coding agents running unattended in the cloud, opening pull requests and shipping while you sleep. Some of that is genuinely useful. But handing an unsupervised agent the keys to your infrastructure because a demo looked slick is how founders end up cleaning up messes they did not see coming. Consequence should set the rules, not the marketing.
If you are objecting right now, thinking the whole promise of agents is that they run without you, hear me out. The promise is leverage, not absence. Leverage means you spend your hour where it changes the most. On low-consequence work, that means stepping away entirely. On high-consequence work, it means staying close so one bad decision does not undo a hundred good ones.
The rule I landed on
Send an agent to the cloud when its job is to produce something and hand it back. Keep it local when its job is to change something that matters: your code, your infrastructure, your money.
Proximity should match consequence. That is the whole rule, and it holds up better than any diagram of where the nodes sit.
Most founders get this backwards. They move everything to the cloud because it feels modern, then wonder why the risky agents feel out of control. They optimized for looking current instead of matching each agent to the stakes of its job. The safe work stayed slow on their laptop, and the dangerous work ran unattended in someone else's data center. Exactly the wrong way around.
Here is the part that took me two years to understand. My agents did not all leave for the cloud. Each one finally landed where its work actually happens. The writer belongs in the cloud, on a schedule, out of my way. The DevOps agent belongs on my machine, within arm's reach, where I can watch it work. Both are the same decision made honestly: put the agent where its consequence lives. Growing up was not everything moving out. It was everything finding its right home.
How to sequence this without getting burned
If you are standing up your own agent team, do not start with the tooling. Start with consequence. List what each agent can touch, and let that decide where it runs.
Walk it in order. The produce-and-hand-back agents can go to the cloud today. Content, drafts, summaries, formatting. Anything where the worst case is a quick edit. Move those first and get your hours back.
The change-something agents earn their independence slowly, with you watching. Give them narrow permissions. Watch them work. Widen the leash only when the track record justifies it, not when the demo impresses you. That sequencing is the difference between an agent team you trust and one you are afraid of.
And be honest about who is watching. Those 1,768 hours of oversight were not idle babysitting. They were the reason the risky work never became an incident. If you do not have someone who can read a deploy and know when to stop it, you do not have an agent team yet. You have a liability with good marketing.
This is exactly the conversation we have with founders at Edge8: what to build, where to run it, and who you actually need to hire to run it well. Reply and tell me what you are building, or book an AI audit before you scale your agents. I would rather help you draw the line now than help you clean up after it.
More on how we run agents in the cloud is here.
FAQ## FAQ
What are AI agents for business, and where should each one run?
An AI agent for business is a model given a job, a set of tools and a place to run: a writer, a designer, an email marketer, a developer, a DevOps agent. Send an agent to the cloud when its job is to produce something and hand it back, and keep it local when it changes something that matters, like your code, your infrastructure or your money. Proximity should match consequence.
How much human time does it really take to build something with agents?
Less than you would guess. Edge8's own web platform was built with about 100 human hours and 394 million agent tokens. The point is not that humans disappear, it is that human hours shift from typing to judgment: briefing, reviewing, and deciding what ships.
Which agents should run in the cloud and which should stay local?
Send an agent to the cloud when its job is to produce something and hand it back, like a writer, designer, or email marketer. Keep it local when its job is to change something that matters: your code, your infrastructure, or your money. Proximity should match consequence, and that rule holds up better than any diagram of where the nodes sit.
Why not just run coding agents unattended in the cloud like everyone is pitching?
Because a hallucinated line of content is a typo, and a hallucinated deploy is an incident. Handing an unsupervised agent the keys to your infrastructure because a demo looked slick is how founders end up cleaning up messes they did not see coming. Consequence should set the rules, not the marketing.
Where should a founder start when building an agent team?
Start with consequence, not tooling. List what each agent can touch, and let that decide where it runs: produce-and-hand-back agents can go to the cloud today, while change-something agents earn independence slowly with you watching. That sequencing is the difference between an agent team you trust and one you are afraid of. Reply and tell us what you are building, or book an AI audit before you scale your agents.