The repository is a shelf of recipes, not one agent
adk-samples separates curated core recipes from broader community contributions under contrib. The root README points to examples for OAuth, session memory, guardrails, retrieval, research, and industry workflows. Each recipe is meant to stand on its own with setup and run instructions. That structure works well when a developer knows the pattern they need. It is less useful as a single application architecture because neighboring recipes can make different choices about models, frontends, cloud services, evaluation, and deployment.
The collection currently leans heavily toward Python recipes, even though the root page links to ADK SDKs for Python, TypeScript, Go, Java, and Kotlin. One core example, deep search, combines an ADK and FastAPI backend with a React frontend, human approval of a research plan, repeated search and critique, and a final cited report. Another recipe may be only a small pattern. Read the target recipe, not the repository tagline, before estimating work.
Core and contrib carry different trust signals
The core directory contains canonical patterns curated by the agents-cli team. The README describes them as small recipes designed to teach one thing well. Community-contributed examples live under contrib and can cover a broader use case. That label is useful provenance, but neither group is a supported Google product. The root disclaimer says recipes are demonstrations and starting points, and they are not eligible for Google's open-source vulnerability rewards program.
Contribution rules are more disciplined than the word “samples” might suggest. A contributed recipe needs a manifest with real ownership, a README with setup and run sections, synchronized Python dependencies, declared environment variables, and a runnability test. The checklist caps a contrib recipe at 70 files and 2 MB, and CI validates structure. Three AI reviewers comment on critical or high-severity additions, while a human maintainer still approves changes. These controls improve incoming examples without turning them into maintained production services.
What happened when we ran it
Our commit 629310b checkout installed 40 packages in 13 seconds with Python 3.12 and used 41 MB on disk. The build succeeded in 5 seconds. Pip-audit reported 0 known vulnerabilities. The repository contained 3,181 files, about 342,181 lines of source, and 106.4 MB checked out. It also had 20 CI workflow files, no Dockerfile, and no tests directory, although pytest discovered a large suite elsewhere in the tree.
Tests finished after 8 seconds with exit code 1. Pytest reported 900 passed, 0 failed, and 9 collection or setup errors out of 909. Every listed error involved a missing tomlkit import in the recipe pyproject alignment or validation checks. This is a failed suite even though no executed test assertion failed. The log supports the missing-module finding; it does not establish whether the root dependency declaration, harness selection, or another setup layer should have supplied that package.
Nine setup errors make the root workflow incomplete
A collection can have excellent individual recipes and still be awkward to validate as one unit. Our run's 900 passing tests are a strong sign that much of the repository's tooling and examples execute in the sandbox. The 9 errors are equally relevant because they block a green root result before those checks run. A contributor touching recipe metadata should reproduce the same command with tomlkit available and confirm that all affected validators collect and execute.
The absence of a root Dockerfile matches the repository's structure. Some recipes have deployment material and others do not. The contribution checklist even makes container preparation an opt-in skill rather than a default part of recipe preparation. Treat each folder as a separate dependency and operations boundary. A passing root build in 5 seconds does not mean the deep-search frontend, Vertex AI authentication, vector store, or media workflow is configured.
Credentials and cloud services vary by recipe
The deep-search recipe can use a Google AI Studio API key for local work or Vertex AI with a Google Cloud project, location, and application-default login. Its custom frontend also needs Node.js, while cloud deployment uses Google tooling and, depending on the path, Identity-Aware Proxy. Other recipes cover RAG, cross-session memory, media generation, expense work, safety plugins, and retail search, each with a different service surface. There is no honest universal setup estimate beyond the root harness numbers.
This makes adk-samples useful for code discovery and risky as a copy-without-reading source. Before adopting a recipe, list every environment variable, external API, cloud resource, model, data source, callback URL, and user-visible action. Then decide how failures and costs are bounded. Agent examples often work with powerful credentials, and a demonstration's permissive assumptions may be wrong for real customer data or autonomous actions.
Production ownership starts after the fork
Google's disclaimer is unusually direct: the collection is illustrative, unsupported, and not intended to be deployed unchanged. A fork needs threat modeling, prompt and tool tests, secret storage, authorization, logs, rate limits, budget controls, data-retention rules, and a deployment plan appropriate to the chosen recipe. Human approval shown in one research example does not automatically appear in another workflow. Safeguards must be traced through the actual agent code and every tool it can call.
Health signals are current. GitHub reported 10,240 stars, 78 open issues and pull requests, an Apache 2.0 license, and an August 26, 2026 push. There was no latest GitHub release, which is unsurprising for a recipe collection but means commit pinning matters. ADK Python is the better source for framework behavior, while LangGraph and AutoGen are worthwhile comparisons when the project is not committed to Google's stack. Use adk-samples to shorten exploration. Keep the resulting production system under your own engineering standards.