# Agent Starter Pack: Google Cloud agent templates now in maintenance mode

> Agent Starter Pack scaffolds ADK, LangGraph and RAG agent projects with Terraform, CI/CD and evaluation wired in. The README now points new work at agents-cli, which changes who should still use it.

**GoogleCloudPlatform/agent-starter-pack** — Ship AI Agents to Google Cloud in minutes, not months. Production-ready templates with built-in CI/CD, evaluation, and observability.

- Repository: https://github.com/GoogleCloudPlatform/agent-starter-pack
- Website: http://goo.gle/agents-cli
- Stars: 6,562 · Forks: 1,501
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/googlecloudplatform-agent-starter-pack

## What Agent Starter Pack actually generates

The project is a CLI that bootstraps a complete Google Cloud GenAI agent repository. The pyproject.toml describes it as a "CLI to bootstrap production-ready Google Cloud GenAI agent projects from templates," and the README frames the pitch as focusing on agent logic while the pack supplies infrastructure, CI/CD, observability and security. That is the real scope: you are not getting an agent framework, you are getting the scaffolding around one.

The audience is narrow and specific. Teams that have already decided to run agents on Google Cloud and want a deployable skeleton rather than a notebook. If you are still comparing frameworks, the template list is a poor way to do it, because each template commits you to a particular runtime and a particular deployment story. The pack is for the moment after the framework decision, when the remaining work is Terraform, a Dockerfile, an evaluation harness and a CI pipeline that nobody wants to write twice.

## The template catalogue and what each one commits you to

The README lists six agents: adk, a base ReAct agent on Google's Agent Development Kit; adk_a2a, which adds Agent2Agent protocol support for distributed agent communication; agentic_rag, for document retrieval and Q&A over Vertex AI Search or Vector Search; langgraph, a ReAct agent on LangChain's LangGraph; adk_java, the same ReAct pattern in ADK for Java; and adk_live, a real-time multimodal agent supporting audio, video and text chat.

The choices are not cosmetic. Picking adk_a2a means you are building for inter-agent interoperability, which only pays off if something else on the other side speaks the protocol. Picking agentic_rag means your retrieval layer is bound to Vertex AI Search or Vector Search, and swapping it later is your problem. Picking adk_live means a streaming, multimodal surface that is harder to evaluate with the same harness as a request-response agent. The README does not document per-template evaluation differences, so treat that as unverified until you read the template source under agent_starter_pack/agents/.

## Installing Agent Starter Pack and creating a first project

The README gives a uv path and a pip path. The uv route needs no prior install because uvx resolves the package on the fly. Running it drops you into an interactive prompt that asks which template and configuration you want, and the result is a project directory with backend, frontend and deployment infrastructure.

```bash
uvx agent-starter-pack create
```

If uv is not available, the README's alternative is a virtual environment plus pip. Note that the package requires Python 3.10 or newer per pyproject.toml, so an older interpreter will fail at install time rather than at runtime.

```bash
python -m venv .venv && source .venv/bin/activate
pip install --upgrade agent-starter-pack
agent-starter-pack create
```

The second entry point is for code you already have. Run it from your project root and it layers the deployment and infrastructure pieces onto the existing layout rather than generating a new agent.

```bash
uvx agent-starter-pack enhance
```

After either command the README says you have a functional agent project ready to customize. What it does not give is a first-run verification step: there is no documented command that proves the generated project builds and deploys end to end before you start editing it. The Makefile in the repository targets the pack's own test suite, not your generated project, so do not read make test as a check on your new agent.

## Maintenance mode is the headline constraint

The README opens with a maintenance notice. Active development has moved to agents-cli, and Agent Starter Pack "will continue to receive critical fixes only" with no new features, no new templates and no new deployment targets. The last push to the repository was on 2026-07-21, so the code is not abandoned, but the direction of travel is explicit in the project's own documentation.

The migration claim is that agent code, tests, Terraform and CI/CD carry over with no rewrites, and the README says migration takes minutes. That is a vendor claim in a README, not an independently verified result, and the honest reading is that it holds for projects that stayed close to the generated structure. If you have heavily modified the Terraform or replaced the CI pipeline, the carry-over promise is worth testing on a branch before you trust it.

The practical consequence: any new template you want, any new deployment target, and any improvement to the CLI itself lands in agents-cli. Bug reports against the pack will get critical fixes at best. For a project you plan to run for two years, that is the deciding factor, not the template list.

## The Makefile, the test suite and what CI/CD means here

The repository's Makefile exposes test, test-templated-agents, test-e2e, lint, install, generate-lock and clean. The interesting one is test-e2e, which sources tests/cicd/.env before running tests/cicd/test_e2e_deployment.py. That tells you the pack's own deployment tests depend on environment configuration you supply, which is consistent with a project that generates infrastructure rather than running a hosted service.

install runs uv sync --dev --extra lint --frozen, so the repository pins its dependency graph through uv.lock and expects reproducible installs. generate-lock regenerates those locks. If you fork the pack to add your own template, you are taking on that lock regeneration step plus the templated-agent linting in tests/integration/test_template_linting.py. That is a real cost, and it is the part people underestimate when they decide to maintain an internal fork instead of migrating.

The lint configuration in pyproject.toml excludes the agent templates themselves from ruff, covering only agent_starter_pack/cli and tests. Generated agent code is not held to the same style rules as the CLI, which is a reasonable split but worth knowing if you were expecting the templates to model lint-clean Python.

## Where it is the wrong tool, and what to compare it against

This is the wrong tool if you are not deploying to Google Cloud. The templates target Cloud Run and Agent Engine, the evaluation path runs through Vertex AI, and the observability guidance is written for Google Cloud's monitoring. Running the generated project on another cloud means rewriting the infrastructure layer, at which point the pack has saved you very little.

It is also the wrong tool if you want a framework rather than scaffolding. LangGraph, the Agent Development Kit and the A2A protocol each have their own repositories and documentation, and the pack does not replace them; it wraps them. If your question is which agent architecture to use, the pack answers a different question.

The real alternative is agents-cli, and the difference is not cosmetic. The README describes a unified CLI replacing the Makefile, with run, deploy, eval run, eval compare, playground and lint subcommands; bundled coding-agent skills for Claude Code, Gemini CLI or Codex; end-to-end lifecycle tooling from scaffold to observe; and first-class support for Google Cloud's Agent Platform. The pack's Makefile-driven workflow and its Cloud Run or Agent Engine targets are the older arrangement. Choosing the pack today means choosing the older arrangement deliberately.

## Licence and the cost of staying

The project is Apache-2.0, declared in both pyproject.toml and the LICENSE file at the repository root. That permits commercial use, modification and redistribution, with the usual obligations around preserving notices and stating changes. It does not give you any warranty, and it does not oblige Google to keep publishing fixes. Since the README states the project receives critical fixes only, the licence's permissive terms matter more than usual: you can fork and maintain the templates yourself if a fix never arrives.

Upgrade cost is the part to price honestly. The pack pins Python 3.10 or newer and depends on click, cookiecutter, google-cloud-aiplatform, rich, pyyaml, backoff, tomli on older Pythons, and requests. Releasing v0.41.1, v0.41.2 and v0.41.3 within ten days in April 2026 suggests the release cadence was fast while development was active. Whether that cadence continues under maintenance mode is not stated anywhere in the project's documentation. If your team depends on a template that later needs a fix, you are the maintainer now.

## Conclusion

Use Agent Starter Pack if you need a working ADK, LangGraph or agentic RAG project skeleton today and you accept that only critical fixes arrive, since the last push was on 2026-07-21 and the README states there will be no new features, templates or deployment targets. Do not start a greenfield project here if you want the unified CLI, bundled coding-agent skills or Agent Platform support described in the migration notice; run uvx google-agents-cli setup instead. Before committing, verify that the template you pick still matches the services you deploy to, and read the migration guide at google.github.io/agents-cli/reference/from-agent-starter-pack/ to confirm your agent code, tests, Terraform and CI/CD carry over without rewrites.

## FAQ

### What is agent starter pack?

It is a Python CLI that bootstraps production-ready Google Cloud GenAI agent projects from templates, described in pyproject.toml as a "CLI to bootstrap production-ready Google Cloud GenAI agent projects from templates." It supplies infrastructure, CI/CD, observability and security around agent code you write yourself.

### What exactly is a starter pack?

In this project's case, a starter pack is a template bundle plus a generator: you run the CLI, answer its prompts, and get a project directory with backend, frontend and deployment infrastructure. The README lists six agent templates including adk, langgraph and agentic_rag.

### Is it a starter kit or starter pack?

The project calls itself Agent Starter Pack, and the package name on PyPI is agent-starter-pack. The README uses the words interchangeably when describing what you get, but the command and package names are the ones to use.

### What are some examples of starter packs?

The README names its own templates as examples: adk, adk_a2a, agentic_rag, langgraph, adk_java and adk_live. It also points to the separate ADK Samples repository for additional ADK examples and use cases.

## Sources

- [GoogleCloudPlatform/agent-starter-pack on GitHub](https://github.com/GoogleCloudPlatform/agent-starter-pack)
- [License: Apache-2.0](https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/main/LICENSE)
- [Project website](http://goo.gle/agents-cli)
- [README](https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/main/README.md)
- [Releases](https://github.com/GoogleCloudPlatform/agent-starter-pack/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlecloudplatform-agent-starter-pack