← ALL EXPERIMENTS / adk-enterprise-agent-platform
ADK 2.0 Enterprise Agent Platform
LANGUAGE / STACK: Go LIVE

ADK 2.0 Enterprise Agent Platform

Four Go agent microservices, one router, and a construction workflow that inspects and repairs its own work — streamed live over SSE.

OVERVIEW

The ADK 2.0 Enterprise Agent Platform is a reference implementation of a multi-agent system built entirely in Go on Google's Agent Development Kit 2.0 (google.golang.org/adk/v2 v2.1.0). Rather than one binary holding every agent, the platform is a single Go module with four cmd/ entry points that compile into four independently deployable Cloud Run services: a master router, a construction orchestrator, a weather agent, and a time agent. The router is the public face — it serves an embedded single-file Command Center UI on / and reverse-proxies /api/ to an ADK launcher API server bound to loopback on port 8081, so the UI and the agent REST API share one origin with no CORS configuration and no second deployment. Its root chat_agent is an llmagent whose routing instruction is generated at runtime from a thread-safe in-process registry: sub-agent packages register themselves in init(), the router blank-imports them for that side effect alone, and registry.All(model) hands the composed sub-agents to the LLM for transfer-based routing, with Google Search as the fallback when no sub-agent fits. The flagship workload is a construction simulation where an orchestrator drives five trade sub-agents through a build in strict order, with a deterministic inspector gate between every phase that can send work back for repair — and the UI renders it as it happens, consuming ADK's server-sent event stream and mapping each functionCall and functionResponse onto stage cards, a per-phase thought stream, and an inspector audit drawer. Because a live run invokes Gemini and costs real money, the public deployment at adk.jking.ai meters runs per visitor behind a Cloudflare edge and falls back to a free simulated pipeline once a visitor's quota is spent. All four services share the same model configuration — gemini-flash-latest via Vertex AI with Application Default Credentials, or Google AI Studio when an API key is present — and export OpenTelemetry spans to Cloud Trace and Cloud Logging.

THE PROBLEM

Most agent demos are one process: a single binary with every tool and sub-agent compiled in, run locally against an API key. That shape stops working the moment an agent platform has to behave like enterprise software. Different agents have different scaling profiles, dependency footprints, failure domains, and release cadences, and one deployable forces them all to move together. A second problem scales with the first — an LLM orchestrating multi-step work will confidently report success on work it never verified. There is no equivalent of a building inspector to catch a defect mid-workflow and force a retry before the next step runs, so errors compound silently across a long chain of agent calls. A third appears the moment any of this reaches the public internet: every visitor who presses Start is spending your money, which turns an interesting demo into an open-ended bill unless the expensive paths are metered and the origin cannot be reached around the meter.

The platform is one Go module with four cmd/ entry points over a shared agents/ package tree, so agent logic is written once and deployed four ways. A single multi-stage Dockerfile takes an ARG SERVICE build argument and compiles ./cmd/$SERVICE, which means make deploy-all produces four Cloud Run services from identical source with no per-service build config. Sub-agent discovery avoids hard-wired wiring: each agent package calls registry.Register(name, description, factory) in its init(), the router blank-imports those packages purely for the side effect, and chat_agent derives both its sub-agent list and its routing instruction from whatever the registry reports — adding an agent to the router means adding one import line. The construction workload demonstrates the hierarchical pattern: construction_agent wraps five trade sub-agents plus an inspector as tools via agenttool.New(). That choice has a consequence worth knowing — sub-agents invoked as tools never emit their own top-level events, so every event on the wire is authored by construction_agent and the active phase has to be identified by tool name rather than event author. Each trade agent owns one typed functiontool whose input struct carries json and jsonschema tags, and a single action field flips it between construct and repair. The inspector is deliberately not an LLM judgement — inspect_phase is plain Go returning PASS or FIX on a 75/25 probability gate, and a FIX verdict blocks the phase until the same trade agent re-runs with action="repair" and re-inspection passes. The UI streams from /api/run_sse, where the streaming flag is a granularity control rather than an on/off switch: false yields roughly 27 complete step events per run, while true yields around 2,000 token-level partials that are never persisted to the session — invisible in the trace UI while flooding a live client. Since this UI paints discrete phases rather than streaming prose, it sends false and gets exactly the functionCall and functionResponse events the stage-card mapping needs. Hardening the public demo took three pieces: a two-tier per-IP quota — a token bucket for bursts plus a daily cap that resets at UTC midnight — applied only to the run endpoints, so the page still works once the quota is spent; client identity resolved from the rightmost X-Forwarded-For entry rather than the attacker-controlled leftmost one, or from CF-Connecting-IP when Cloudflare fronts every request; and a shared secret injected by a Cloudflare Transform Rule that metered endpoints require, so the bare Cloud Run origin cannot be used to route around the meter. The counter lives in process memory, so the router deploys with --max-instances 1 — right for a demo, and a hard ceiling on cost.

Distributed Microservice Architecture

How one Go module deploys as four independent agent microservices behind a metered public edge

Distributed Microservice Architecture CLICK TO ENLARGE
Construction Workflow & Inspector Gate

How a build request runs five trade sub-agents through an automatic inspect-and-repair loop

Construction Workflow & Inspector Gate CLICK TO ENLARGE
High EFFORT
code_blocks

Go 1.26

One Module, Four Binaries

hub

ADK v2.1

google.golang.org/adk/v2

auto_awesome

gemini-flash-latest

Vertex AI + AI Studio Fallback

account_tree

Agent Registry

init() Sub-Agent Discovery

build

agenttool + functiontool

Typed Tool Contracts

stream

SSE Event Stream

/api/run_sse, Step Granularity

speed

Per-IP Demo Quota

Token Bucket + Daily Cap

shield

Cloudflare + Cloud Run

Edge Auth, Scale-to-Zero

[DISTRIBUTED MICROSERVICES][COMPILE-TIME AGENT REGISTRY][HIERARCHICAL SUB-AGENTS][SELF-HEALING REPAIR LOOP][DETERMINISTIC QUALITY GATE][LIVE SSE TELEMETRY][PER-IP DEMO QUOTA][EDGE-AUTHENTICATED ORIGIN][DISTRIBUTED TRACING][SCALE-TO-ZERO DEPLOY]