Production-ready agents, Part 11.75: What Gemini Enterprise is: one work agent, connectors, skills, plugins and sandboxes

In partner meetings I keep hearing the same words used for different things. One person says “connector” and means a data source. Another means an MCP server. Someone asks whether we support “plugins”, and half the room thinks of Part 9’s guardrail plugins while the other half thinks of an installable package. And lately everyone asks about “sandbox agents”, because every vendor seems to be launching one.

Part 12 publishes Acme’s router to Gemini Enterprise. Before we do that, this short part explains what Gemini Enterprise actually is, what its pieces are called, how the same pieces are named by other vendors, and what a sandbox-based agent is. Everything comes from public documentation and announcements, linked at the end. In August I wrote about the packaging side of this in Plugins vs agents: what changed in August 2026; this part builds on it rather than repeating it.

If you prefer to watch first, here is the heart of this part as a short animated explainer.

Video: what Gemini Enterprise is and what its connectors, plugins and sandboxes really are, in three minutes. The narration is a synthetic voice; the script and animation are mine.

Where are we in the architecture?

This part adds no new box to Acme. It explains the Gemini Enterprise box itself: the Gemini agent, connectors, skills, the two meanings of plugin and sandbox-based agents. It also adds the top row: Gemini Enterprise for CX for Acme’s shoppers and the Legal industry edition for its lawyers. Part 1.25 walks through the whole picture, layer by layer.

where Part 11.75 sits in the Acme architecture: highlighted boxes are the subject of this part, solid boxes come from earlier parts, faded boxes arrive later

What do I need to know first?

These are the terms this part untangles. Each one is explained in more depth below.

A work agent is my label for the category: one general-purpose agent for knowledge work that connects to a company’s systems. Vendors do not agree on a name. Google’s documentation calls Gemini Enterprise “an intranet search, AI assistant, and agentic platform”, and in October 2026 Google announced the Gemini agent as “a single, universal agent for work”.
The host agent is the agent the user talks to, the one that decides which tools and skills to use. In Gemini Enterprise that is Gemini.
A connector is a configured link from the work agent to another system, such as Jira or Salesforce. It can bring data in for search, expose actions, or both.
An action is Gemini Enterprise’s word for a tool: one thing the agent can do through a connector.
A skill is written know-how: a folder with a SKILL.md file that says how to do one task well (Part 4).
A plugin means two different things, which is the cause of most confusion. More below.
A sandbox is an isolated machine where an agent can read and write files, run commands and keep working for a long time, separated from everything else.

If the list feels abstract, picture a hotel concierge. A guest asks for “dinner for two at eight, then a taxi”. The concierge is the host agent: they decide what to do and in what order. They have phone lines to restaurants and to the taxi firm (connectors), and on each line there are only a few things they can ask for: book a table, cancel a table, send a car (actions, which are tools). A binder behind the desk says how this hotel does things, such as “always confirm by text” (a skill). A welcome pack from a restaurant group, with its numbers and its booking rules in one folder, is a plugin in the workplace sense. A back office where a colleague can spend all afternoon planning a guest’s week-long trip, away from the busy desk, is the sandbox. And when the concierge passes a wine question to the hotel’s sommelier, who has her own rules about what to recommend, that is a registered agent.

The trap is to read these as six products to buy. They are six roles, and every vendor in this part fills the same roles under different names.

How does this apply to Acme? Here is the host agent and a registered agent in one request, as Part 12 sets it up. Maria, in Gemini Enterprise, asks “Draft my weekly update with the Acme Pure Refill Launch results”:

1. Gemini (the host agent) reads the request. Drafting the update is its own job.
2. The figures are not: it hands "How did the Acme Pure Refill Launch perform?" to Acme's router,
   a registered agent.
3. The router answers with grounded figures, such as Acme Pure spend EUR 283,590, checked by its
   own number check.
4. Gemini writes the update around those figures and shows Maria the draft.

Gemini decided what to delegate; the router, in code, decided who owns each figure.

What kind of product is Gemini Enterprise?

Gemini Enterprise is search, an assistant and an agent platform in one product, and since October 2026 one Gemini agent sits in front of all three. The common mistake is to think of it as a chatbot over company documents. That is where it started; the agent layer is what changed.

A public library is a fair picture. The catalogue and the shelves are the search layer: they tell you what exists and where, and the staff-only rooms stay locked to you. The librarian at the desk is the assistant: you ask in plain words and get an answer, with the book it came from. The new part is a librarian who will also take a job away, such as “gather everything on local flood history by Friday”, working in a back room and calling the archive specialist when needed, while you go home.

How does this apply to Acme? At Acme, this is how the same three layers would look for Maria. Part 12 builds the hand-off to the router.

Search:        "Find the Refill Launch brief"     a document from a connected store, with a link
Assistant:     "Summarise it in five bullets"     an answer grounded in that document
Gemini agent:  "Draft my weekly update with the launch results"
               plans the job, hands the figures to Acme's router (a registered agent), writes
               the draft, and could keep working after she closes her laptop

It is easiest to describe in layers. Google’s overview page starts with search: prebuilt connectors to systems like Confluence, Jira, SharePoint and ServiceNow, “permissions-aware access to enterprise information”, conversational answers, and the ability to “host custom AI agents”. On 8 October 2026, at Gemini at Work 2026, Google added the layer that changes how it feels to use: the Gemini agent.

the anatomy of Gemini Enterprise as of October 2026: people reach one Gemini agent from many channels; it chooses a model, uses tools through connectors, follows skills, remembers context, creates sub-agents and calls agents you register; long work runs inside Agent Sandbox and all traffic passes through Agent Gateway

From the announcement, these are the parts that matter for anyone building agents around it:

One agent, many channels. The Gemini agent “can answer your questions when you chat with it, work autonomously to complete objectives you assign it, and generate code”, and can be reached from web, mobile, desktop and “any channel (command line, Google Workspace, Microsoft 365, or Slack)”. It can also run as a headless agent, without its own interface.
Persistent execution. “Work that takes hours or days keeps running after you close your laptop.”
Sub-agents and coworker agents. It can “dynamically create a roster of sub-agents”, each with its own identity, and Google describes longer-lived coworker agents with their own identities and storage.
Model choice. “Gemini is the agent, and the model underneath it is a separate choice.” The announcement names Gemini models and Claude models today, and the release notes show that since 15 October 2026 administrators can turn on Claude Opus 5.5 and Claude Sonnet 5.5 in the Gemini Enterprise app.
Tools, skills and memory. Tools connect it to company systems, including “any Model Context Protocol (MCP) server”, with an enterprise tools registry. Skills, with a company skills registry, teach it how work gets done. It keeps “four kinds of memory”: session, semantic, procedural and episodic.
Governance. “All Gemini agents execute tasks safely inside an Agent Sandbox with its own network boundary”, and “all traffic, in, out, and between agents, passes through Agent Gateway”. Spend caps pause a project’s agent when it reaches its limit, and they count “token usage and sandbox costs”.

Alongside the Gemini agent sit the pieces Part 12 covers: agents you build and register (ADK or A2A), Google-made agents such as Deep Research, Workflow Builder for no-code agents, and search over connected data.

One honest gap: the announcement describes the Gemini agent’s capabilities but does not give a launch stage for most of them, and I have not tested them for this series. Treat the details above as what Google has announced, and check the current documentation for what is available in your edition.

Where do Gemini Enterprise for CX and the industry editions fit?

The name “Gemini Enterprise” now appears on several products, and they are not all the same kind of thing. If the Gemini Enterprise app is the front door for employees, the other two are a front door for customers and a set of bundles that plug into the employee front door.

Think of a bank. Staff sign in to the back-office system to look up policies and draft letters: that is the employee front door. Customers walk up to the counter or ring the phone line, usually with no staff login at all: that is a separate customer front door, with its own scripts and its own rules. And when the mortgage team has a specialist toolkit (the lending rules, the calculators, links to the credit agencies) loaded onto the same back-office system, nothing new appears at either door; the staff system simply knows more about mortgages. That toolkit is an industry edition. Where people get tripped up is the shared name: three products carry “Gemini Enterprise”, but there are only two front doors, and only one of them is for customers.

How does this apply to Acme? The diagram puts Acme in the same three places: Maria at the employee door, a shopper at the customer door, and Acme’s lawyers using a toolkit inside the employee door.

three Gemini Enterprise names, three different things: the Gemini Enterprise app is the front door for employees; Gemini Enterprise for Customer Experience is a separate solution for agents that serve your customers; the industry editions are bundles of skills, connectors and agents installed inside the Gemini Enterprise app

Gemini Enterprise for Customer Experience (CX) is a separate solution for the people your business serves, not the people who work there. Google’s documentation describes it as “an agentic solution designed to bring shopping and customer service together on a single intelligent interface for businesses”, with “prebuilt and configurable agents” that cover “the entire customer lifecycle, from initial product discovery to post-purchase resolution”. Its parts:

Customer Experience Agent Studio: build agents “with both generative AI and deterministic functionality” for customer self-service.
Agent Assist: helps human customer care representatives in the moment, with “generative knowledge assist, summarization, smart reply, and live translation”.
Customer Experience Insights: KPIs, call drivers and sentiment for operations managers.
Commerce agents and AI Commerce Search: end-to-end agents for commerce use cases that “connect frontend interfaces like chat and voice directly to backend tools”, and search and recommendations for your digital properties.

So the difference from the Gemini Enterprise app is who is asking, which is the question that drives identity in Part 7 and front doors in Part 12.5. Maria is an employee signed in with Acme’s identity provider. A shopper on acme.com is a customer, often not signed in at all, talking by chat or voice.

The industry editions are the opposite: not a new front door, but the Gemini agent specialised for one industry, inside the same Gemini Enterprise app. At Gemini at Work, Google said it is “specializing Gemini for individual industries, with the skills, tools, and knowledge specific to each one”, in preview for Financial Services and Legal and “coming soon to Government, Healthcare, and Retail” (as of 8 October 2026). On 20 October 2026 Google then announced Gemini for government services in preview, “part of our new suite of purpose-built industry solutions”.

Look inside one and you find the building blocks of this series. The Financial Services announcement lists four components, and the government one lists five that follow the same pattern:

Skills (Part 4): “reusable packages of instructions and context that teach an agent to run a specialized task the way your institution runs it”. The government edition’s skills apply “the statute, regulation, and agency guidance that govern that task”.
Connectors over MCP (Part 2): “direct integrations, using MCP, into essential financial platforms and licensed data sources”, where “access stays bound by the entitlements you already maintain”.
Agents (Parts 1.75 and 6): the Financial Research agent is “a Google-built, Google-managed agent” with “more than 50 foundational skills”, which teams can “wire it into existing agent workflows through Agent-to-Agent (A2A) APIs”. That is a managed agent you reach over A2A. Partner agents sit alongside it, such as the government edition’s agents for FOIA discovery and batch redaction, “with a person approving each consequential step” (Part 9’s approval pattern).
A governed control plane (Parts 7, 9 and 12): one place for security teams to enforce policy, with VPC Service Controls and CMEK named in both announcements, and answers grounded with citations.

Are they “plugins”? Google does not use that word for them in these announcements. But in the workplace sense from the plugin section below (a package of skills and connector settings that a host agent uses), an industry edition is the same idea at a larger scale: a curated bundle of skills, connectors and agents, plus governance, for one industry.

A quick test for where a request belongs, asked in this order:

1. Is the person asking a customer, not an employee?          Gemini Enterprise for CX
2. Is it an employee doing everyday work across company
   systems?                                                    the Gemini Enterprise app
3. Is it an employee in an industry with an edition (such as
   financial services or law) who needs that industry's
   skills and licensed data sources?                           an industry edition, inside the app

How do they relate to managed agents?

Part 1.75 sorts hosted agent products into a three-level ladder: hosted tools, managed agents (the vendor runs the loop and the sandbox), and hosted runtimes for your own code. That ladder explains both products:

Industry editions        a bundle: skills and MCP connectors (materials for any agent) plus
(e.g. Financial          agents. The Financial Research agent is described as "a Google-built,
Services, Legal)         Google-managed agent" that teams can wire into their own workflows over
                         A2A: a level 2 managed agent with an industry's skills built in.
Gemini Enterprise for    a product for agents that serve your customers. You configure agents in
Customer Experience      Customer Experience Agent Studio, which "is built on Agent Development
                         Kit (ADK)", and Google runs them, alongside prebuilt commerce agents. By
                         the ladder's definition that is level 2 too, but pointed at shoppers on
                         chat and voice, not called by your own agents.
Acme's market watch      the same level 2 idea for Acme's own public research job (Part 1.75).

So all three are managed agents in the ladder’s sense: Google runs the loop and the infrastructure, and you supply instructions, skills and connections. What differs is who they serve: Acme’s router (market watch), Acme’s employees inside Gemini Enterprise (an industry edition), or Acme’s customers (GE for CX). Acme’s diagram shows all three, and none of them reads governed data through the router.

What does Acme use them for?

Both appear in Acme’s architecture diagram at the top of this post, in the top row above the employee front door. At Acme, this is how each one would work, and each keeps the series’ rules intact.

Use case 1: consumer care with Gemini Enterprise for CX. During the Refill Launch stockouts, shoppers flooded Acme’s care line with “Where can I buy the Verde refill?” and “Why is it never in stock?”. Acme puts a customer agent on acme.com chat and its care phone line, built in Customer Experience Agent Studio, which Google’s documentation says “is built on Agent Development Kit (ADK)”. Agent Assist helps the human reps who take the calls the agent hands over, and Customer Experience Insights finds the call drivers.

1. Shopper (acme.com chat):  "Where can I buy the Verde refill near Leeds?"
2. Customer agent:           answers from Acme's public store-locator and product pages; if the
                             shopper is angry or asks for a refund, it hands over to a rep, and
                             Agent Assist suggests replies and summarises the chat for the rep
3. CX Insights:              tags the conversation with the call driver "out of stock: refill"
4. Export:                   insights are exported to a BigQuery table (CX Insights documents an
                             export to BigQuery), next to campaign_performance
5. Maria, next Monday:       "Did the stockouts hurt us beyond penalties?"  The marketing agent can
                             now count care contacts tagged "out of stock: refill" by week, as one
                             more measure in the semantic registry

The shopper never reaches the router, the specialists or any Acme figure. The only link between the customer side and the employee side is data: an exported, governed table, that our agents read with their usual narrow tools. That is the dashed arrow from GE for CX to BigQuery in the diagram.

Use case 2: contract review with the Legal industry edition. The penalties in this series (EUR 36,026 in Western Europe) come from clauses in retailer contracts. When a retailer sends a new contract, Acme’s legal team wants the OTIF penalty clause compared with the current one. Acme’s lawyers already use Gemini Enterprise; the Legal edition adds legal skills and connectors to the document systems where the contracts live, which Google says inherit “matter-level permissions and ethical walls” from platforms like NetDocuments and iManage.

1. Acme lawyer in Gemini Enterprise:  "Compare the OTIF penalty clause in the new retailer
                                       contract with the one we signed last year."
2. Legal edition:                     reads both contracts through the document-system connector,
                                       as the lawyer, within that matter's permissions
3. Gemini agent + legal skills:       returns the two clauses side by side with citations, and
                                       flags that the new per-unit penalty is higher
4. Later, supply's semantic registry: once the contract is signed, supply updates the penalty
                                       rate behind penalty_metrics; the router never reads contracts

The Legal edition sits inside the same Gemini Enterprise app as Maria’s router, but it serves different people and different data. The arrow in the diagram runs from the Legal edition into Gemini Enterprise, because that is where it is installed. Retail, when it arrives, would plug in the same way.

My view: treat the industry editions as a strong starting kit, not a replacement for your own system. They give you the domain skills and connectors you would otherwise write yourself; your own agents still own the decisions that are specific to your business, the way Acme’s router owns who may see which figure.

What do other platforms call the same things?

The building blocks are the same across vendors; only the labels change, so compare the blocks, not the labels.

British and American English make a good warm-up. A lift and an elevator are the same machine; a car’s boot and its trunk are the same space. A visitor who decides London has no elevators has been misled by the word, not by the building. Vendor vocabulary works the same way: an action in Gemini Enterprise is an MCP tool anywhere else, and a ChatGPT plugin is roughly what you add to Gemini Enterprise as an MCP connector plus skills.

Every work agent is built from the same few blocks: a host agent, links to other systems, know-how, a way to bundle those, a way to bring your own agent, and somewhere to run long jobs. The names differ. This is the map I use, built only from each vendor’s public documentation:

the same building blocks under different names: a connection to another system is a connector in Gemini Enterprise, Microsoft 365 Copilot and Claude, and part of a plugin in ChatGPT; each tool in it is an action in Gemini Enterprise; know-how is a skill almost everywhere; a bundle of skills and tools is a plugin; long-running work happens in a sandbox

A few notes on the map:

Microsoft calls its links to other systems Copilot connectors. Synced connectors “index data into Microsoft Graph”, and federated connectors “use a Model Context Protocol (MCP) model to fetch data in real time”. Its extensions are plugins, and Copilot Studio can call an A2A agent (Part 12.5).
OpenAI describes ChatGPT plugins as things you “build and publish … with skills, MCP servers, and optional UI”. There, the plugin is the package and the MCP server sits inside it.
Anthropic uses connectors for links to apps and services, which work over MCP, and its documentation has a section on skills.
Gemini Enterprise calls them connectors or data stores, and the custom MCP server guide states plainly that “the term data store can be used interchangeably with the term connector” and that MCP “tools” are “referred to as actions”.

How does this apply to Acme? At Acme, say the IT team writes one requirement: “Give the assistant access to our marketing MCP server.” Through the map, that one sentence becomes a custom MCP server connector whose tools show up as actions in Gemini Enterprise, a federated connector or a plugin in Microsoft 365 Copilot, a plugin with the MCP server inside it in ChatGPT, and a connector in Claude. One server, four labels. The questions that matter, which tools and acting as whom, are the same in all four.

My view: once you see the map, most product comparisons get simpler. Under the names, every vendor has settled on MCP for tools and something very close to Agent Skills for know-how. They now compete on what sits around those: the host agent, memory, governance, the sandbox and the marketplace.

Are connectors just tools?

Mostly, yes. A connector is the wiring; what travels over it is data, actions or both, and every action is a tool. A connector is a configured link, with credentials and settings, to another system. What it gives the agent is one or both of two things:

Data for search and grounding. The connector brings content into an index, or queries the source live. Gemini Enterprise and Microsoft both offer the two choices: ingestion (copy and index) and federation (fetch at question time). Part 14 covered the trade-off.
Actions. Each action is a tool, exactly like the narrow tools in Part 2: a name, a description and an input schema. A custom MCP server connector is a list of MCP tools that an administrator has chosen to enable. Gemini Enterprise’s guide recommends keeping the enabled actions in one custom MCP data store to 100 at a time. (For what changed in MCP itself in 2026, and the UTCP alternative, see Part 2.)

A simple way to hold the three apart is how you follow a football match. Reading this morning’s paper is ingestion: the news was printed overnight, so it is instant to read, but a late goal is not in it. Ringing a friend at the ground is federation: always current, but you wait for them to answer, and every call costs something. Asking that friend to buy you a programme is an action: it tells you nothing new, it changes something in the world. The connector is the phone line itself.

How does this apply to Acme? At Acme, this is how all three would work. Say Acme connects the source behind campaign_performance to a work agent, and Maria asks at 11:00 “What was Verde’s spend yesterday?”:

Ingestion: the connector copied and indexed the data at 02:00 last night.
  The answer comes from that copy: fast, but it shows what the source held at 02:00.
  A correction loaded at 09:00 is not in it until the next sync.
Federation: the connector queries the source when Maria asks, at 11:00.
  The answer includes the 09:00 correction, and every question waits on, and costs, a live query.
Action: an admin adds a custom MCP server connector and enables one action, a marketing query
  tool shaped like Part 2's query_marketing_measures(measures, brand, region, ...).
  The host agent picks it from its name and description, fills in brand=["Verde"], and calls it,
  exactly as an ADK agent calls a tool.

The first two decide where the data comes from; the third gives the agent something it can do.

Which do you need? Ask in this order, cheapest and safest first:

1. Is last night's copy good enough?            ingestion: fast and cheap per question
2. Must the answer include today's changes?     federation: current, but every question
                                                waits on a live query
3. Must the agent change something, not just    an action, and then ask: does it write,
   read it?                                     and whose credential does it use?

So when a partner asks “do you have a connector for X?”, the useful follow-up questions are the ones from Part 2 and Part 7: which actions does it expose, does it read as the user or with a shared credential, and which of those actions write data? Anthropic’s connector page makes the identity point well: Claude “inherits each person’s permissions from the connected service”, but “custom connectors that use a shared credential reach whatever that credential can access”.

Why does “plugin” mean two different things?

Because two communities picked the same word for opposite ends of the system. A workplace plugin adds abilities to someone else’s agent; an ADK plugin is a check you put inside your own.

Your phone shows the same split. An app you install from the store is the first kind: you choose it, it adds something the phone could not do before, and it runs only when you open it. Screen-time limits are the second kind: nobody installs them app by app, they sit in the phone itself and check every app you launch, every time. Same phone, two very different meanings of “add-on”. The trap is to say yes to “can you build us a plugin?” before asking which of the two.

two different things called a plugin: a workplace plugin is a package of skills and MCP server settings that a user or admin installs into an AI tool; an ADK plugin is code inside your own agent that runs before and after every model call and tool call, like the guardrails in Part 9

The workplace plugin is a package that extends a host agent. It bundles skills and MCP server settings so a user or administrator can install them in one step. This is the meaning in Agent Plugins 1.0, the standard released in August, and in ChatGPT and Microsoft 365 Copilot. The August post explains it in detail. As that post notes, Gemini Enterprise does not install a single plugin package today; you add skills and MCP servers separately.

The ADK plugin is code inside your own agent. ADK’s plugins are classes with callbacks that run around every model call, tool call and run, across the whole app. Part 9 used them for Acme’s kill switch, rate limit, Model Armor screen and audit log. Nobody installs them into anyone else’s agent.

So “should we build a plugin?” has two possible meanings. If you want your product to show up inside Gemini, Copilot or ChatGPT, you mean the first: an MCP server plus skills, packaged for each host. If you want every call your own agent makes to pass a check, you mean the second.

How does this apply to Acme? One Acme example of each, in the same order as the phone: the installed package first, then the check that always runs.

(a) Workplace plugin (hypothetical): an "Acme marketing" package.
    acme-marketing/
      skills/campaign-questions/SKILL.md   how to answer campaign questions well
      MCP server settings                  point at an Acme marketing MCP server
    An admin installs it in ChatGPT or Microsoft 365 Copilot. It does nothing on its own:
    it acts only when that host agent decides a question needs it.
(b) ADK plugin (in our build, Part 9): RateLimitPlugin inside the router, ACB_RATE_CAPACITY=20.
    Maria sends her 21st question in a burst. before_run_callback finds her bucket empty,
    logs a rate_limited event and returns a polite message. No model or agent runs.
    It runs on every question, and nobody installs it.

The host decides when the first one runs. Our code decides that the second one always runs.

What is a sandbox-based agent, and why is everyone building one?

A sandbox-based agent does long, hands-on work in an isolated machine, while a trusted harness outside it keeps the plan, the approvals and the audit trail. Where people get tripped up is assuming the isolation also decides permissions. It does not.

A chat assistant answers within one request. A lot of real work does not fit in one request: reading a data room, building a spreadsheet, running analysis code, or working through a task for hours. For that, the agent needs a workspace of its own. OpenAI’s sandbox agents guide puts it well: a sandbox gives an agent “an isolated, Unix-like execution environment with a filesystem, shell, installed packages, mounted data, exposed ports, snapshots, and controlled access to external systems”.

Picture a builder renovating one flat in a block. The builder works inside that flat for days, with tools, dust and half-finished work: that is the sandbox. The site manager in the office keeps the plan, signs off each stage and keeps the log: that is the harness. The block’s front desk decides whether the builder may enter the flat next door or the plant room, whoever’s name is on the request: that is the gateway, carrying identity. And the client’s budget stops the job when it runs out: the spend cap. Shutting the builder inside one flat protects the neighbours from the mess; it does not decide which other doors open.

a sandbox-based agent: the harness that runs the agent loop, approvals and audit sits in trusted infrastructure; the work itself runs in an isolated sandbox with a filesystem, shell and packages; everything the sandbox reaches goes through a gateway that applies policy and adds the right identity

The same guide draws the line that matters for production. The harness is “the control plane around the model”: the agent loop, model calls, tool routing, approvals, tracing and recovery. Compute is the sandbox, where model-directed work runs. Keeping them apart lets you keep “auth, billing, audit logs, human review, and recovery state outside any one container”. That is the same idea as Part 1.5’s harness, with the risky work moved into its own box.

How does this apply to Acme? Here is the same split, site manager, builder, front desk and budget, on one overnight job for Maria: “Build the quarterly campaign analysis for Acme Pure, Verde and Harvest Row”:

1. Harness (trusted side): runs the agent loop, keeps the plan, records every step for audit,
   and holds any approval Maria must give.
2. Sandbox (compute): the model-directed work. It writes analysis.py and a CSV to its own
   filesystem, runs the script, fixes it and runs it again, for hours.
3. Gateway: when the script tries to read service_cost in Databricks, the call leaves the
   sandbox through the gateway, which applies policy and carries Maria's identity.
   service_cost is granted to supply and finance only, so the call is refused, however isolated
   the sandbox is. The analysis goes ahead with the marketing data and says what is missing.
4. Spend cap: if the job reaches its limit, it is paused (Part 11.5's budget, applied by the platform).

The sandbox decides nothing about permissions. The harness, the gateway and the cap do.

Do you need a sandbox-based agent at all? Cheapest first:

1. Does one request with a few tools answer it?      a normal agent, like most of Acme's questions
2. Does one step need to run generated code?         sandbox that step only (Part 3.5)
3. Does the job need files, a shell and hours?       only then a sandbox-based agent, behind a
                                                     gateway and a spend cap

Every major vendor now offers a version of this, each in its own words:

Gemini Enterprise runs every Gemini agent’s tasks “inside an Agent Sandbox with its own network boundary”, with all traffic through Agent Gateway, and the agent’s identity “stamped into … any virtual machine spun up to run code on its behalf”.
The Gemini API lists an Antigravity Agent, “a general-purpose managed agent that autonomously plans, reasons, runs code, manages files, and browses the web inside a secure, isolated Linux sandbox”, under a preview model ID. Its agents overview also lists a Deep Research agent, and ADK can call these managed agents as a step in your own agent. Part 1.75 explains how a managed agent differs from a tool, what jobs suit one, and how each vendor offers them.
Anthropic’s Claude Managed Agents provide “the harness and infrastructure for running Claude as an autonomous agent”, where each session runs in an environment: “an Anthropic-managed cloud sandbox, or a self-hosted sandbox on your own infrastructure”.
OpenAI offers sandbox agents in its Agents SDK, as above.

Meta’s developer site describes the same direction from another angle: its Muse Wonder model is pitched for “long-running agents” that plan the work and delegate “parts to sub-agents”. Its page does not describe a sandbox, so I leave it out of the list above.

How this connects to the series:

Part 3.5 put one step, running generated code, in a sandbox. A sandbox-based agent puts the whole job there.
Part 7 and Part 12. The sandbox isolates the work, but it does not decide what the work may reach. Identity and a gateway do that, which is why Google pairs Agent Sandbox with Agent Gateway.
Part 11.5. Long jobs need budgets. Gemini Enterprise’s spend caps count sandbox costs and pause the agent, which is Part 11.5’s budget idea applied by the platform.

Where does Acme fit in this picture?

For governed figures, Acme plugs in as a registered agent that keeps its own rules; for light, low-risk lookups, tools and skills are enough.

A hospital ward shows the two paths. A doctor who needs a medicine can send a prescription to the pharmacy, where a pharmacist checks the dose, the allergies and whether this doctor may prescribe it before anything is handed over. Or the ward can be given a key to the medicine cupboard: faster and simpler, but now the checks depend on whoever holds the key. Neither is wrong in general; plasters can live in the open cupboard, controlled drugs cannot.

Acme’s agents can meet a work agent in two ways, and the August post called them the open path and the boxed path.

As a registered agent (the boxed path). This is what Part 12 does: the router is published to Gemini Enterprise, and the Gemini agent hands it questions that need Acme’s governed figures. Acme keeps its own routing, number check and guardrails.
As tools and skills (the open path). Acme could offer an MCP server, added as a custom MCP connector, plus skills in the company registry. The Gemini agent would then do the thinking, in its own sandbox, and call Acme’s tools as actions.

For Acme’s numbers I would stay on the boxed path, because the series’ central rule is that code, not a model, decides who owns which metric (Part 1), and that logic lives in the router. For lighter tasks, such as looking up campaign metadata, the open path is less to build and maintain.

How does this apply to Acme? The router is the pharmacy, and a connector with a shared credential is the cupboard key. Here is the same question down both paths: “What did the Acme Pure stockouts in Western Europe cost us?” The open path is shown for contrast; Acme’s build offers no MCP connector.

Boxed path (Part 12):
  1. The Gemini agent hands the question to Acme's router.
  2. Code labels it delegate: penalties belong to supply, so it goes to the supply agent,
     carrying the asking user's identity (Part 7).
  3. Supply answers from service_cost: EUR 36,026.40.
  4. The number check confirms every figure in the reply came from supply. Maria sees EUR 36,026.40.
  5. Ian the intern asks the same thing. Same route, but he gets Part 10's refusal, not the figure.
Open path (suppose Acme exposed its query tools as actions):
  1. The Gemini agent reads the action descriptions and picks one itself.
  2. Nothing in code says penalties belong to supply, and no number check runs on the answer.
  3. If the connector uses a shared credential, Ian gets EUR 36,026.40 as well.

On the boxed path, Acme’s code makes the ownership and permission decisions. On the open path, the host model and whatever credential the connector holds make them.

The test I use before choosing, cheapest first:

1. Is it read-only, low-risk and fine for anyone        open path: an MCP connector and skills
   who can already see the source?
2. Does a team own the figure, or may only some         boxed path: a registered agent with its
   people see it?                                       own routing and checks
3. Not sure?                                            boxed path; it is easier to open up later
                                                        than to lock down

This is Part 1’s rule again: when ownership matters, code decides, not the model.

What can go wrong

Buying the word, not the feature. “We support connectors” can mean search over a copy of the data, live federation, write actions, or all three. Ask which.
A connector with a shared credential. It reaches whatever that credential can reach, for every user. Prefer connectors that act as the signed-in user.
Building the wrong plugin. An installable package and an ADK guardrail plugin are different jobs with different owners. Agree which one before estimating.
Treating the sandbox as the security model. Isolation stops the work escaping its machine; it does not stop the agent calling a system it should not. That needs identity and a gateway.
Assuming platform settings cover your agent. Gemini Enterprise’s console setting for Model Armor does not protect custom ADK or A2A agents (Part 12.5); screen inside your agent (Part 9).
Too many actions. A connector with hundreds of enabled actions makes tool choice harder, for the same reasons as Part 2’s narrow tools.

Try it: translate a requirement into building blocks

No code this time. Take one sentence from a real requirements document, for example “The assistant must use our Jira connector and the procurement plugin, and run the quarterly analysis overnight”, and rewrite it in the vocabulary of this part:

“Jira connector”: which actions (tools), reading as whom, and is any of them a write?
“Procurement plugin”: an installable package of skills and MCP servers for a host agent, or a check inside our own agent?
“Run overnight”: does the platform run long jobs in a sandbox, what does that sandbox reach through the gateway, and what budget stops it?

If you cannot answer one of the three from the requirement, that is the first question to send back.

Here is one worked answer for that sample sentence. The details are what I would propose, not what the sentence says:

1. "Jira connector" = two actions, both acting as the signed-in user, not a shared credential:
   - search issues (a read, safe to retry)
   - create an issue (a write: needs the user's approval, and is never retried blindly)
2. "Procurement plugin" = a workplace package (skills plus MCP server settings) for a host agent.
   Not an ADK guardrail plugin. If the host is Gemini Enterprise, the skills and MCP server are
   added separately, because it does not install a single plugin package today.
3. "Run overnight" = a long job in the platform's sandbox. It reaches only the endpoints the gateway
   allows for that user, and a spend cap pauses it at a set limit.
Questions back: who approves issue creation, who owns the procurement skills, and what is the cap?

What code did we write in this part?

Every part ends with the same map of Acme’s build: which files exist so far, and the code this part added, explained line by line. The map grows with each part.

This part adds no code to Acme’s build. It is a concept part that explains what Gemini Enterprise is and untangles its vocabulary: connectors, skills, the two meanings of plugin and sandbox-based agents. Its examples are worked walkthroughs in plain text, and its exercise is to translate a requirement into building blocks, with no code.

Where does it live?

router/                                             the router agent: extract, route, write
  app/agent.py                                      P5,8        workflow; extract reads memory; App with compaction and resumability
  app/app_utils/services.py                         P8          picks the session, artifact and memory services
  app/fast_api_app.py                               P8          Runner with session, artifact and memory services
  app/remote.py                                     P6,7        A2A client over mTLS; metadata carries Sam's token
  app/writer.py                                     P5,8        writer reads memories and saves the conversation to Memory Bank
  scripts/create_memory_bank.py                     P8          creates the Memory Bank and its topics, once
  tests/eval/acb_metrics.py                         P10         code metrics: route_correct, grounded, golden_numbers
  tests/eval/build_datasets.py                      P10         splits source cases into golden and held-out, seed 42
  tests/eval/calibrate.py                           P10         compares judge scores with human labels (kappa)
  tests/eval/datasets/golden_marketing.json         P10         golden cases with expected route, target and numbers
  tests/eval/eval_config.yaml                       P10         eval metrics, including the faithfulness judge
  tests/eval/gate.py                                P10         thresholds per metric; exits 1 when one fails
  tests/unit/test_router.py                         P10         unit tests; routing checked with one row per question type
marketing/                                          the marketing specialist, on BigQuery
  app/agent.py                                      P1,2,3,4    marketing agent with its skill in a SkillToolset
  app/app_utils/a2a.py                              P6          A2A endpoint and agent card (1.0 and 0.3) for marketing
  app/skills/marketing-kpis/SKILL.md                P4          marketing know-how: which tool, definitions, story checks
  app/skills/marketing-kpis/references/tables.md    P4          tables, grain, measures and the join rule, read on demand
  app/tools.py                                      P1,2        three narrow tools: measures, unserved demand, SQL fallback
  tests/unit/test_marketing.py                      P2          unit tests for the tools, with a fake context and database
supply/                                             the supply specialist, on Databricks
  app/agent.py                                      P3,7,8,9    supply agent and App with the confirmed replan tool
  app/app_utils/a2a.py                              P6          A2A endpoint and agent card (1.0 and 0.3) for supply
  app/skills/supply-catalog/SKILL.md                P4          supply know-how, given only to the supply agent
  app/tools.py                                      P3,7,9      supply tools; the replan tool asks a human first
shared/                                             code all three services share
  adk_common.py                                     P3,6,9,11   plugins and redacted JSON logs, now with the usage ledger
  auth_manager.py                                   P7          auth manager callback: token or consent (off by default)
  engines.py                                        P3,7        run_databricks connects as the signed-in user
  factcheck.py                                      P5          ungrounded_numbers: finds figures not in the findings
  registry.py                                       P2          reads semantic.yaml: measure names, computable measures
  routing.py                                        P1          classify: picks the specialist in code, no model
  safety.py                                         P9          per-user token bucket and injection pattern scan
  semantic.yaml                                     P1,2        registry of measures, owners and published formulas
  skill_source.py                                   P4          loads a skill from disk or a pinned registry revision
  sqlguard.py                                       P3          guard_sql read-only allow-list; redact for log lines
  tests/test_cost_report.py                         P11         unit tests for the cost maths
ops/                                                build, deploy and evaluation tooling
  .cloudbuild/eval_gate.yaml                        P10         after staging: eval run, then gate.py
  .cloudbuild/pr_checks.yaml                        P10,11      offline PR checks, cheapest first, ending with the mutants
  env.sh.example                                    P11         settings for every engine: ids, models, plugin switches, OTEL; no secrets
  tools/cost_report.py                              P11         prices the ledger and reports cost per resolved question
  tools/mutants/acb_mutate.py                       P10         pytest plugin that injects each mutant's fault
  tools/pricing.json                                P11         list prices per model, kept out of the code
  tools/run_mutants.py                              P10         runs the offline suites once per mutant

+ added in this part   ~ changed in this part   Pn = the parts that touched the file

What did we learn?

Gemini Enterprise is search, an assistant and an agent platform, and since October 2026 it is built around one Gemini agent that plans, uses tools and skills, writes code, delegates to sub-agents and runs long work in Agent Sandbox behind Agent Gateway.
Work agents from different vendors share the same building blocks under different names. MCP for tools and skills for know-how are common to all of them.
A connector is a configured link that provides data, actions or both; an action is a tool.
“Plugin” means a package that extends someone else’s agent (Agent Plugins, ChatGPT, Microsoft 365 Copilot) or code that runs around every call in your own agent (ADK, Part 9).
Sandbox-based agents keep the harness in trusted infrastructure and run the work in an isolated machine. Isolation is not permission: identity and a gateway still decide what the work can reach.

What comes next?

In Production-ready agents, Part 12: Giving it to users we publish Acme’s router to Gemini Enterprise, handle user consent, control where the agents can connect with Agent Gateway, and roll out in stages.

Sources

Opinions are my own. Every fact in this post comes from the public documentation linked above.