Google Agents CLI Extensions: Run LangChain Without Forking Your Toolchain

Google's Agents CLI is no longer tied to a single agent framework. On October 21, 2026, Google introduced an extension system that lets teams replace selected lifecycle commands, add new commands, and ship coding-agent skills without maintaining a fork. The first-party LangChain template shows the idea in practice: scaffold a LangChain or LangGraph agent, run and evaluate it through familiar agents-cli commands, then deploy through the native Google Cloud path.

This guide separates Google's documented behavior from Rubic8's implementation recommendations. It also uses the current template reference from the official documentation, v1.11.0. Google's announcement demonstrated v1.8.0; copying that launch-day command today would unnecessarily pin an older release.

What Google announced

The October 21 announcement describes an Extension System that began in Agents CLI v1.5.0 and added a first-party LangChain extension in v1.8.0. Google marked the system experimental at that point and advised teams to pin the CLI version because the command surface and manifest schema could still change before stabilization.

Extensions can override selected built-in commands such as create, run, deploy, or eval generate. They can also add entirely new commands and install skill folders that coding agents can read. The important architectural decision is selective replacement: an extension does not need to reimplement the whole lifecycle.

The first-party LangChain template, for example, overrides the framework-coupled parts. It runs the graph in process for run, uses LangGraph's local server for the playground, and produces the standard evaluation dataset shape for eval generate. Framework-neutral commands such as deploy, infra, and eval grade remain native.

Why extensions are more useful than a permanent fork

A fork can solve the same immediate problem, but it creates an ongoing merge and security-review burden. An extension narrows the customization boundary to a manifest, a few scripts, and optional skills. That makes the difference between Google's behavior and your organization's policy visible in code review.

Rubic8 recommendation: start with a project-scoped extension. Move to a fork only if you can name a required change that cannot be expressed as a command override, added command, skill, or wrapper. This is an engineering recommendation, not a performance claim; Google has not published benchmark data comparing the approaches.

How the extension contract works

An extension is described by agents-cli-extension.yaml. A command maps to a run: vector, which Agents CLI executes directly without a shell and with the user's arguments appended. A project-root manifest is automatically loaded at project scope. A reusable extension can instead live in a Git repository and be added by shorthand, an org/repo reference, a named extension fragment, or a local path.

schema: agents-cli-extension/v1alpha1
name: release-policy
description: Run a supply-chain check before deployment.
requires:
  agents_cli: ">=1.11,<2"
  on_incompatible: error
commands:
  override:
    deploy:
      run: ["uv", "run", "scripts/checked_deploy.py"]
      description: Verify the SBOM, then run the native deploy.

The manifest can declare a supported Agents CLI range. With on_incompatible: error, add or update refuses an out-of-range extension. With warn, installation continues but surfaces the mismatch. Because the schema remains labeled v1alpha1, treat the compatibility declaration and a pinned CLI version as operational controls, not optional documentation.

Project scope, user scope, and conflicts

Project scope is the default. Its extension list is stored in the repository, and the working copy is vendored under extensions/. User scope, selected with --global, applies across projects and is mainly useful when an override must exist before a project is created. If both scopes claim the same command, project scope wins. agents-cli info and agents-cli extension list expose the active source and conflicts.

That visibility matters for incident response. A developer should be able to answer three questions before executing an unfamiliar command: which extension owns it, which commit is running, and whether the override is project-wide or machine-wide.

Trust and lockfile-style pinning

Google's documentation is explicit that repository extensions can execute arbitrary code. First-party shorthand references are trusted automatically, while a typed org/repo reference prompts for trust. The --yes flag bypasses that prompt and should be reserved for reviewed automation.

On add, Agents CLI resolves the requested branch, tag, or SHA to an exact commit, records it in agents-cli-extensions.yaml, and vendors the working copy. agents-cli install restores the pinned code without advancing it. agents-cli extension update is the deliberate action that advances a tracked reference and re-prompts for third-party trust.

Rubic8 recommendation: commit the extension list and vendored copy, require review for pin changes, and run agents-cli install in CI. Do not let a floating branch update as a side effect of a deployment.

Run a LangChain agent through Agents CLI

The official project currently lists Python 3.11+, uv, and Node.js as prerequisites. Google's launch walkthrough also uses the Google Cloud SDK for Cloud Run deployment. Local development can use a Google AI Studio key; cloud deployment and managed services require a Google Cloud project and may incur the underlying service charges. The official sources do not advertise a separate paid Agents CLI plan.

1. Install and authenticate

uvx google-agents-cli setup

# For Google Cloud and Cloud Run workflows
gcloud auth application-default login
gcloud config set project YOUR_PROJECT_ID
gcloud services enable aiplatform.googleapis.com run.googleapis.com artifactregistry.googleapis.com

For a purely local AI Studio workflow, use the API-key path documented by Google instead of assuming Application Default Credentials. Keep credentials in a local environment file or secret manager; never commit them with the extension manifest.

2. Scaffold the current LangChain template

agents-cli create my-agent --agent google/agents-cli/extensions/langchain/template@v1.11.0 -d cloud_run
cd my-agent
agents-cli install
agents-cli info

The resulting project includes an auto-loaded project-scope extension manifest, a standard Agents CLI project manifest, langgraph.json, application code, evaluation fixtures, infrastructure files, and a dependency lockfile. The default agent is a Gemini ReAct agent built with LangChain's create_agent, which compiles to a LangGraph graph. The template does not depend on google-adk.

Run agents-cli info immediately after scaffolding. Confirm that the expected commands are overridden, record the CLI and template versions in the pull request, and inspect the generated code before introducing proprietary tools or data.

3. Run, evaluate, and deploy

agents-cli run "Summarize the release checklist"

agents-cli eval generate --dataset tests/eval/datasets/basic-dataset.json -o tests/eval/output/

agents-cli eval grade --traces tests/eval/output/<dataset>.json --config tests/eval/eval_config.yaml

agents-cli deploy

The first-party extension replaces run and eval generate with LangChain-aware implementations. Grading remains the native, framework-neutral command. Deployment also stays native; for the Cloud Run target, the container serves the agent over the Agent2Agent protocol through a FastAPI entry point.

There are documented limits. Some operations that depend on ADK behavior are refused with an explanation. On Agent Runtime, integrations that expect ADK routes do not work for this A2A-served project, although traces can still reach Cloud Trace. Test the exact target and console workflow you plan to use before standardizing the template.

Add a supply-chain gate before deployment

The extension system is also useful when your framework is already supported. A deployment override can generate an SBOM, scan it, enforce an allowlist, and then call the built-in deploy only if policy passes.

# scripts/checked_deploy.py — simplified control flow
generate_sbom(output="build/sbom.cdx.json")
scan_for_disallowed_components("build/sbom.cdx.json")
run(["agents-cli", "deploy", *sys.argv[1:]], check=True)

Agents CLI sets AGENTS_CLI_DISABLE_OVERRIDES=1 while an override runs. Therefore, the nested agents-cli deploy call reaches the built-in implementation instead of recursively invoking the wrapper. The authoring guide recommends putting multi-step logic in a wrapper because the manifest accepts a single command vector, not a shell pipeline.

When you need to inspect a sanitized CycloneDX JSON file, Rubic8's JSON Validator can catch syntax errors and the JSON Formatter can make a compact artifact easier to review. Do not paste private package inventories, internal repository paths, credentials, or customer data into any online tool. Validate sensitive SBOMs locally or inside CI.

A practical adoption checklist

1. Pin both layers. Pin the Agents CLI version and reference a reviewed extension tag or SHA.
2. Prefer project scope. Use global scope only when the override must exist before project creation.
3. Inspect ownership. Run agents-cli info and agents-cli extension list in CI logs.
4. Review executable code. Treat manifests, wrapper scripts, copied skills, and generated templates as code, not configuration-only metadata.
5. Protect secrets. Keep API keys and cloud credentials out of manifests, prompts, logs, evaluation datasets, and browser-based utilities.
6. Test refusals. Verify that unsupported commands fail clearly and that a failed policy check prevents deployment.
7. Control updates. Make extension pin changes reviewable pull requests; do not run blanket update commands in production jobs.
8. Start with one service. Measure upgrade effort, developer friction, and failure recovery before rolling the pattern across a platform.

When this pattern is a good fit

Use the extension approach when you want a common lifecycle across LangChain, LangGraph, Deep Agents, or an internal framework; when platform engineering needs to enforce deploy policy; or when a team wants a native-feeling command without changing upstream Agents CLI.

Do not adopt it only to rename a command, hide an undocumented script, or bypass the normal trust prompt. If the workflow is a simple CI step, keeping it in the pipeline may be clearer. If the required change reaches deeply into CLI internals, document the gap and evaluate whether an upstream contribution or a maintained fork is more honest.

Final take

The important part of Google's October update is not merely that Agents CLI can run LangChain. It is that framework-specific behavior and organization-specific policy can now live behind a small, inspectable boundary while the rest of the lifecycle remains upstream. Exact commit pinning, explicit scopes, compatibility declarations, and native-command fallbacks make the model practical—but the system is still evolving, so disciplined versioning and review are essential.

Official sources

• Google Developers Blog: Powering the Agent Development Lifecycle with any framework, from ADK to LangChain and beyond — October 21, 2026.
• Agents CLI documentation: Using Extensions.
• Agents CLI documentation: Authoring Extensions.
• Agents CLI documentation: First-party frameworks.
• google/agents-cli on GitHub.