Three layers, one repo: a tour of google/adk-recipes Google restructured its ADK sample content into a single repository, google/adk-recipes, splitting it into three top-level folders: core/ for reference patterns curated by the Agents CLI and DevRel teams, plugins/ for installable vertical skills packaged as Plugin Recipes conforming to the Agent Plugins v1.0.0 spec, and contrib/ for end-to-end deployable services across five languages. Every recipe ships a validated manifest.yaml, an AGENTS.md written primarily for AI coding assistants, and for contrib/ and plugins/ a Dockerfile plus a runnability test, with CI enforcing the standards on every PR. The repo is the single source of truth for ADK content consumed by Agents CLI, Agent Garden, and Google Cloud infrastructure components including Agent Platform Sandboxes, Memory Bank, Vector Search 2.0, and Veo 3.1 Reference-to-Video. A developer building on Google Cloud today can scaffold a long-horizon memory agent from the terminal, install a retail vertical skill into a coding assistant with one line, and deploy a fully-wired production service to Cloud Run, Agent Runtime, Agent Garden, or Gemini Enterprise app — all from the same curated source tree. That tree is google/adk-recipes , the restructured successor to google/adk-samples that now serves Agent Platform from a single source of truth. ADK recipes are agent-friendly: we've made it easy for your agents to 1 discover relevant recipes for various agent use cases, and 2 install and use them automatically from your favorite harness. google/adk-recipes splits its content into three top-level folders: core/ for reference patterns curated by the Agents CLI and DevRel teams, plugins/ for installable vertical skills packaged as Plugin Recipes conforming to the Agent Plugins v1.0.0 spec, and contrib/ for end-to-end deployable services across five languages. Every piece has been designed with machine readability as the primary consideration. What follows is a walkthrough of the repository https://github.com/google/adk-recipes/tree/main/ 's shape, three worked examples one per layer , and a reflection on what the new structure enables. Three top-level roots, each anchored on one reader action: Every recipe ships a validated manifest.yaml , an AGENTS.md that tells the coding assistant opening it what the recipe is and how to use it, and for contrib/ and plugins/ a Dockerfile plus a runnability test. CI enforces the standards on every PR, and a suite of coding-assistant skills in the repo prepare-python-recipe , generate-manifest , github-pr-review , and others does most of the preparation, so your agent can scaffold, validate, and submit a recipe end-to-end. Every AGENTS.md , every manifest.yaml , every SKILL.md is written primarily for the AI coding assistant that will open the repo on your behalf; README.md files are what humans still read. The handbook glossary captures the dual framing: "Recipe — a runnable agent example or importable agent module under core/ , contrib/ , or plugins/ , consumed by ADK developers and coding agents alike." adk-recipes serves as the single source of truth for ADK content across the three Agent Platform surfaces that consume it. Each reads the repository through its own protocol. Agents CLI reads core/ . When a developer runs uvx --from google-agents-cli agents-cli create my-agent , Agents CLI can scaffold on demand a core/ recipe. The CLI, launched earlier this year at Google Cloud Next, exposes the full scaffold → deploy → evaluate → publish lifecycle; the base content it serves comes from our recipes. Horizon, the reference harness we examine below, is an example pattern Agents CLI treats as a production template. Agent Garden features a curated selection. The developer-facing path into the repository is a pull request to contrib/ : a recipe lands in GitHub, becomes part of the public ADK ecosystem, and from that moment is discoverable by other developers and by coding assistants reading the repository. Appearing in the Agent Garden gallery is a separate editorial decision made by the Agent Garden team, which curates a subset of recipes and promotes them to the public catalog on their own cadence. Once an agent is in the gallery, any developer in a Google Cloud project gets a one-click install. Beyond these primary surfaces, Google Cloud's own infrastructure components appear as building blocks inside the recipes themselves. Horizon uses Agent Platform Sandboxes for per-user sandboxing, Memory Bank for durable memory, and Agent Platform Sessions for session state. The retail product-search Plugin Recipe uses Vector Search 2.0 on Gemini Enterprise Agent Platform paired with BigQuery. The retail virtual-tryon Plugin Recipe uses Gemini image models for still composites and Veo 3.1 Reference-to-Video for animated outputs. The recipes do not just live alongside Agent Platform; they document it in use. For developers working with coding assistants outside Google Cloud's tooling Claude Code, Antigravity, Cursor, Windsurf, Zed, and others , Plugin Recipes additionally install through the open npx skills CLI maintained by vercel-labs. core/ Building an agent that can handle a single conversation is a well-understood problem. Building one that holds its own across days of interaction, remembering what the user did yesterday and planning tasks for tomorrow, is a materially different undertaking. The hard parts of such a long-horizon system are the same regardless of what the agent is being built to do: cross-session memory, per-user sandboxing of tool execution, secrets management, guardrails against runaway behaviour, and the orchestration primitives that make multi-step tasks resumable. Horizon, which lives at core/python/long-horizon-harness , is the reference harness we built to collect these primitives in one place. The shortest path from a fresh clone to a running Horizon instance: uvx google-agents-cli setup gcloud auth application-default login gcloud config set project YOUR PROJECT ID gcloud services enable aiplatform.googleapis.com git clone --depth 1 --filter=blob:none --sparse https://github.com/google/adk-recipes.git cd adk-recipes git sparse-checkout set core/python/long-horizon-harness cd core/python/long-horizon-harness Default: LHA ENVIRONMENT BACKEND=local, in-memory sessions, no cloud deploys needed make dev-local make deploy rolls the backend to Cloud Run through Terraform; make destroy tears it back down. Horizon's evaluation suite lives in tests/eval/evalsets/ as eighteen named behavioural rubrics covering memory recall, injection-based exfiltration attempts, guardrail halting under adversarial input, tool-selection discipline, and a journey-level plot-artifact evaluation. The rubrics are executed with uv run pytest tests/eval . A first chat turn against the running backend confirms the memory layer is wired correctly: Horizon is the harness we give coding assistants to study before building something harder. When a developer asks their assistant to build an agent that must run across days of interaction, the right next step is uvx google-agents-cli create with Horizon as the scaffold, and the rest of the harness falls into place. Horizon encodes a reference pattern. It does not encode a vertical. For that, the second layer of the repository holds Plugin Recipes, each addressing a specific industry domain. The first vertical fully covered in this launch is retail, available under plugins/retail/ . The Plugin Recipe format sits on top of the Agent Plugins v1.0.0 specification published at agent-plugins.org https://agent-plugins.org/specification , an open standard for packaging installable AI skills across coding assistants. The specification defines a plugin as a bundle of one or more skills with a top-level plugin.json manifest declaring name, version, license, and ownership. Each skill is a self-contained folder with a SKILL.md conversational installer, a README.md , an EVAL.yaml of quality gates, and the scripts and assets the skill needs to do its work. The retail plugin's layout is: plugins/retail/ ├── plugin.json └── skills/ ├── product-search/ │ ├── SKILL.md Q-MODE conversational installer │ ├── README.md │ ├── EVAL.yaml LLM-as-judge rubrics + deterministic assertions │ ├── scripts/ │ ├── references/ │ └── assets/ └── virtual-tryon/ └── ... Two skills ship in this plugin today. The first, retail-product-search , builds an ADK agent with a vector-search retrieval tool backed by Vector Search 2.0 on the Gemini Enterprise Agent Platform and a BigQuery catalog. The skill handles the entire pipeline: ingesting a CSV or JSON catalog into BigQuery, generating multimodal and text embeddings with Vertex AI Embeddings, building the Vector Search collection, scaffolding the ADK agent with a retrieve docs tool, and deploying to Cloud Run. The agent is deliberately single-agent: one root agent with one retrieval tool and no coordinator layer. The semantic complexity sits in the retrieval pipeline and the evaluator rubric, not in agent-to-agent communication; adding orchestration layers would obscure the pattern rather than clarify it. The second skill, retail-virtual-tryon , generates a photorealistic composite of a model wearing or holding a product, with an optional eight-second studio catwalk video on top. It uses gemini-2.5-flash-image by default, falling back to gemini-2.5-pro-image when editorial quality matters more than latency. For video it uses veo-3.1-generate-001 in Reference-to-Video mode, conditioning the generated motion on the still produced by the image pipeline. The skill ships a pre-flight product-cutout classifier and configurable safety levels, operational details that become obvious after the third real production deployment. Both skills install into any coding assistant that reads skills with a single command: From Antigravity, Claude Code, Codex, Cursor … npx skills add google/adk-recipes --skill retail-product-search --full-depth npx skills add google/adk-recipes --skill retail-virtual-tryon --full-depth The --full-depth flag instructs the CLI to walk past its default top-level lookup and discover the nested plugins/retail/skills/ structure. The install lands in ~/.agents/skills/