Google Shipped a Cheap Agent Model and an API That Spins Up an Agent in One Call. Before You Hand Google the Orchestration, Run the Lock-In Math.
Google used I/O to make a direct play for the part of your stack you've been building yourself. The headline was Gemini 3.5 Flash, a cheaper agent-tuned model. The more consequential announcement was the Managed Agents API: one API call provisions a working agent that reasons, picks tools, and executes code inside a secure Google-hosted Linux environment, with governance and data-handling controls inherited automatically.
Strip the keynote language and here's what's on offer. You stop running the agent loop. No more standing up a sandbox to execute tool calls, no more wiring the retry logic, no more babysitting the execution environment. Google runs all of it and hands you a result. For a solo builder who just wants an agent in production by Friday, that's a real temptation, and it's exactly the kind of temptation worth being suspicious of before you build on it.
What Google actually launched
Gemini 3.5 Flash is the model layer: agent-tuned, priced to undercut the bigger Gemini Pro tier, and pitched at builders who got a nasty surprise from their first AI infrastructure bill. The pricing being quoted puts it well below the flagship, which is the whole point of a Flash-class release.
The Managed Agents API is the platform layer, and it's the more important one. A single call gives you an agent that runs its full reason-act loop server-side: it reasons about the task, calls tools, executes code in Google's sandbox, and comes back with output. The execution environment is Google's, the orchestration is Google's, and the privacy and governance posture comes from Google's platform rather than something you assembled. Google also signaled an Omni Flash variant rolling out to developers in the following weeks.
What the convenience is actually worth
I don't want to be reflexively cynical here, because the convenience is real and for some builders it's the right trade.
Running your own agent loop is genuinely annoying work. You need a sandbox to execute tool calls safely, error handling for when a tool times out or returns garbage, retry and backoff logic, and a way to keep the whole thing from running up a bill or running off a cliff. Managed Agents deletes that entire category of plumbing. If you're early, low-volume, and trying to find out whether an agent-shaped product even works, paying Google to run the loop so you can ship this week is a defensible call. Speed to a real user beats architectural purity when you have no users.
What the convenience costs
Here's the part the launch coverage skips, and it's the part that matters for anyone past the prototype stage. When Google runs the loop, your orchestration logic, your tool wiring, and your execution environment all live inside one vendor's managed product. The thing you'd most want to be portable (how your agent actually works) becomes the thing most tightly coupled to a single API.
Models are commodities you can swap. The orchestration around them is not, once it's expressed as calls into a proprietary managed runtime instead of code you control. The day a competitor ships a better or cheaper model, swapping it is easy if you own your loop and painful if Google owns it. You didn't just rent a model. You rented the architecture, and the exit cost is the architecture too.
This is the same move every major vendor is making right now: Google, Anthropic with its hosted Managed Agents, OpenAI with its agent tooling. They are all racing to host your agent, because the model is a commodity and the orchestration layer is where the lock-in lives. That's not a conspiracy; it's just where the margin is. Knowing that should change how you read every "spin up an agent in one call" pitch.
What I'd actually do
Decide which kind of builder you are before you touch the API, because the right answer flips depending on where you are.
If the agent is a feature inside a product that does other things, and you're still proving it's worth having at all, use the managed API. Ship it, learn from real usage, and don't romanticize owning a loop that might not survive contact with users. The portability you'd be protecting is portability of something that may not exist in three months.
If the agent is the product (your differentiation is how it orchestrates, what tools it chains, how it recovers from failure), keep the loop yourself. That logic is your moat, and you do not hand your moat to the company that also sells the model it runs on. Use Gemini 3.5 Flash as a model behind your own orchestration if the price is right, but own the part that makes you you.
The honest counter-take: managed runtimes have historically gotten stickier and better, and it's possible the portability worry is a purist's concern that costs real builders real months. Plenty of successful products run happily on infrastructure they could never extract themselves from, and "I own my agent loop" has never once shown up on a customer's reason for buying. If your loop is generic (the same reason-act pattern everyone ships), then the lock-in you're protecting against is lock-in to something that wasn't a moat anyway, and you should just take the convenience. The math only favors owning the loop when the loop is genuinely yours. Most aren't. Be honest about which one you're holding before you decide.
Author
Lukas
@lukcombinator