What_Google_Actually_Shipped

The Gemini Enterprise Agent Platform is structured across four operational zones: Build, Scale, Govern, and Optimize. Each zone solves a class of failure:

Build (Agent Studio, Agent Development Kit, Agent Garden) solves the authoring problem. Agents must be authored somewhere, by someone, in a form that can be reviewed and deployed. Studio provides visual authoring; ADK provides code-first development with graph-based orchestration primitives built in. The failure mode: agents authored in isolation, without a shared contract for how they connect.

Scale (Agent Runtime, Sandbox, Memory Bank, Sessions) solves the execution problem. Agents run somewhere; they maintain state; they may run for seconds or days. The failure mode: single-point-of-failure agent that blocks the entire system when it times out or errors.

Govern (Agent Identity, Agent Registry, Agent Gateway, Agent Threat Detection) solves the accountability problem. Every agent in production must have a cryptographic identity, must be catalogued, must route through a uniform access control point, must be monitorable as a threat surface. Without this layer, you have untracked code running with model keys. The failure mode: deployed agents nobody knows about, running with permissions they shouldn't have, producing output nobody is logging.

Optimize (Agent Simulation, Agent Evaluation, Agent Observability, Agent Optimizer) solves the validation and debugging problem. Agents must be tested before deployment. Failures in production must be retrievable and debuggable. The failure mode: agents shipped untested, failures discovered in production incident calls, entire audit trails replaced with guesses.

This is a governance stack with tooling implementations, not a tooling stack. Google has named the layers because the layers are non-negotiable.

How_My_System_Maps_to_Google's_Stack

Layer by layer, my agent system against Google's stack:

Registry - My agent roster maintains a canonical list of 12 agents with their domains, model assignments, and trust tier. Google's Agent Registry serves the same function: central library, source of truth, approval gate. Why it was built: The first time an agent was deployed nobody knew about, the lack of a roster became visible. A registry is a solved problem only if you have one.

Orchestration - Sheena is my orchestration persona - the coordination mode I put on for dispatch and multi-specialist routing. All tasks requiring coordination flow through Sheena; Sheena delegates to specialists; specialists never delegate to each other. Google's Agent Runtime with orchestration primitives (Sub-Agent Framework) serves the same structural role: one explicit router, clear delegation paths. Why it was built: Uncoordinated agents stepping on each other's work costs time in meeting notes. A delegator is structural overhead worth its weight.

Recently I built EXP_006 (ADK Visualiser) and EXP_007 (Orchestration Map) - experiments that make agent topology visually inspectable, with live LLM annotation of delegation decisions. The topology was working. It was not legible. A collaborator reading the CLAUDE.md could not trace task routing without reconstructing it by hand. Observability at the orchestration layer is not just logs. It is whether the routing logic is readable without deconstruction.

Identity & Scope - My model tiering system assigns scope by agent: Sonnet runs orchestration and code/QA/research/strategy; Haiku runs copy/social/content/design/ops. The override ceiling is Sonnet - no agent runs on Opus. Each agent has one model, one domain, one trust tier (Autonomous / Always-Review / Conditional). Google's Agent Identity assigns each agent a cryptographic ID and authorisation policies. Why it was built: An agent with the wrong scope is an agent that will take actions it shouldn't. Scope drift is silent until production.

Gateway - My trust tier protocol is the gateway. Autonomous agents (Tom, Nix, Jo) execute without review. Always-Review agents (Vera, Lena) never execute without human sign-off. Conditional agents (Sable, Quinn, Oren, Reid, Maya, Cleo) execute only within explicit bounds and escalate on anomaly. Google's Agent Gateway is the unified access control point - enforces security policies, manages connections, detects anomalies. Why it was built: Without a gateway, every agent is every agent. With a gateway, an agent that tries to read files outside its scope can be caught.

Observability - My nightly repo audit (EXP_004) spans 8 repos, running 3 drift checks per repo: open Dependabot PRs, stale branches over 30 days, and pull requests open longer than 7 days. It was built proactively, not reactively. Google's Agent Observability layer provides visual tracing of reasoning, real-time lens into decision-making, anomaly detection. Why it was built: Observability built reactively is incident response. Observability built proactively is governance.

Validation - My PR Comprehension Gate (3 core + 4 extended questions, unanswered blocks merge) is pre-deployment validation. Post-merge verification checks code against the brief's acceptance criteria. Google's Agent Simulation layer validates agents against synthetic user interactions and virtual tools before they run. Why it was built: Agents shipped untested fail in production at model-key scale. Testing before deployment is the only reliable way to catch it.

Each mapping is bilateral. The Google component exists because practitioners have spent two years solving the same problem manually. My artefacts exist because the specific failure modes are predictable and the costs are material.

The_Five_ADK_Lessons_and_What_They_Reveal

Google published a case study in April 2026 documenting the refactor of a brittle single-agent sales research tool into production-grade multi-agent architecture. The five lessons from that refactor, and how they map to a system I've been running:

Ditch the monolith for orchestrated sub-agents. The original agent was a single loop; one sub-task failure stalled the entire process silently. The fix: decompose into specialised sub-agents (Company Researcher, Search Planner, Case Study Researcher, Selector, Email Drafter), each with a bounded responsibility. My agents are assigned by domain: Nix (frontend), Sable (backend), Quinn (security), Tom (data), Oren (platform), Reid (brand strategy), Vera (copy), Lena (social), Cleo (content). Decomposition is visible in the agent roster and in the delegation protocol. Each agent has one clear responsibility; failures in one domain do not block the entire pipeline.

Force structured outputs. The original system relied on freeform LLM text; downstream steps broke whenever the output deviated. The fix: replace freeform output with typed, validated schemas - in Google's case, Pydantic. In my system, the equivalent is Zod: all API payloads are validated at the boundary before they reach any downstream logic. Every external call expects a defined shape; any deviation is caught at entry, not discovered mid-pipeline. Pydantic and Zod solve the same failure mode in different stacks - the insight is the same: trust the schema, not the model output.

Replace hardcoded state with dynamic context retrieval. The original system bundled static knowledge into the prompt; it went stale and bloated token usage. The fix: move to a RAG pipeline - retrieve relevant context at request time based on what the current task actually needs. My system handles this through tiered context injection in the chat engine: always-on context (nine files, injected every request) and on-demand context (four files, injected only when keyword matching flags a relevant topic). This is a primitive RAG pattern - context is retrieved based on the request, not bundled statically into the prompt. It is not a vector database; it is the same architectural instinct applied at smaller scale.

Model assignment in my system is also a live cost decision built into this layer. During EXP_006 (ADK Visualiser) and EXP_007 (Orchestration Map), I switched from Claude to OpenAI mid-build - not capability, cost. At iteration volume, the difference is material. Context and model scope that make sense at proof-of-concept may not hold at production volume. That decision point has to be built into the process, not assumed as static.

Observability is non-negotiable. The original system had no visibility into failures. The fix: OpenTelemetry tracing, live diagnostics, anomaly detection - built in before the system reaches production load. My nightly repo audit (EXP_004) was built before agents were failing in production; it runs nightly and flags drift across 8 repos. This is proactive governance, not reactive incident response.

Tame the token burn. The original system had no budgets, no circuit breakers, no retry boundaries. Agentic loops consumed model quota in minutes. The fix: framework-level cost controls - exponential backoff, strict timeouts, circuit breakers at the agent level. My rate limit protocol in the chat engine forces backpressure; memory.ts fails closed on rate limits (safe default). An agent that can consume unbounded resources is not a governed agent.

The most useful lesson is implicit: observability built reactively is incident response. Observability built proactively is governance. The difference is whether you discover a problem because users complained or because a metric flipped. My nightly audit was built to flip the metric first.

What_the_Google_Stack_Doesn't_Solve

The platform is accurate as mapped, and incomplete as specified. Three gaps are visible:

Specification layer. Registry, orchestration, identity, gateway, observability govern how agents run. They do not govern what agents are told to build. Spec-Before-Code is a layer above infrastructure: written briefs, module manifests, comprehension gates, acceptance criteria. These are specification governance. Google solves the operational layer. The specification layer remains the operator's responsibility.

Concrete recent example: three articles drafted in sequence went through three revision rounds - 3rd person voice corrected to 1st person, missing deliverable fields identified, format inconsistencies resolved. Each revision round is specification debt. The spec (voice, required fields, format) was not complete before drafting started. No registry flags a 3rd-person article in a 1st-person voice. The operator catches it in revision. The correct fix: write the format spec before the content process begins - which is what happened after round 3. The deliverable format is now standardised and committed to the system. The spec-before-factory rule applied to the content factory.

Coordination memory. Agent Registry tracks deployed agents. It does not track cross-session decisions: why Sheena was chosen as orchestrator, why Sonnet was assigned to code specialists, why trust tiers were assigned this way, what changed and why. My cross-project awareness system records the reasoning behind those decisions. This is documentation as governance. Infrastructure cannot codify it.

Trust development. Agent Identity assigns scope but does not specify how scope decisions are made, how they evolve, or what happens when an agent needs escalation. My trust tier system has escalation paths baked in: Conditional agents flag, not decide; Autonomous agents execute within bounds. But the process by which an agent graduates from Always-Review to Conditional is not infrastructure - it is discipline. It requires a pattern of decisions applied consistently over time.

The gaps are not product failures. They are boundaries between what infrastructure can govern and what the operator must govern. The stack names the layers that can be automated. It assumes the operator will govern everything above them.

What_This_Means_If_You're_Running_Agents_Now

Three observations, each with an action:

First: name the layers you have. If you are running agents by hand, use Google's vocabulary. Name your registry. Name your orchestrator. Name your identity system (even if it is a spreadsheet). Name the layers you are missing. The inventory is step one. You cannot govern what you have not named.

ACTION: Write a one-page diagram of your agent system using the four zones (Build, Scale, Govern, Optimize). List what you have in each zone and what is missing.

Second: infrastructure is necessary but not sufficient. The Google stack is a coherent set of tools. Running it does not solve specification drift, dark code, or cross-session decision tracking. Those problems live one layer up. You can have a perfect registry and still deploy an agent nobody asked for, because specification governance failed before it got to registry. You can have perfect observability and still miss a failure because you were not watching the right metric, because observability was built reactively instead of proactively.

ACTION: Audit one failing agent deployment in the past month. At which layer did the failure originate - specification, infrastructure, or operator discipline? Write down the root cause and the layer where it should have been caught.

Third: the convergence is telling you something. When multiple independent practitioners wire the same layers and a vendor productises them, those layers are necessary conditions. The platform validates that the layers are non-negotiable. It does not validate the tool choice or the specific implementation. The question is build or buy - a resourcing question, not an architecture question. Run the math on your own.

ACTION: For each of the four zones, decide build or buy. If buy, sketch the integration cost. If build, estimate the overhead of maintaining custom tooling. The decision is about your specific constraints, not about the Google platform.

The_Discipline_That_Infrastructure_Cannot_Automate

Every layer in the Google stack is automatable. Authoring can be visual or code-first. Routing can be graph-based or sequential. Governance can be enforced by policy engines and gates. Observability can be centralised or distributed.

The specification work - deciding what agents will build, to what standard, under what constraints, with what failure modes in mind - is not automatable. Running agents at enterprise scale requires the same discipline as a production launch: holding requirements, constraints, operating context, and failure modes in mind simultaneously, before the system runs. You must write a brief before you build. You must define acceptance criteria before you deploy. You must decide what failure modes are acceptable before you ship. That discipline is what Launch Integrity names.

The industry is building infrastructure for that accountability. Google's platform is one instance. The discipline is not new. It is the same discipline that separates a shipped product from a prototype, a governed system from a system you hope will work. The Google announcement names the layers. The discipline that runs those layers is still yours.