Google Cloud's Gemini Agent Wants to Be Every Employee's Persistent Coworker

On October 8, 2026 Google Cloud used its Gemini at Work 2026 event to announce the Gemini agent, which it calls a single universal agent for work. Per Google's own blog, work now starts in the prompt window: the agent holds an organisation's business context and covers everything from knowledge work and answering questions to content creation and coding; it plans the work, uses skills and tools, connects to a customer's business systems, and brings back something finished inside the documents, inbox and developer environments people already use; it picks the best model for the job, ships with cost controls, and carries the security, administration and governance enterprise customers ask for.

The Gemini agent is built to be handed a whole assignment, not one prompt at a time

From a collection of assistants to one agent

For the past few years Google sold a set of assistants: one for email, one for spreadsheets, one for code. This bet is different. Instead of asking employees to manage separate agents, Google wants them to delegate an objective: you say what finished work should look like, the agent works out how, reaches the right systems, and returns the artifact. That sounds like an interface change. It is actually an architecture change. The moment an agent is accountable for an outcome, it needs its own identity, memory and permission boundary rather than living inside somebody's chat session.

# A coworker agent is not a chatbot session. It is an identity that
# gets provisioned like a new hire: account, mailbox, calendar, storage.
agent_spec:
  name: event-planner-agent
  mode: coworker            # vs. "personal assistant"
  identity:
    workspace_account: [email protected]
    mailbox: [email protected]
    calendar: shared            # bookable by humans
    drive: /Shared/Events
    directory_listing: true
  attestation: cryptographic   # every action is attributable
  surfaces: [web, ios, android, windows, mac, cli, chat, m365, slack]
  approvals:
    - create_calendar_event     # auto
    - spend_money: human_approve
    - contact_external: human_approve

Four memories, not one 'context'

The genuinely interesting engineering is the memory architecture. Google splits it four ways: session memory for the task in flight, semantic memory for accumulated knowledge, procedural memory for learned workflows, and episodic memory for what happened last time and what came of it. Splitting them matters because 'remember everything' is not a design. A context dictionary that only grows is a junk drawer that slows inference and dilutes the information that actually helps.

# You hand over an objective, not a sequence of steps. The agent
# keeps working across days; execution lives in the cloud, so you
# can start on a laptop and pick it up from a phone.
from time import sleep

def delegate(agent, objective, deadline_hint=None):
    run = agent.start(
        objective=objective,
        # agents can only read what a team explicitly shares with them
        data_scope="team_shared_only",
        spend_cap_usd=250,
        notify=["slack://#events", "mailto:[email protected]"],
    )
    while not run.done:
        # long-running work: poll, do not block a request thread
        print(run.status, run.current_step)
        sleep(60)
    return run.artifacts      # docs, slides, PRs, tickets

Four memory stores: session, semantic, procedural and episodic

Where a coworker agent's identity comes from

VentureBeat flags the detail that matters: these agents get their own identity inside existing productivity infrastructure - a dedicated mailbox, calendar, Drive storage and directory presence, mentionable in Google Chat and assignable document edits. More important is the boundary: coworker agents can access only information team members explicitly share with them, rather than inheriting a human employee's entire permission set. For organisations that want agents near financial records, customer databases or legal documents, that boundary is what decides whether a project clears security review. That distinction has practical consequences. A personal assistant acting for one employee inherits an accountability chain that already exists: a manager, a review cycle, an offboarding process. A department-wide coworker agent has none of that by default, which is why provisioning and licensing matter more than they first appear to. If you cannot say who owns the agent, who reviews its work, and what happens to its mailbox when the project ends, you have not deployed a colleague - you have deployed an unowned service account with write access.

# The memory architecture is the interesting engineering choice.
# Four stores, because 'remember everything' is not a design.
MEMORY = {
    "session":    "state for the task in flight; discard on completion",
    "semantic":   "accumulated facts about the company and domain",
    "procedural": "learned workflows the agent can replay",
    "episodic":   "what happened last time, and what came of it",
}

def recall(agent, task):
    ctx = agent.memory.semantic.search(task.topic)
    ctx += agent.memory.procedural.match(task.intent)   # repeatable recipes
    ctx += agent.memory.episodic.recent(task.domain)     # prior attempts
    return ctx

# Splitting these is what stops 'context' from becoming a junk drawer
# that grows forever and helps nobody.

Policy belongs in the gateway, not scattered everywhere

Google's governance has three layers. Each agent gets a cryptographically attested identity. Actions land in audit logs, including the moments it creates isolated environments to execute code. An Agent Gateway enforces organisation-wide policy on communications between agents and external systems, with sandboxing around code execution. The shape is the same one Uber described for its MCP gateway: centralise governance so 'who may call what' has one answer instead of fifty teams improvising their own.

# An Agent Gateway enforces organisation-wide policy on every
# outbound call. Sandboxing bounds what generated code can touch.
agent_gateway:
  default: deny
  rules:
    - { from: "*",            to: "internal.registry",   allow: true }
    - { from: "coworker-*",   to: "salesforce",          allow: true, scope: "read" }
    - { from: "coworker-*",   to: "github",              allow: true, scope: "pull_request" }
    - { from: "coworker-*",   to: "public_internet",     allow: human_approve }
  budgets:
    project_spend_cap: true          # pause the agent when exhausted
    attribute_costs_to: department
  code_execution:
    sandbox: true
    record_isolated_envs_in_audit_log: true

Code execution is sandboxed and every action lands in an audit log

Swappable models and controllable cost are the real gates

Two more design details decide whether this lands. First, models are swappable: Google supplies Gemini, VentureBeat reports the agent can already use Anthropic's Claude, and more proprietary and open-weight models are planned. Second, a Smart Routing capability picks models per workload by performance and cost, alongside project-level spending limits that can pause an agent when budgets run out and the ability to attribute costs to individual departments. Enterprise buyers weigh those two things more heavily than any leaderboard. The competitive backdrop makes the timing easier to read. Microsoft introduced an updated Copilot on September 25, combining productivity work, software development and persistent automation. OpenAI introduced always-on dots agents at DevDay on September 29, and Anthropic announced native Claude integration with Google Docs, Sheets and Slides on October 6. SpaceXAI's Grok Bot, launched August 11 with its own cloud computers, is the closest structural analogue. Every one of these bets the same way: the assistant stops being a chatbot and becomes a long-running digital worker. What differs is where the identity lives, and who governs it.

# Smart routing picks the model per workload instead of pinning one
# model for the whole platform - cheaper models for cheap steps.
ROUTING = {
    "summarise_email":  {"model": "small", "why": "high volume, low stakes"},
    "write_pr":         {"model": "frontier", "why": "needs real reasoning"},
    "draft_contract":   {"model": "frontier", "why": "consequential output"},
    "extract_fields":   {"model": "cheap", "why": "verifiable output"},
}

def plan(agent, objective):
    steps = agent.decompose(objective)
    # complex work can fan out to temporary, specialised sub-agents
    if len(steps) > 5:
        return agent.spawn_subagents(steps, ttl="run")
    return steps

# The open question Google did not answer: pricing, GA date, and
# whether every capability lands in existing Gemini Enterprise plans.

What is still unanswered

The adoption numbers Google cites are strong: nearly 90% of Fortune 100 companies use Gemini Enterprise, BNP Paribas is deploying it to more than 65,000 employees, and Japanese insurer SOMPO has built over 10,000 custom agents. None of that is adoption of the new universal agent. The open questions are equally clear: no separate price, no word on whether every capability is included in existing subscriptions, no general-availability date, and no confirmation of whether administrators can selectively enable or disable pieces of an agent's Workspace presence. If you are evaluating it, put those four on your procurement list first.