AI agents need to survive interruptions

The useful signal this morning is not that an AI agent can do one more impressive task. It is that Google is adding the boring machinery an agent needs when work takes longer than a chat turn.

Google announced new Managed Agents capabilities for the Gemini API on July 7: background execution, direct connection to remote MCP servers, custom function calling, and credential refresh across interactions. In plainer terms, Google is trying to make managed agents survive the ordinary failures of real software work: the connection drops, the task takes minutes, the tool lives behind a private API, the access token expires, and the agent still needs its files when it resumes.

The key change is background work. Google’s docs say standard HTTP requests often close after about 60 seconds, while long agent tasks can take much longer. The new background execution path lets a client start an interaction with background: true, get back an interaction ID, then poll, stream progress, reconnect, cancel, or delete the run later. That sounds small. It is not. If an agent cannot keep working after the tab closes or the stream disconnects, it is a demo, not a dependable worker.

The second change is where tools live. Google says Managed Agents can now connect directly to remote Model Context Protocol servers, while also using sandbox tools such as code execution, Search, and URL context. The point is not “MCP is trendy.” The point is that useful agents need to reach private databases, internal services, observability systems, and business APIs without every developer writing a custom proxy for each connection.

That creates a sharper security question. A remote tool is not just a convenience. It is a new place where authority enters the agent’s work. Tool schemas, descriptions, parameters, credentials, and network rules become part of the trusted system around the model.

Credential refresh is the tell. Google’s environment docs describe managed Linux sandboxes whose files and installed packages can persist across interactions. They also describe network allowlists and credential injection through an egress proxy, rather than placing secrets directly in the sandbox as files or environment variables. If a token expires, the developer can pass the same environment ID with a new network configuration, replacing the old rules while keeping the sandbox state.

That is the actual product line: keep the working directory, rotate the authority.

This fits the broader enterprise-agent pattern. Google Cloud’s Agent Platform release notes now include agent registry, observability, gateway controls, memory, and semantic governance policies. Different pieces, same direction: agents are becoming long-running software processes with state, tools, credentials, logs, and cancellation paths.

The caveat is important. These are Google’s claims and docs, and much of this managed-agent stack is still in preview. A hosted sandbox with background execution does not prove the agent is reliable, safe, or easy to debug. It does show where the fight is moving. The model still matters, but production agents are increasingly judged by whether they can finish work without losing state, leaking authority, or asking users to babysit every network hiccup.

What to watch next: whether teams treat these agent manifests, tools, and network rules like deployable software artifacts. If they do, the real competition is not only who has the smartest model. It is who gives the model a place to work that can be inspected, paused, resumed, governed, and cleaned up.

Source graph: Semble source collection