Google Turns Gemini Into an Agent With Its Own Email Address and Subagents

Google is turning Gemini into an agent for business. It plans tasks, executes them in corporate applications and systems, hands pieces of work to subagents and picks different AI models for different steps. The agent also gets its own work identity, including an email address. The announcement covers three key mechanics, and companies get them first, not ordinary users.

What exactly was announced

According to TechCrunch's description, Gemini now works as an executor, not just a conversation partner. It receives a goal, builds a plan, works through the steps and calls into business applications. If the task is large, it delegates it to subordinate agents. For different parts of the work, it can use different models.

The article contains no numbers: no prices, no limits, no list of supported systems, no regional availability dates. Keep that in mind during the first wave of enthusiasm. For now the architecture is clear, but the economics are not.

• Planning: the agent breaks a goal down into steps on its own
• Execution: work inside business applications and systems
• Delegation: subagents handle separate subtasks
• Multi-model: several AI models in a single process
• Identity: a work account with its own email
• First segment: enterprise customers

Why an agent needs an email address

The email detail looks minor, but it solves a very down-to-earth problem. While an agent works under a live employee's account, the logs cannot distinguish an action by a human from an action by a machine. Permissions have to be delegated wholesale, and auditing turns into guesswork.

A separate identity changes the picture. The agent can be added to the user directory, given a minimal set of permissions, included in work email threads and switched off with one button. You can assign it a task with an ordinary message, as you would a colleague.

The flip side is obvious. The mailbox becomes a front door for attacks. An email with a hidden instruction can try to pull the agent off course, and the broader its permissions, the costlier the mistake. The announcement does not say how Google closes off this class of threats.

Subagents and multiple models

The setup with an orchestrator and narrow executors has become standard for agentic systems. The main agent holds the goal and context, while subagents handle specific operations: collecting data, preparing a draft, checking against a policy. Using different models saves money. A cheap, fast model handles routine work, and an expensive, powerful one steps in where reasoning is needed.

This setup has a cost. One subagent's error can pass quietly up the chain, and debugging a multi-step process is harder than checking a single answer. Competitors in enterprise agents already exist, for example Microsoft with Copilot Studio and Salesforce with Agentforce, so Google is entering a crowded segment. Deep integration with its own workplace stack could become its argument, but the article offers no confirmation of that.

What to check before a pilot

If you are considering a test, start with the questions the announcement does not answer.

• Which systems connect out of the box, and which require custom connectors
• How cost is calculated: per request, per token or per "agent-hour", and whether subagents are counted
• Whether the agent's permissions can be restricted at the level of individual operations rather than whole applications
• Where action logs are stored and whether they can be exported to your own monitoring system
• How the agent's mailbox is protected against instruction injection through incoming emails

A sensible first scenario is a narrow process with a verifiable result and a human who confirms the final step. Grant the agent read access first, and add write access gradually, after reviewing real logs.