The most important agent in your company next year is one you will never open a chat window with.

At I/O 2026, Google introduced Gemini Spark, a personal agent that runs continuously on dedicated virtual machines in Google Cloud, plugged directly into Gmail, Docs, Sheets, and Slides. It has its own email address. You can write to it the way you would write to a colleague. It does not need your laptop open to keep working.

"It's your personal AI agent that helps you navigate your digital life, taking action on your behalf and under your direction," Sundar Pichai told reporters during the pre-briefing.

The interesting word in that sentence is not agent. It is runs. Spark is not a smarter chatbot. It is a process. It sits inside the system where work originates, watches for triggers, holds context, takes action, and reports back. The interface is incidental. The operating surface is the inbox itself.

That is the shift worth naming. Agents are leaving the session and moving into the substrate. The advantage no longer comes from what a model can answer when you ask. It comes from what an execution loop can do, remember, and be accountable for when no one is watching.

From session to substrate

For two years, the dominant pattern was the open tab. You went to a model, gave it a prompt, watched the tokens, copied the output, and closed the window. Useful, but episodic. Every loop started cold.

Persistent execution inverts that. The agent does not wait for you to arrive; it arrives at the work. Spark monitors an inbox, drafts a status report by pulling from emails, docs, and sheets, and waits at a checkpoint for your assent. Google's I/O announcement extended the same pattern to Search itself: information agents "operating in the background, 24/7" that watch the web on your behalf and surface what changed.

What looked like a feature update is a category change. The unit of work shifts from prompt to loop.

Every durable loop has the same anatomy:

  • Trigger: a signal that says start. An incoming email, a calendar event, a price move, a failed deployment.
  • Permissions: a scoped right to read and act. Whose calendar, which repo, what budget.
  • Memory: the state the agent carries between runs. Prior decisions, prior corrections, prior outcomes.
  • Action: the move the agent makes in the real system. Draft, send, file, deploy, refund, escalate.
  • Audit: the trace left behind that lets a human reconstruct what happened and why.
  • Exception gates: the points where the loop pauses and asks for assent before crossing a threshold.

A system that has all six is a workflow. A system missing any of them is a demo.

What this makes possible

The reason this matters commercially is that real businesses are starting to publish numbers that only make sense if persistent loops are actually running.

McKinsey and AppliedAI reported a procurement case where vendor onboarding compressed from two weeks to under five minutes, with a roughly 99% reduction in manual effort. That is not a chatbot saving a few prompts. That is a regulated, evidence-heavy process being decomposed into triggers, permissions, memory, and audit, then handed to agents that run it end to end and pause only at the exception gates a human still owns.

Rakuten Advertising made the same move on the revenue side with its Mirai agent for affiliate marketing. The agent does not draft a creative and stop. It runs the loop: generate the offer, target the audience, deploy, measure, optimize, repeat. The marketer's job migrates from production to direction and exception handling.

In production operations, Resolve AI extended its always-on background agents into a multi-agent investigation architecture for live incidents. Instead of one model trying to diagnose a failure, a coordinated set of specialized agents tests hypotheses in parallel, verifies each other, and builds full causal chains from symptom to root cause. The company reports more than a twofold improvement in root-cause accuracy on its internal benchmarks. The interesting claim is not the accuracy number. It is that incident response now has a SWAT team that does not sleep.

Three very different functions. The same grammar. Trigger, permissions, memory, action, audit, exception gate.

The moat moves to context

Once you see persistent loops as the unit, the competitive geography changes.

A standalone agent with a brilliant model and no permissions inside your work systems is a tourist. Spark's quiet advantage is not the Gemini base model. It is that Google already holds the email, the docs, the calendar, the chat, and the browser. The permissions are pre-installed. The memory has nowhere else to live. The agent runtime ships with the substrate underneath it.

That is why the platform layer is suddenly contested. Kore.ai's Artemis is positioned as a neutral control plane, with a YAML-based Agent Blueprint Language and six built-in orchestration patterns, betting that enterprises will not let Microsoft, Salesforce, ServiceNow, or Google own every agent they run. Whether or not that bet wins, the framing is correct. The fight is not over who has the best model this quarter. It is over who owns the substrate where persistent loops execute, and who defines the standard for how those loops are described, governed, and observed.

For builders, the implication is direct. The defensible asset is not the prompt or even the agent. It is the cleanly defined loop: the trigger you can detect, the permission scope you can defend, the memory you can audit, the exception gate where your judgment shows up. That is the artifact worth investing in.

What persistent execution requires

This is where speed needs a partner. An always-on agent that acts without verification paths is not an asset; it is a liability with throughput.

The quiet discipline of persistent execution is the exception gate. Spark drafts the status report; you assent before it sends. The procurement agent compiles the vendor file; a human signs the threshold-crossing risk. The incident agent narrows root cause; an engineer commits the fix. The point of the gate is not to slow the loop. It is to keep human judgment present where it actually matters, and absent everywhere it does not.

This is the same operating shape we mapped in Verification Latency: the bottleneck in AI-native work is no longer producing the output, it is producing the evidence that the output is what it claims to be. Persistent execution makes that evidence requirement structural. Every loop needs an audit trail that an outsider could read, and an exception design that a regulator, a customer, or a CFO could trust.

It is also why agent identity is becoming infrastructure rather than admin. A loop that runs 24/7 against your systems must answer who it is, what it is allowed to do, and what it actually did, in a form that survives review. The agent control plane and the identity layer are converging because persistent execution forces them to.

None of this slows the buildout. It clarifies it. The teams that compound advantage will be the ones that treat the loop, not the prompt, as the deliverable, and that invest in the gate, not the demo, as the proof.

The measurement shift

One practical signal that a team has actually crossed into persistent execution: the metrics change.

Automation volume stops being interesting. The questions become sharper. How long is the loop? How many exceptions did it raise? How many did a human approve, override, or escalate? How quickly did memory improve next-run behavior? What is the cycle time from trigger to evidence?

If an organization cannot answer those, it does not have agents in production. It has assistants in a window. The vendor onboarding case is striking because the numbers exist. Two weeks to five minutes is a cycle-time claim, not a marketing claim. It implies the loop runs, the gates work, and the evidence holds.

The parallel for builders is the one we made in agent deployment: as the packaging gets easier, the scarce resource moves upward. With persistent execution, the scarce resource is loop design that survives contact with a real business.

Where to start

The useful first question is small. Inside your organization, what is the highest friction-to-value process that already has a clean trigger, a known set of permissions, a recoverable memory, and an obvious place where a human would still want to assent before money moves or a customer is touched?

That is your first loop. Vendor onboarding for some. Inbound lead qualification for others. Incident triage. Renewal risk review. Campaign reallocation. Procurement exceptions. Status reporting itself.

Codify the six primitives for that one loop. Run it. Watch the exception rate. Tighten the gates. Then take the next one.

The background agent is already running somewhere in your market. The only question is whether the first loop that runs continuously in your business was designed by you, with the gates where you wanted them, or inherited from whoever moved first.

Sources and further reading