Google Cloud says its new Gemini Agent can be hired like a person: it gets an email address, a calendar, Drive storage and a company directory listing. The interesting part for builders is not the inbox. It is the list of things Google had to bolt on so an agent can hold a job: its own identity, its own audit trail, a sandbox, a network gateway and a spend cap. That is the same checklist onchain agent builders have been writing for a year, and it is now showing up in enterprise software.
Everything below is what Google announced, as reported by Decrypt. The article shows no demos, benchmarks or independent tests, so treat the capabilities as claims.
What Google announced
Per Decrypt, Google Cloud unveiled the Gemini Agent at its "Gemini at Work" event. CEO Thomas Kurian said work "now starts in the prompt window." The pitch is that you hand the agent a goal instead of a question, and it returns finished work.
- ▸Reach: it works across Gmail, Docs, Sheets, Slides, Drive, Chat and Calendar, and also reaches Microsoft 365 and Slack.
- ▸Duration: Google says it keeps running in the cloud after you close the laptop, for hours or days.
- ▸Integrations: Salesforce, ServiceNow, Jira, Snowflake, BigQuery, and any server that speaks Model Context Protocol (MCP).
- ▸Model routing: Gemini orchestrates across Gemini and Anthropic's Claude models, sending each job to whichever Google judges best on quality and cost.
The coworker part
A manager describes a role, for example an events coordinator, and Gemini creates an agent for it. That agent gets a Workspace account with an email address, calendar, Drive storage and a directory listing. Its actions land in an audit trail kept separate from human users.
Decrypt notes that similar "agent as staffer" features exist elsewhere, naming Grok Bot, OpenAI's GPT dots and Hermes bots. The category is converging on one idea: an agent is a principal with its own identity, not a tab inside a human's session.
The guardrails, as claimed
Google's security story, in its own terms:
- ▸Each agent has a "cryptographically attested identity," and every action is attributed to the agent, not a person.
- ▸Agents run in an "Agent Sandbox," and their traffic passes through "Agent Gateway," which Google calls an "AI network firewall."
- ▸Real-time spend caps pause an agent when a project hits its limit, until someone clicks to resume.
Those are Google's descriptions. Decrypt does not show them being tested, and it cites a July report from Accomplish AI researchers that the local mode of Claude Cowork could escape its Linux virtual machine on Macs and reach host files. That is a different product from Google's, and it is a reminder that "runs in a sandbox" is a claim until someone tries to leave it.
No pricing or general availability date was published. Financial services and legal versions are in preview, with government, healthcare and retail listed as coming soon.
Why onchain builders should care
Strip the Workspace branding and look at the shape. An identity that is not a human's. A per-agent log. A hard spend limit. Tool access over MCP. Those are the four things an onchain agent needs before it touches funds: a wallet of its own, an attributable history, limits it cannot talk its way past, and tools it can call.
The difference is where the rules live. Google's identity and spend cap sit inside Google's platform, and you trust the operator to enforce them. In an onchain stack, the wallet, the allowance and the payment rail can be checked by anyone with a block explorer. Neither model is automatically better. They answer different questions: who do I have to trust, and what can I verify myself?
Also worth noting: MCP is on Google's integration list as a first-class path. The protocol that connects agents to tools is now table stakes for the biggest vendors, which makes the quality of the MCP servers you pick a real part of your agent's risk surface.
The prompt is the cute part. The stack under it is where the work lives. A coworker agent with a calendar and a company directory entry still needs the unglamorous pieces: limits, logs, scoped tool access.
What to watch
- ▸Pricing and availability. Agents bill by tokens, and Google offers no price or date yet. A spend cap is only as useful as the bill it protects.
- ▸Independent testing of the attested identity, sandbox and gateway claims. Until then, they are vendor statements.
- ▸Whether agent identities travel. An email address works inside one company. An agent that pays, hires or gets hired across organisations needs identity that other parties can check.
- ▸Spend caps that stop and wait. Google's pause-until-someone-clicks design is a useful pattern for any agent with a budget, onchain or not.
If you are building an agent that handles money, start from the stack, not the prompt. Describe the agent and Sato maps the wallets, MCPs, payment rails and skills it needs, with the evidence we have on each: satohub.ai/build. The Sato Score tells you how open and active a listing is. It is a transparency signal, not a safety grade.