Ask where your AI agents should run and you will get a hosting debate: cloud for convenience, local for control. The debate is real, but it bundles two questions that deserve to be pulled apart. Where does the agent execute? And where does the agent's work live? Teams that separate them stop arguing about infrastructure and start getting the benefits of both.
The execution question
Local execution means the agent runs on your machine: your files, your environment, your logins, your network. This is why the most capable agent workflows of the last two years have been terminal-bound. Close to the work, an agent can read the real repo, drive the real browser, and use the accounts you already trust. The costs are real too: the machine has to be on, and capability is tied to the box it sits on.
Cloud execution means the agent runs on someone's server: always on, nothing to install, but far from your files and your tools. Every capability has to be piped in through an integration, and your credentials have to travel to wherever the agent lives. For reading the web and drafting text that is fine. For doing your actual work, the distance shows.
There is no universal winner here, which is exactly why this is the less important question.
The state question
The question that decides how your team works is different: when the agent finishes, where does the work go?
If the answer is a session, you have the local-era problem no matter where the model ran. The output evaporates, a colleague cannot pick it up, two agents cannot see each other's progress, and every handoff is a human copying something between windows. A perfectly hosted, always-on agent whose work lives in a private transcript is still a closet server with a language model inside it.
If the answer is shared, persistent state, everything changes regardless of execution. Work lands in docs and tables the team can open. Attribution says who did what. A person starts something, an agent extends it overnight, another person reviews it in the morning. The state is the collaboration.
Execution is a deployment detail. State is the decision.
Why it is a per-agent choice, not a platform choice
Split the questions and the hosting debate dissolves: execution is something you should pick per agent, and the state layer is the thing that should never vary.
That is how Dock is built now. When you hire an agent, you choose where they run. A local agent runs on your own machine, in a real folder, with your own Claude account and the tools already connected to it, which is what lets them work your actual repo, your browser, your files. A cloud agent runs on their own machine instead, always on, and signs into a Claude login of their own: the machine opens an authorize URL, you approve it once in a browser you are already signed into, and nothing is typed or pasted. The credential is issued to you, not to Dock, and it lives on that agent's own disk.
Either way, the state layer is identical. Both kinds hold their own identity, write to the same shared docs and tables, and leave the same audit trail. Your researcher watching production issues overnight wants to be a cloud agent. The agent that drives your local repo and your logged-in browser wants to be local, and their work queues while your machine sleeps rather than being lost. The team reads both the same way, because the work lives in the same place regardless of where the run happened.
How to decide for your team
Ask the two questions in order, per agent. First: does this agent's work need your real environment, your repo, your accounts, your logged-in browser? If yes, run them locally. Does the work need to happen while every laptop is closed, a standing watch, an overnight sweep? Run them in the cloud. Second, and always: does the agent's output land somewhere your team can see, continue, and audit without you as the courier? If the answer is no, fix that before optimizing anything else. A team of brilliant agents writing into private sessions is still a team of one-person tools. The five shifts are the checklist for what the shared layer has to provide, and they are worth reading before any hosting decision at all.