Google launches Agents CLI Extension System for LangChain, LangGraph and custom AI agents
Google has detailed an extension architecture for Agents CLI that allows developers to build, run, evaluate and deploy AI agents using frameworks other than Google's Agent Development Kit (ADK), without abandoning the surrounding Google Cloud development workflow.
The technical walkthrough, published October 21, 2026, demonstrates a first-party LangChain project template and a custom deployment extension that performs a Software Bill of Materials (SBOM) vulnerability scan before invoking the native deployment command.
The Extension System itself was introduced in Agents CLI 1.5.0 on September 1, 2026. The October publication explains its operation through the LangChain integration in version 1.8.0, rather than announcing the original release.
Extensions replace framework-dependent commands while preserving infrastructure and deployment operations. Google's example intercepts deployment, uses Syft and Grype to inspect dependencies and blocks deployment when configured severity thresholds are exceeded.
The Extension System is experimental; the LangChain integration has documented limitations, particularly on Agent Runtime. It is not a new AI model or a universal framework-independent runtime.
··········
THE DEVELOPMENT PROBLEM GOOGLE IS ADDRESSING.
Agents CLI was introduced at Google Cloud Next 2026 as a command-line interface for managing the agent development lifecycle, initially centered on ADK.
Developers could scaffold, run, configure, deploy and evaluate ADK projects through a unified workflow. However, commands invoking the agent or generating evaluation responses relied on ADK-specific application structures.
LangChain, LangGraph and proprietary frameworks could not automatically reuse those execution commands. By contrast, provisioning infrastructure, deploying containers and analyzing standardized evaluation results need not depend on the underlying framework.
Google's Extension System lets projects replace individual framework-dependent commands without maintaining a fork of the whole CLI. It reduces coupling, but does not erase differences between frameworks or deployment targets.
........
Concern | ADK-centered | Extensions |
Implementation | ADK conventions | ADK or custom |
Local run | Native ADK | Override |
Evaluation generation | ADK execution | Adapter |
Infrastructure | Native | Preserved |
Deployment | Native | Preserved |
........
··········
THE EXTENSION SYSTEM WAS INTRODUCED BEFORE THE OCTOBER ANNOUNCEMENT.
Official Agents CLI release notes identify version 1.5.0, dated September 1, 2026, as introducing the Extension System, including custom commands, agent templates and a LangChain extension.
The October 21 technical walkthrough uses version 1.8.0 to explain the architecture and demonstrate a first-party LangChain project and deployment-policy extension.
The publication date and original release date describe distinct milestones. Developers reproducing the example should use the pinned template and documentation corresponding to their selected CLI release.
........
Milestone | Detail |
Initial introduction | Agents CLI 1.5.0 |
Release date | September 1, 2026 |
Walkthrough | October 21, 2026 |
Template version | 1.8.0 |
Status | Experimental |
........
··········
HOW AGENTS CLI EXTENSIONS ARE STRUCTURED.
An extension is a directory with an agents-cli-extension.yaml manifest defining its name, schema, compatibility constraints and command mappings.
Command overrides replace an existing command implementation while preserving its user-facing name. Command additions introduce new commands. Both mechanisms can coexist within one extension.
A platform team could override deploy to enforce a vulnerability scan and add sbom-report to produce an inventory independently. Extensions are distributed as source through Git, including repositories containing multiple addressable extensions.
This fits existing review and access-control workflows, but makes installation an executable software supply-chain decision rather than a harmless configuration change.
··········
COMMAND OVERRIDES AND NEW COMMANDS USE THE SAME MANIFEST.
Google's October example uses the agents-cli-extension/v1alpha1 schema. The requires section specifies CLI version compatibility and whether incompatibility triggers a warning or error.
The commands section maps existing or new CLI operations to executable command vectors. A run value is not an automatically interpreted shell script; sequential scanning and deployment steps belong in a wrapper script.
Google also documents overrides for specific subcommands, including eval.generate. Manifest validation is strict to reduce silent misconfiguration.
........
Manifest field | Purpose |
schema | Schema version |
name | Extension identifier |
requires | Compatibility |
commands.override | Replace commands |
commands.add | Add commands |
run | Executable vector |
........
··········
GIT DISTRIBUTION, VERSION PINNING AND REPRODUCIBILITY.
Extensions can be installed from Git repositories or local directories. Repository references can include a fragment selecting one extension from a repository containing several.
Google documents shorthand for first-party extensions, organization/repository references, and local references. Example commands include agents-cli extension add langchain and agents-cli extension add local@../my-extension.
Agents CLI resolves a Git reference to an exact commit SHA and records it in an extension lockfile. The source can be restored from that pinned commit rather than following a moving branch.
Running agents-cli install restores the pinned version. An explicit update operation resolves a newer commit. Teams should commit the lockfile and vendored extension source, and review changes before updating.
A lockfile protects reproducibility of extension code only when changes to the lockfile and scripts themselves are controlled.
··········
PROJECT AND USER SCOPES HAVE DIFFERENT EFFECTS.
Project-scoped extensions apply to a repository and are suitable for team-wide framework adapters and deployment rules. User-scoped extensions apply globally and can support bootstrap tooling.
Where both scopes define the same command, project scope takes precedence. CLI inspection commands reveal active extensions and command ownership.
A project-root agents-cli-extension.yaml may be loaded automatically without a separate trust prompt. Google warns developers to review such code before invoking commands in untrusted repositories.
A malicious repository could otherwise arrange for a familiar command to execute arbitrary scripts. Scope and precedence therefore affect security as well as convenience.
··········
THE FIRST-PARTY LANGCHAIN TEMPLATE DOES NOT REQUIRE ADK.
Google's first-party template creates a LangChain and LangGraph application, a FastAPI server, evaluation assets and an extension manifest without requiring google-adk.
The October walkthrough creates a project using the template google/agents-cli/extensions/langchain/template@v1.8.0 with -d cloud_run, then runs agents-cli install.
The project-root manifest activates framework-specific overrides. Developers do not need a separate global extension to create the template project.
The template establishes an integration pattern, not automatic compatibility for arbitrary Python agent code or every managed runtime feature.
··········
THE GENERATED PROJECT PRESERVES THE STANDARD DEPLOYMENT STRUCTURE.
The template contains agents-cli-extension.yaml, agents-cli-manifest.yaml, langgraph.json, pyproject.toml, Dockerfile, app/agent.py, app/fast_api_app.py, scripts for execution and evaluation, tests, deployment configuration and uv.lock.
The main agent exports a compiled LangGraph state graph. FastAPI exposes an Agent-to-Agent interface. Framework-specific commands are implemented through the extension manifest.
Infrastructure and container deployment remain reusable because the deployment operation depends on the service interface, image and target configuration rather than the internal graph.
A successful container deployment does not imply parity with managed features that expect ADK-specific routes or application behavior.
··········
LANGCHAIN, LANGGRAPH AND DEEP AGENTS SHARE A COMMON INTEGRATION PATH.
Google describes support for LangChain agents, LangGraph graphs and Deep Agents through the first-party template. Modern LangChain uses LangGraph for state management, providing a common compiled graph interface.
The generated example uses langchain.agents.create_agent and a Gemini-backed model, with the compiled state graph invoked by a framework-specific adapter.
Support remains bounded by the template, graph interface and target runtime. Specialized persistence, custom dependencies or nonstandard server behavior can require adaptation.
The existence of the template is not evidence that every feature of every framework is natively supported by Agents CLI.
··········
LOCAL EXECUTION AND EVALUATION REQUIRE FRAMEWORK-SPECIFIC ADAPTERS.
The LangChain template overrides operations that otherwise assume ADK. Its playground uses the LangGraph development server, run invokes the compiled graph, and eval generate produces responses for the shared evaluation pipeline.
Other evaluation operations can remain native when they consume standardized datasets or outputs rather than directly invoking ADK.
Some dataset synthesis and optimization workflows depend on ADK-specific execution and are refused by the LangChain integration. The CLI does not pretend unsupported operations work.
Version-specific command ownership should be checked against the pinned template's manifest rather than inferred from evolving online documentation.
........
Operation | LangChain behavior |
playground | LangGraph dev server |
run | Graph invocation |
eval generate | LangChain adapter |
eval grade | Native workflow |
infra | Native workflow |
deploy | Native workflow |
Some ADK-dependent features | Unsupported |
........
··········
CLOUD RUN DEPLOYMENT REUSES THE EXISTING AGENTS CLI PIPELINE.
The October walkthrough targets Cloud Run. The LangChain application is packaged as a container exposing the expected HTTP interface.
Native deployment can build and deploy the application without understanding the internal LangChain graph, preserving the surrounding infrastructure-as-code conventions.
This separates framework selection from selected operational tasks. It does not eliminate requirements imposed by each target's application interface.
··········
AGENT RUNTIME HAS IMPORTANT COMPATIBILITY LIMITATIONS.
Google distinguishes Cloud Run and GKE container deployment from Agent Runtime integrations. The LangChain template can serve its container and export traces on Agent Runtime, but some platform features expect an ADK application.
The template exposes an A2A interface rather than the ADK-specific reasoning_engine routes required by those features. The publish gemini workflow is refused for an incompatible Agent Runtime configuration.
The Google Cloud Console playground cannot invoke the agent through the unsupported interface, and expected Console session and trace views remain unavailable, although telemetry can reach Cloud Trace.
Organizations must verify whether their chosen target requires capabilities beyond container execution.
........
Capability | LangChain Agent Runtime |
Container execution | Supported |
A2A service | Available |
Cloud Trace | Exported |
ADK reasoning_engine routes | Unavailable |
Console playground | Limited |
publish gemini | Refused when incompatible |
........
··········
CUSTOM EXTENSIONS CAN ENFORCE ENTERPRISE DEPLOYMENT POLICY.
Google's second walkthrough example wraps the native deploy command with a security requirement instead of replacing a framework-specific execution path.
The sbom-deploy extension overrides deploy and adds sbom-report. Running agents-cli deploy generates a dependency inventory, scans it for vulnerabilities and proceeds only when the scan passes.
This creates a common policy step across projects without requiring every application team to maintain a separate script.
The mechanism can be adapted for other checks, but the demonstration does not establish that every conceivable policy is implemented or non-bypassable.
··········
THE SBOM WORKFLOW USES SYFT AND GRYPE.
A Software Bill of Materials identifies application components and dependencies. Google's example uses Syft to generate CycloneDX JSON and Grype to scan the inventory against known vulnerabilities.
The wrapper fails when Grype reports vulnerabilities meeting the configured critical-severity threshold. With set -euo pipefail, a failing scan stops the script before the final agents-cli deploy invocation.
The wrapper forwards the original deployment arguments so that developers can continue using the same command interface.
SBOM scanning does not guarantee complete supply-chain security. It can miss undisclosed vulnerabilities, components absent from the inventory or malicious behavior unrelated to known CVEs.
Production controls may additionally require container-image scanning, provenance attestations, secrets detection and policies for base images and runtime dependencies.
··········
HOW THE WRAPPER CALLS NATIVE DEPLOY WITHOUT RECURSION.
An overridden deploy command could otherwise call itself recursively when its wrapper invokes agents-cli deploy.
Google's loader sets AGENTS_CLI_DISABLE_OVERRIDES=1 while invoking the override script. The nested deployment call therefore reaches the native implementation.
This lets the extension own the policy check while the CLI retains the underlying deployment logic.
The same ability to bypass overrides for debugging means local command wrapping is not an unavoidable enterprise enforcement boundary. Mandatory checks should also exist in CI/CD or server-side deployment authorization.
··········
VERSION LOCKING HELPS PREVENT UNREVIEWED EXTENSION CHANGES.
A Git commit SHA recorded in the extension lockfile allows developers and CI systems to restore reviewed code without silently advancing to a newer branch revision.
However, pinning extension code does not pin every executable it invokes. Google's example depends on Syft, Grype and vulnerability databases whose versions and contents may change.
An identical source tree can pass one day and fail after new advisories become available. Organizations should document tool versions and update policies.
Reproducibility of extension code and reproducibility of external security data are related but distinct.
··········
SECURITY RISKS INTRODUCED BY EXECUTABLE EXTENSIONS.
Extensions run scripts with the privileges available to the developer or CI process. A malicious extension could inspect files or environment variables, modify build inputs or interfere with deployment.
The manifest compatibility rules and Git lockfile help identify and reproduce code but do not prove it safe.
Google warns that project-root manifests can be auto-loaded without a separate trust prompt. Untrusted repositories containing such manifests should be treated as executable software.
Enterprise controls should include restricted repositories, review requirements, commit pinning, limited CI credentials and independent deployment authorization. An SBOM scanner generally does not need unrestricted production credentials.
··········
THE EXTENSION SCHEMA REMAINS EXPERIMENTAL.
Google labels the Extension System experimental in the October walkthrough, even though it defines a schema and compatibility mechanisms.
Teams should pin CLI versions, extension commits and templates, and test behavior before upgrading. Native command argument changes can break wrapper scripts, while framework changes can affect execution adapters.
The architecture reduces the need to fork Agents CLI but does not eliminate adapter maintenance.
··········
CUSTOM FRAMEWORK SUPPORT IS AN IMPLEMENTATION PATTERN, NOT AUTOMATIC COMPATIBILITY.
A custom framework can use extensions to replace framework-dependent commands while retaining shared lifecycle operations, but it still needs an application entry point, adapters, evaluation conversion and a compatible deployment interface.
Unusual state representations, authentication requirements and runtimes can demand additional work. The first-party LangChain template is one integration path, not evidence of official adapters for every framework.
The same distinction applies to LangGraph and Deep Agents: integration is bounded by the implementation and deployment target.
··········
WHAT CHANGES FOR ENTERPRISE PLATFORM TEAMS.
The Extension System allows platform teams to standardize infrastructure, deployment conventions and security checks without requiring all application teams to adopt ADK.
Git-distributed extensions fit established review and ownership workflows. Teams can pin releases and adapt only commands that depend on a framework's execution model.
Nevertheless, local command overrides do not replace server-side authorization, a lockfile does not guarantee correctness, and container deployment does not supply unavailable managed-runtime interfaces.
The strongest pattern combines reusable developer tooling with independently enforced deployment controls.
··········
LIMITATIONS OF THE OCTOBER RELEASE AND AVAILABLE EVIDENCE.
Google demonstrates a LangChain project and SBOM deployment extension and documents command dispatch, Git distribution, pinning and selected adapters.
The publication does not benchmark agent quality, inference latency or runtime cost between ADK and LangChain, nor quantify developer time saved compared with custom scripts.
The SBOM example is procedural, not a measured study of vulnerability detection effectiveness. Agent Runtime and ADK-dependent evaluation gaps remain material for production decisions.
The evidence supports a more extensible development lifecycle, not universal framework parity.
··········
WHY AGENTS CLI EXTENSIBILITY MATTERS.
Google's October publication illustrates a separation between agent-framework execution and the operational lifecycle around it. Framework-specific commands can be replaced while infrastructure and selected evaluation and deployment workflows remain shared.
The LangChain template demonstrates adapter-based execution; the SBOM example shows how organizations can insert security checks into familiar commands without forking the tool.
The benefit depends on adapter quality, interface stability and controls outside local developer environments. The Extension System does not solve interoperability generally or make every managed Google Cloud feature independent of ADK.
It provides a concrete mechanism for separating application framework choices from selected deployment, evaluation and governance workflows.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
