Gemini Spark and the background-agent era: who is holding the spec?

By Nick Beaugeard · 6 minute read · ← All posts

Google used I/O 2026 to plant a flag in the agentic era. Gemini 3.5 landed as a frontier family aimed squarely at agents and coding, with a fast, cheap Flash variant shipping the same day. Alongside it came Gemini Spark: a personal agent that does not stop when you close the tab. Spark lives on dedicated Google Cloud VMs, runs tasks on a schedule or on a trigger, integrates natively with Gmail, Docs, Sheets and Slides, and ships with MCP connections to third-party services on day one. Each task runs in an isolated, ephemeral VM. Beta opened to AI Ultra subscribers in the US from 26 May, and Google cut the Ultra price from $250 to $100 a month to push it.

Set aside the consumer framing. The architecture is the story. We have crossed from "agent that responds when prompted" to "agent that acts while you sleep." That is a different risk model, and it changes what good engineering looks like.

The shift hiding in the demo

A chatbot is bounded by your attention. You ask, it answers, you read the answer, you catch the mistake. A background agent removes the human from the loop by design - that is the entire value proposition. "Works while you sleep" and "makes mistakes while you sleep" are the same capability. The convenience and the exposure arrive together.

So the question that decides whether a background agent is an asset or an incident is no longer "can it do the task?" The models can do an awful lot of the task. The question is: what does it work from, and what can you reconstruct afterwards?

Three things an always-on agent forces you to get right

Authored intent, not a remembered prompt

If a background agent is acting on your behalf for hours, the instruction it follows cannot be a sentence someone typed and forgot. It has to be an explicit, versioned specification - what the agent is for, what it may and may not do, what "done" means. The moment the only record of intent is a chat message, you have an autonomous actor and no source of truth. This is the reframe behind Symphony: the spec is the program, the run is a build artifact. Background autonomy makes that distinction load-bearing rather than philosophical.

Isolation as a first principle

Google running each Spark task in an ephemeral, isolated VM is not a detail - it is the right instinct. An agent that acts unsupervised needs a contained blast radius: its own workspace, its own scoped credentials, no persistence bleeding from one task into the next. Any orchestrator worth trusting with autonomous work treats per-task isolation as the default. Symphony has worked this way from the start, one contained workspace per issue, precisely because unattended work and shared state do not belong in the same sentence.

An audit trail you can actually read

When you wake up and the agent has done six things, you need to answer "why each one?" without spelunking through logs. The trail has to connect every action back to the clause of the spec that authorised it and the trigger that fired it. Without that, autonomy is unfalsifiable: you cannot tell a good run from a lucky one.

Why this matters beyond Google

Spark is not an outlier; it is the shape of the quarter. Every major lab is now shipping something built to run in the background, unsupervised, for hours or days. The differentiator across all of them is identical, and it is not the model. It is whether there is a governing layer holding the intent: a reviewed spec, isolation per unit of work, acceptance checks before anything irreversible settles, and an audit trail by default.

That layer is the orchestrator. The lab gives you a brilliant, tireless, slightly overconfident worker who will now keep working after you go home. Whether that is leverage or liability depends entirely on whether someone authored the spec it is working from - and whether you can read back what it did.

An always-on agent is only as trustworthy as the spec it runs while you are not there to correct it.

If you are looking at background agents for real work - reconciliations overnight, monitoring, recurring drafting - the engineering question is governance, not capability. That is the work we do inside Symphony. Come and talk it through.