Lifting a local agent to the cloud
My local agent worked within a few days. The cloud version has been a few weeks in the making and still isn't fully operational. The gap isn't really technical — the code is similar. The difference is everything around the code.
I've been building an agent that analyses mobile app data and produces reports. The data lives in BigQuery; the context that makes it meaningful is spread across Confluence, Jira, and Figma, some of which sit behind my company's VPN. Locally, all of it just worked: my machine already had VPN access, tokens in the keychain, a Confluence MCP I could point at, and a folder of markdown files for context. Useful within days.
Code is the easy part
Three things get harder, and only one is what I expected.
Network. A cloud agent doesn't inherit your VPN access. The Confluence MCP that worked locally can't reach Confluence from the cloud. Restoring that access means site-to-site VPN, allow-listing, or a proxy — none of which you do alone.
Tooling. Locally, I added context by editing markdown. The cloud agent uses a schema-enforced vector store set up by IT, presumably for governance and cleaner retrieval. Probably the right long-term design, but the friction per update goes up by an order of magnitude.
Process. Permissions, tests, verifications, and multiple teams wanting to contribute requirements. None unreasonable individually — but cumulatively, the bottleneck shifts from writing code to coordinating people. The agent stops being software and starts being a small platform. A local agent serves one user. A deployed agent serves a constituency, and constituencies need governance.
Scope down, don't tool up
None of this is unique to agents. It is the same gap as deploying to AWS versus running locally, or writing an automation script versus spinning something up in n8n. The agent space just doesn't have its "Vercel" yet — at least not inside the kind of network I am working in.
What I keep coming back to is scoping down, not tooling up. Deploy early with deliberately small context. Keep v1 context in the simplest form possible, even if the long-term store is structured. Resist multi-team requirements until v1 is live.
The architectural bet I have not tried but suspect is the most interesting: deploy several small, focused agents — each specialised on a domain — with a router in front. Each agent has a tight context that one team owns. You trade one big coordination problem for several small ones, which is usually the better trade.
The real blocker isn't the agent
What's slowing me down is the overhead of standing up infrastructure and loading data into the structured context system. The tooling exists, but it is low-level enough that I am spending more time on plumbing than on the thing that is meant to be useful.
My working hypothesis is that the cloud agent will be worth the cost — for standardisation, shared improvements, scale — but only if I can resist letting it become everything to everyone before it is anything to anyone.
If you have taken an agent from local prototype to deployed, what slowed you down most? Did you go with one big agent or several small ones behind a router? How did you keep context focused as more teams asked to be involved? Reply or comment — I would like to learn from your patterns.
