Google Agents CLI Adds LangChain Support, With Evaluation Limits

In its October 21 announcement, Google says Agents CLI introduced extensions in version 1.5.0 and shipped its first-party LangChain extension in version 1.8.0. Extensions can replace built-in command behavior or add commands without requiring a fork of the CLI.

The LangChain offering is a project template. It carries a manifest that activates framework-specific command overrides inside the generated project. Google describes support for LangChain agents, LangGraph graphs, and Deep Agents through their common graph representation. Its documentation says the generated code contains no ADK dependency.

Our editorial assessment is that this matters most to teams already using LangChain and considering Google Cloud deployment. They can investigate a shared lifecycle without first rewriting their agent around ADK. That is a documented integration path, not evidence that an existing application will migrate unchanged or require less maintenance.

The first-party framework documentation separates framework-dependent commands from shared infrastructure. In a LangChain project, run invokes the compiled graph in-process, playground starts the local LangGraph development server, and eval generate produces the standard evaluation dataset shape. Deployment and several evaluation commands remain native.

For Cloud Run, Google says deployment uses the same underlying path as an ADK project. The template exposes a FastAPI application and serves Agent2Agent protocol traffic, giving the deployment machinery a common application contract. Teams changing the generated project must preserve the documented application entry point.

This is also a reason to inspect command behavior before reusing existing scripts. A familiar command name can invoke a different implementation within this project. The extension documentation says command help identifies overrides, while agents-cli info shows their sources. Those inspection tools belong in a proposed pilot’s first checks.

The supported evaluation sequence is narrower than “all evaluation commands work.” Google says the overridden eval generate drives the LangChain graph and emits the standard EvaluationDataset format. Native eval grade, eval compare, and eval analyze can consume that output.

The announcement explicitly refuses eval dataset and eval optimize because their implementations require ADK. The current framework documentation specifically lists eval dataset synthesize and eval optimize as refused. A team relying on automatic dataset synthesis or that optimization workflow therefore has a concrete gap to resolve.

Our recommendation is to begin with a small, manually reviewed dataset of representative tasks. Define acceptable outputs and tool behavior before generating traces, then examine failures alongside grades. Our agent evaluation guide for small teams provides related planning guidance. Neither Google’s walkthrough nor this article establishes evaluation quality for your application; we have not run these commands.

The announcement labels the extension system experimental in version 1.8.0 and warns that the manifest schema and command surface may change incompatibly. It recommends pinning the CLI version. Its example references the LangChain template at v1.8.0; the live framework documentation accessed for this article references v1.11.0.

That difference is evidence that the documentation has moved beyond the announcement’s example. It does not establish when every intervening change shipped. For a reproducible trial, record the CLI version, template reference, and project revision together. Avoid combining snippets from different versions without checking their compatibility.

The extension lifecycle documentation separately describes Git-installed extensions pinned to exact commit SHAs. Installation restores pinned code; an explicit update advances the reference. Distinguish that mechanism from the LangChain template’s project-root manifest, which loads automatically. Scaffolding a framework project and installing a separately distributed extension are different operations.

We propose selecting one bounded agent task with an understandable expected result. Preserve a baseline from the existing application, then adapt that task to a separate template-based project. Compare its answer, tool calls, and failure behavior using the same inputs. This is a suggested experiment, not a migration we performed.

Next, verify which commands are active and whether the supported evaluation sequence produces artifacts your reviewer can interpret. Include an intentionally unsuccessful case so the trial examines failure reporting as well as a successful response. Keep application regression checks alongside agent evaluations; our guide to regression tests for AI-generated code explains that complementary discipline.

If Cloud Run is your intended target, assess that deployment path separately from local execution. The current framework documentation warns that Agent Runtime integrations expecting an ADK application have limitations, including unavailable invocation through the Console playground. Local success should not stand in for checking the chosen deployment target.

Consider a pilot if your team wants to retain LangChain while using Agents CLI’s shared deployment and supported evaluation steps. The strongest adoption case is a concrete workflow need: common commands that your team can inspect, document, and maintain.

Defer broader adoption if essential steps depend on the refused evaluation commands, or if you cannot maintain an experimental interface. A working existing deployment remains a useful baseline. The decision should turn on whether this template supports your actual tasks and review process, with its version and limitations recorded, rather than on the breadth of the announcement’s framework coverage.