Gemini Spark works while your laptop is closed. What an always-on agent changes for a business
Google's Gemini Spark, announced at I/O on 19 May, is a personal agent that lives in the cloud, runs on schedules and triggers, and checks with you before it does anything expensive. The consent model is the real product. Most enterprise agent pilots skip it, and that is why they stall.
Update, 30 July 2026: Google launched Gemini Spark in India on 29 July. Everything below still holds; the difference is that Indian businesses now have staff who can switch it on.
Google announced Gemini Spark at I/O on 19 May and described it as a 24/7 personal AI agent. The phrase that matters is in the small print: it works in the background on your phone or laptop even while they are turned off. Spark does not live on your device at all. It runs on Gemini 3.5 inside Google's cloud, on the Antigravity agent platform, and connects to Gmail, Calendar, Docs, Sheets and Drive through the same Connected Apps permissions the Gemini app already uses.
The examples Google published are ordinary. Scan my inbox every Monday at nine and give me a prioritised to-do list. When an enquiry email arrives, pull out the client's name and requested date, log the lead in my tracker sheet, and create a Drive folder named after them. Find and track internships in New Orleans for the summer. Nothing in that list is technically hard. What is new is that the task keeps running after you close the lid.
Trusted testers got it in the week of I/O, and the beta reached Google AI Ultra subscribers in the US the week after. Third-party tools arrive through MCP over the following weeks, Spark moves into Chrome as an agentic browser later in the summer, and the roadmap includes texting or emailing the agent directly, building custom sub-agents, and authorising payments with a spending limit and an approved list of merchants.
That last item is the one enterprise buyers should read twice.
The agent as a service, not a feature
Until now, most agents a normal person could use lived inside an app session. You opened the tab, asked for the thing, watched it work, closed the tab. If you wanted the same task done every Monday you did it every Monday.
Spark is a resident. It has schedules, it has triggers, it has memory across runs, and Google says you can teach it a new skill and it will keep it. In architectural terms it is a long-running service with an identity, a permission set and a job queue. Google has built the thing that every enterprise agent platform has been promising and wrapped it in a consumer product with 900 million monthly users behind it.
The consequence for a business is straightforward. Within a year, a meaningful share of your staff will have used an agent that runs unattended, on their personal accounts, and will expect the same at work. The question shifts from whether your company should have always-on agents to how you will govern the ones people bring in.
The consent model is the product
Google's launch copy repeats one line in several forms: Spark operates autonomously, but always under your direction, and it is designed to check with you before taking major actions. The payments roadmap goes further, with the Agent Payments Protocol letting a user set a budget and a list of merchants inside which the agent can transact without asking.
I would argue this is the most important design decision in the launch, more than the model or the cloud residency. It draws a boundary between what the agent may do on its own and what needs a person, and it expresses that boundary as rules the user sets rather than a blanket toggle.
Compare that with the enterprise agent pilots we get asked to review. They tend to sit at one of two extremes. Either the agent can only read, in which case it produces reports nobody acts on, or it has a service account with write access to everything, in which case the security team stops the pilot the first time it does something odd. Almost nobody builds the middle: a written policy of which actions are automatic, which need a click, and which are forbidden, enforced in code and logged.
Google shipped the middle to consumers. That is the bar now.
What an always-on agent needs from your business
Three things, and none of them are model choice.
An identity of its own. An agent that runs on a schedule while its owner is asleep cannot borrow that person's session. It needs credentials that belong to the agent, scoped to the systems it touches, and revocable on their own. If an agent's access is indistinguishable in your logs from its owner's, you cannot audit either.
Approval boundaries written as rules. Spark's model is a good template: automatic below a threshold, confirm above it, never for a defined set. For a finance agent that might be "post invoices under $2,000 from approved vendors, queue anything else, never change bank details". Write it down before the pilot, not after the incident.
A log a human can read. Every run, what it read, what it changed, what it asked permission for and who answered. Compliance is a side benefit. The real reason is that the first time the agent does something unexpected, the log is the only way to work out whether the task, the data or the agent was wrong.
Teams that have those three can let an agent run overnight. Teams that do not should keep a person in the loop for every action, whatever the vendor demo suggested.
Which tasks to hand over first
The tasks Google chose to demonstrate are the tasks that suit an always-on agent, and they map cleanly onto a business back office.
Recurring summaries on a schedule, such as the Monday inbox recap, translate to a weekly pipeline digest for a sales lead or a Friday status note for a delivery manager. Trigger-based logging, such as the enquiry email that becomes a row in a tracker sheet, is the same shape as a support ticket that becomes a CRM record or a supplier invoice that becomes a queue entry. Watch-and-notify tasks, such as tracking internship listings, become monitoring a regulator's site for a rule change or a competitor's pricing page for edits.
What these have in common is that they are frequent, low-stakes individually, boring, and easy to check. That is the profile to start with. Save the high-stakes, one-off decisions for a person and an agent that prepares the brief.
A pilot you can run in a fortnight
Pick one recurring task from the list above that someone on your team currently does by hand at least weekly. Give the agent its own credentials scoped to exactly the systems that task needs. Write the approval boundary in one paragraph. Run it for two weeks alongside the person who used to do it, and compare the outputs.
Measure three things: how often the agent's output needed correction, how much time the person got back, and how many times the agent asked for approval. If the third number is zero, the boundary is too loose. If it is every run, the task was not suitable.
That is the shape of every agent engagement we run, and Spark has just given a very large number of people a reference point for what the finished thing feels like.
Frequently asked
What is Gemini Spark? Gemini Spark is a personal AI agent Google announced at I/O on 19 May 2026. It runs in Google's cloud on Gemini 3.5, connects to Google apps such as Gmail, Calendar, Docs and Sheets, and carries out multi-step tasks on a schedule or in response to triggers, even when the user's phone and laptop are switched off. It rolled out to trusted testers first, then as a beta for Google AI Ultra subscribers in the US, and launched in India on 29 July 2026.
Does Gemini Spark act without permission? Google says Spark operates autonomously but under the user's direction, and is designed to check with the user before taking major actions. The planned payments feature lets users set a spending budget and approved merchants inside which the agent can transact without asking each time.
What does a business need before running an always-on AI agent? Three things: credentials that belong to the agent rather than a person, an approval boundary written as rules (automatic, confirm, never), and a per-run log of what the agent read, changed and asked. Model choice matters far less than those three.
Related reading
- AI agents vs automation: when to use which
- Governance is a feature, not an appendix
- Agent-driven onboarding use case
Google has put an unattended agent with a consent model in front of 900 million people. The teams that will do well with agents at work are the ones that copy the consent model. The demo is the easy part.