At Google I/O 2026, Google announced Gemini Spark: a persistent AI agent that runs 24/7 in the cloud, managing your Gmail, Docs, Calendar, and Sheets even when every device you own is off and sitting on a shelf. No prompt required. You give it a task, it runs until the task is done. That's the pitch.

My first reaction was skepticism. Not because I don't believe in agentic AI — I do. But because these personal AI agents tend to work well for limited use cases in controlled environments. I've been building my own system using these tools for more of my nuanced use cases and needs, and I think that's how these agents will eventually pan out. People will need a lot of flexibility for tools to work how they do, at least initially.

But the more I sat with the details, the more I found myself making a list of questions I'd want answered before I handed that much access to anything.

What "always-on" actually means

Most AI tools we use today are reactive. You open the app, type something, get something back. Gemini Spark is designed to work the other way around. It's connected to your Google Workspace through structured APIs — not screen-reading or simulating clicks, but calling defined methods with known inputs and outputs — and it runs continuously on Google's cloud infrastructure.

The practical implication: Spark could be monitoring your inbox right now, drafting a reply to a client email, and scheduling a follow-up meeting, all while you're asleep. The "always-on" part is what separates this from a chatbot — it's the always-on agent architecture that doesn't wait for you to open a tab.

Google's underlying platform here is Antigravity 2.0, which is also worth understanding on its own terms. It's an orchestration layer that lets multiple AI sub-agents run in parallel, each handling a different piece of a complex workflow. Google cited a case study of 93 parallel sub-agents building a working operating system in 12 hours. That number is wild enough that I'd want to see independent verification, but it gives you a sense of the scale they're designing for.

The security model Google is betting on

Google's stated approach to security is ephemeral VM isolation. Every task Spark runs executes in a fresh, isolated virtual machine that gets destroyed when the task completes. The idea is that each session is sandboxed — nothing from one task bleeds into another.

But prompt injection attacks have proven stubborn in other agentic contexts, and the attack surface here is substantial. Spark has standing access to your email, your calendar, your documents. A malicious email crafted to manipulate Spark's behavior — telling it to forward messages, schedule meetings with external parties, or modify documents — is a real category of risk. The ephemeral VM prevents data leakage between sessions, but it doesn't necessarily stop a bad actor from using the current session's access against you.

Simon Willison, who writes some of the most technically grounded AI criticism I've read, has a policy of not writing about things he can't actually test. Most of what Google announced at I/O is "coming soon" — not yet available for independent testing. That's relevant here because we're evaluating Google's security claims without being able to probe them. The architecture sounds reasonable. Whether it holds up under real-world adversarial conditions is a different question.

The part that gave me the most pause

Buried in the coverage is something that came from code analysis, not from Google's official announcements. The code within the Google app suggests Gemini Spark may be able to make purchases without explicit per-transaction user approval.

That's unconfirmed. Google hasn't announced it as a feature. But it's worth naming because if it's accurate, the failure mode changes category.

A bad email draft is embarrassing and fixable. A misconfigured agent that makes unauthorized purchases — or that gets manipulated into doing so through a prompt injection attack — is a different problem. For freelancers and small operators who might use Spark to manage client communications and invoicing, the gap between "draft an invoice" and "send payment" is one the agent probably shouldn't be crossing without a confirmation step.

The Forbes coverage flagged this as "an uncomfortable warning" that Google left out of its I/O presentation. I think that's fair. The autonomous purchasing question deserves a direct answer from Google before this goes into wide release.

The "coming soon" problem

Google AI Ultra — the subscription tier that will get beta access to Spark — costs $100/month for developers or $200/month for the full tier. That's real money. And right now, what you're paying for is mostly access to a roadmap.

This isn't unique to Google. OpenAI and Anthropic have both announced capabilities before they shipped them. But there's something worth noticing about how the discourse around AI capability has shifted: we're increasingly evaluating claims instead of testing tools. The press cycle runs on announcements, not on months of independent use.

I'm not saying Google is being dishonest. I'm saying that "trusted testers first, then U.S. beta subscribers" is a significant gap between what was announced and what's available. And for a product whose value proposition is "trust me to run in the background of your business while you're not watching," the absence of independent testing reports is a real gap in what we know.

There's also the question of usage caps. Code analysis suggests even AI Ultra subscribers may face caps with no way to purchase additional capacity. That's also unconfirmed. But if you're building workflows that depend on Spark running continuously, discovering a cap mid-workflow is the kind of thing you'd want to know about before you build the dependency.

What this actually changes for creators and small operators

The architecture Google is building is genuinely interesting. Antigravity 2.0 as an orchestration layer for multi-agent workflows — the parallel sub-agents, the persistent execution, the API-level integration with Workspace — that's a real platform bet. If it works the way Google describes, it shifts the question from "how do I prompt this well" to "how do I design a system of agents with defined roles and handoffs."

But here's what I think will actually happen: most people will need to build their own systems anyway. The general-purpose agent that handles everyone's email the same way is useful for simple tasks. But once you get into the specifics of how your business works — the particular clients who need different communication styles, the specific documents that follow your format, the nuanced decisions that reflect your judgment — you need something more flexible than what Google's shipping.

I've been building exactly that kind of system using the tools available now. Custom agents for different parts of my workflow, designed around how I actually work, not how an average user works. And honestly, that's been more useful than any all-in-one agent I've tried.

For most of us, the honest answer is: wait and see. Not because the technology isn't interesting, but because the things that would actually determine whether Spark is safe to use in your business — the real-world security behavior, the actual usage caps, the autonomous purchasing question — aren't answerable yet. The product isn't available for independent testing, and the unconfirmed features are exactly the ones with the highest stakes.

I'd also pay attention to the Antigravity CLI transition. Google is sunsetting its open-source Gemini CLI and replacing it with a closed-source Antigravity CLI, with a migration deadline of June 18, 2026. If you've built anything on the open-source CLI, that clock is running. And for developers who care about auditability, the move to closed-source signals that Antigravity is a commercial platform play, not an open ecosystem.

None of this means Gemini Spark won't be useful. It might be genuinely useful. But "24/7 access to your Gmail, Calendar, and Documents, running autonomously in the background" is a significant thing to hand over, and the questions I'd want answered before doing that haven't been answered yet. When the beta opens up and people start publishing real-world reports — not Google's case studies, but independent accounts of what it actually does under production conditions — that's when I'll have a better sense of whether this works the way they're promising.

Until then, I'm watching the trusted testers carefully.