On October 8, 2026, at its enterprise event "Gemini at Work 2026," Google Cloud announced "Gemini agent," an AI agent that can take on a wide range of business tasks. It goes beyond answering questions to creating documents and running code, and it switches between Google's Gemini and Anthropic's Claude depending on the job. Google also envisions team-based agents with their own email addresses and calendars, so that people can assign them work just as they would with human colleagues. Long-term memory and multi-day autonomous execution were already available on Google's enterprise AI platform. What stands out in this announcement is that these capabilities are being built into everyday work so that AI agents can serve as "colleagues" with ongoing roles.
Long-running autonomous execution already existed; the focus now is integration with daily work
At Cloud Next in April 2026, Google announced the "Gemini Enterprise Agent Platform," an evolution of Vertex AI.
It is a foundation for developers to build and run AI agents and to manage their access permissions and activity. The Gemini Enterprise app used by employees connects to internal data and external services through this platform.
An execution environment for long-running tasks, and a mechanism for remembering user preferences and past interactions across conversations, had also already been introduced at that point.
Looking back at Google's official announcements in chronological order: long-term memory and the execution platform came in April, continuous execution of up to seven days in July, spending caps in August, and operations spanning multiple Google Workspace apps in September.
The latest announcement sets out a plan to combine these features and develop them into agents that handle a person's varied work, as well as agents that take on ongoing roles within a team.
| Announcement date | Features and usage announced | Relation to this announcement |
|---|---|---|
| April 22 | Long-running task execution, Memory Bank, agent identity management and governance | Built the foundation for carrying out work continuously |
| July 29 | Up to seven days of continuous execution in Agent Runtime, expanded availability of memory and identity management | Multi-day autonomous execution is handled by the existing platform |
| August 26 | Monthly spending caps per project, pausing and resuming API calls | A mechanism for managing the costs of autonomous execution |
| September 9 | Creating documents and sheets for other apps from within each Workspace app | A way to assign work without switching apps |
| October 8 | Gemini agent using multiple models; colleague agents with dedicated Workspace accounts | A vision for delegating work continuously while preserving business context and roles |
Note: This is a chronological summary of Google's official announcements. Each feature differs in its stage of availability and target product, so the list does not show feature additions or general-availability transitions for a single product. Also, the "up to seven days" execution time announced in July will not necessarily apply as-is to the new Gemini agent.
The September Workspace announcements introduced features such as creating Google Slides presentations from Google Chat conversations, and summarizing long Gmail threads into Google Docs.
Google also showed a use case in which an email draft is created from Google Docs and the user reviews it before sending.
In other words, Google's AI agents had already reached the stage of creating deliverables across multiple apps.
The October announcement outlined a vision in which agents handling this work gain model selection, memory, and roles within a team, so they can be entrusted not just with one-off tasks but with continuing work.
Gemini agent also uses Anthropic's Claude
Despite its name, the newly announced Gemini agent does not rely solely on Google's Gemini models.
Google has designed the agent that carries out work and the AI model that handles reasoning inside it as separate components. It currently supports Gemini and Claude, and plans to support other companies' proprietary models and open models in the future.
The aim of this design is to spare companies from rebuilding the business knowledge and working environments they have accumulated every time an AI model is updated.
For example, even if Gemini is used for one job and Claude for another, the agent's connection settings to internal systems, its skills, and its business context are preserved.
As competition over AI model performance continues, this lets companies avoid making their entire working environment dependent on a particular model.
What supports this environment are "tools" and "skills."
Tools are the means by which an agent connects to business systems to retrieve information or carry out operations. Skills are reusable bundles of the instructions, knowledge, and work procedures needed for specific tasks.
Google says it also supports the Model Context Protocol (MCP) for connecting to external systems, and that companies can register tools and skills to share internally.
However capable an AI model is, it is hard for it to produce appropriate answers or deliverables if it cannot access the internal documents it needs.
Whether it understands internally used metric definitions and approval procedures also affects how practical the finished documents and analyses are.
As a result, the more flexibly AI models can be swapped, the more important it becomes to have a mechanism that maintains business knowledge and connection settings independently of the model.
That said, this announcement did not reveal details such as the criteria for choosing between Gemini and Claude, or how much switching models improves quality or cost.
Also, support for Claude does not mean the Gemini agent's working environment can be moved as-is to a platform other than Google Cloud.
Being able to change the AI model and being able to freely migrate the agent's execution platform itself are separate things that need to be considered distinctly.
Four types of memory to carry work across apps
The Gemini agent as Google describes it runs in the cloud and is designed to carry over the same memory and business context even when the device or app changes.
Google says it can continue work that takes hours or days even after the laptop is closed.
For this, there are four types of memory with different roles.
| Memory type | Information stored and referenced |
|---|---|
| Working memory | The content of the task in progress and the context gained along the way |
| Knowledge memory | Structured knowledge gained from documents and interactions with people |
| Procedural memory | How work is done, and skills the agent created itself |
| Execution history memory | Past tasks carried out and the experience gained from them |
What matters in this classification is that it does more than remember long conversations: it lets the agent apply knowledge and experience gained earlier to the next task.
For example, working memory helps carry over policies decided and revisions made in a task in progress.
On the other hand, finding the person you usually ask for help, or following an internally established procedure, also requires accumulated knowledge and procedures.
In other words, the role of memory is expanding from sustaining a conversation to sustaining the work itself.
In this announcement, Google presented an example in which a user asks, "Set up a meeting next week with the usual local events contact."
The agent identifies the contact from the members of a Google Chat space and from the conversation history about past events.
It then checks calendar availability and arranges the date by email, including with external participants.
Previously, users would have had to look up the contact's name and email address and tell the AI the necessary information each time. Using memory could reduce that effort.
However, remembering past information is a different matter from that information still being correct today.
If a contact changes roles or an internal procedure is revised, the earlier memory may not be usable as-is.
As for skills the agent creates itself, saving an incorrect procedure could cause it to repeat the same mistake.
This announcement gave no detailed explanation of how long memories are retained, how they are deleted, or how skills created by agents are verified.
To entrust work continuously, it is important not only to increase memory but also to update information appropriately and correct outdated knowledge or faulty procedures.
An AI "colleague" with its own account: whose permissions does it work under?
Another notable point in this announcement is the concept of a "colleague agent" that works as a member of the team.
This agent is given its own Google Workspace account and can use email, a calendar, and Google Drive.
Because it also appears in the company's user directory, employees can invite it to Google Chat spaces or assign it work by mentioning its name in document comments, just as they would with human colleagues.
When the agent proposes edits to a document, the changes are recorded under the agent's name.
This differs from a "sub-agent," which temporarily shares a specific task.
A sub-agent handles processing needed to carry out a job efficiently.
A colleague agent, by contrast, has an ongoing role and its own workspace. Its position is closer to that of an employee with a defined set of responsibilities, such as managing a project's progress or analyzing a department's data.
However, when AI agents are given dedicated accounts, managing access permissions becomes critical.
According to Google, a colleague agent operates under its own identity rather than the identity of the user who assigned the work.
It will also be able to access only information shared within the team.
Whereas a personal agent understands a user's broad range of work, a colleague agent is designed to limit access to the scope of information the team shares.
Having a dedicated identity makes it easier to set access permissions for each agent and to record who performed which operation.
Google had also explained, in connection with "Agent Identity," whose availability it expanded in July, mechanisms for granting minimum necessary permissions, access management that ties identities to execution environments, and auditing of activity history.
This announcement described a mechanism in which the agent's identity is carried over using OAuth and similar methods when connecting to external systems, and is also associated with the environment where code runs.
Communication is controlled through "Agent Gateway."
Google says a company's security policies can be applied not only between the sandbox and external environments but also to communication between agents.
For example, setting a rule that prohibits access to documents in a certain confidentiality class can reduce the burden of repeating the same configuration for each agent.
However, granting appropriate access permissions does not mean an agent will always make correct decisions.
Even if access to prohibited documents is prevented, the agent may still misunderstand the contents of documents it is allowed to read.
To entrust AI with work as a team member, it is necessary to decide not only access permissions but also which operations may run automatically and at which stages human confirmation is required.
The scheduling example presented cannot tell us whether the agent can always send emails to outside parties without user confirmation.
To have AI agents take part in work on an ongoing basis, dedicated accounts and access controls must be paired with mechanisms that let humans step in appropriately on important decisions.
The cost of autonomous execution can't be judged by model unit price alone
Managing costs is also a key issue when companies run AI agents continuously.
In August, Google announced a feature for managing agent usage charges that lets customers set monthly spending caps per project.
When the set cap is reached, API calls by the agent are paused and can be resumed from the management console.
This announcement also described a mechanism that monitors token usage and sandbox costs and stops processing when spending reaches the cap.
It helps to distinguish "Smart Routing," which optimizes AI model selection, from the feature that sets spending caps.
Smart Routing selects an appropriate model according to the content of the work.
Setting a spending cap, on the other hand, limits the budget available to the agent.
Even if a cheaper model is chosen, repeatedly redoing processing or calling tools more than necessary will raise the final cost.
Also, even if processing can be stopped when the budget cap is reached, the requested work is not necessarily complete.
What matters to companies is not only the unit price of a single AI model response but how much it costs to produce a deliverable that is actually usable.
For repeated tasks, avoiding redoing the same reasoning each time also helps cut costs.
Google presented a method that combines BigQuery and Knowledge Catalog to standardize the definitions of business terms used internally and to save and reuse generated queries.
Once a report has been created, it can be rerun using the saved query, eliminating the need to ask generative AI each time.
This reduces the token costs of generating the same query.
However, not needing generative AI tokens is not the same as the whole process being free. Separate costs for running queries in BigQuery and elsewhere may apply.
The approach is to create the processing for a task in natural language and leave the repeated execution to saved processing.
This division of roles is expected not only to curb the cost of having an AI model make the same judgment each time, but also to make it easier to review what is being executed.
However, saved queries are not always correct, and if the underlying data structure or business definitions change, the processing needs to be reviewed.
The availability of features also warrants attention.
According to Google Cloud's October 2 release notes, the ability to connect to Data Cloud services such as BigQuery and query data without moving it, as well as the integration with Knowledge Catalog, is in preview.
Not all of the features included in the announced vision are available under the same conditions.
Also, the October 8 keynote did not present a list of general-availability dates, supported regions, or compatible pricing plans for all features of the new Gemini agent.
Many of the corporate adoption results presented concerned Gemini Enterprise as a whole, so they need to be distinguished from results that independently measure the new Gemini agent's task completion rate or total cost.
To decide whether to adopt it, companies should test it on tasks they repeat daily, checking what share of work it completes end to end, how much rework occurs, and how much it costs to finish a deliverable.
They should also confirm that work history and access permissions can be managed properly even when the AI model changes, and that humans can step in to make decisions when needed.
What Gemini agent aims for is an evolution from AI that answers questions to AI that understands business context and takes on work continuously.
Being able to use multiple AI models and to give agents dedicated accounts are merely means to that end.
What will be tested from here is how reliably and efficiently combining these mechanisms lets the agent complete real work.