You build an AI assistant that checks support tickets. You ask about ticket 1042. It calls the right function and returns the correct status.
Then a colleague asks about a ticket that does not exist. The assistant invents an explanation. Another request hits a slow service, and the application hangs.
Your successful demonstration covered one path through a much larger system.
For junior engineers, this is a useful career milestone: moving from “I built something that works” to “I can explain when it works, how it fails, and how I test changes.”
Google’s October 21, 2026 article about Agents CLI extensions offers a practical starting point. Its broader lesson concerns the engineering work surrounding an agent: evaluation, deployment, and investigation when something goes wrong.
1. What changed?
Google describes an extension system introduced in Agents CLI version 1.5.0 and a first-party LangChain extension shipped with version 1.8.0.
A command-line interface, or CLI, lets developers operate tools through typed commands. Agents CLI provides a common interface for creating, evaluating, and deploying agent applications.
The LangChain template lets developers use that framework within the CLI’s lifecycle without adopting Google’s Agent Development Kit, or ADK. The article also demonstrates customizing deployment checks. October 21 is the walkthrough’s publication date; it should not be treated as the launch date of every underlying capability. Google’s original article
My assessment: the useful development is greater separation between how an agent behaves and how a team operates it.
2. Understand the system around the agent
Consider an assistant answering, “What happened to my support ticket?”
Several components cooperate:
Component | Its responsibility |
|---|---|
Language model | Interprets the request and produces a response |
Agent framework | Coordinates model calls, tools, and conversation state |
Ticket tool | Retrieves information from the support system |
Application service | Accepts requests and manages application behavior |
Deployment process | Publishes a particular application version |
Evaluation and monitoring | Check behavior and expose failures |
A tool is a function the agent can call, such as lookup_ticket. The model may choose to request it, but ordinary application code performs the lookup.
An evaluation checks behavior against defined expectations. A trace records execution steps, helping you inspect which tool was called, what it returned, and where time was spent.
These distinctions matter because a wrong answer can have several causes. The model may choose the wrong tool. The tool may retrieve stale information. The application may lose the user’s identity.
Changing the prompt will not fix every layer.
3. How teams handled this previously
Teams can already build these capabilities with deployment scripts, test suites, cloud services, and monitoring tools.
The difficulty appears when those components assume a particular framework. Adopting another framework can require adapting the surrounding infrastructure.
Google’s article describes approaches including maintaining a modified copy of the CLI or placing custom scripts around it. Those approaches remain possible, but they create code the team must maintain. Original discussion
There is nothing inherently wrong with a small script. For a simple application, it may be the clearest solution.
The question is whether each project should independently rebuild the same deployment and evaluation conventions.
4. How extensions improve the workflow
An extension maps selected CLI commands to replacement implementations or adds new commands. The mapping is declared in an agents-cli-extension.yaml file. Developers can inspect active extensions and their command sources. Extension documentation
Think of it as an adapter. The team keeps a familiar command interface while the implementation underneath accommodates another framework.
For LangChain, the documented evaluation flow generates execution records in a shared format, allowing subsequent grading and comparison steps to reuse existing tooling. Framework documentation
The potential benefit is consistent practice across projects. Engineers can review familiar structures and compare changes using a common workflow.
That consistency does not establish correctness. You still need representative questions, reliable tool implementations, and explicit acceptance criteria.
5. Limitations and situations where it does not fit
First, the extension system is described as experimental in version 1.8.0. Teams should pin versions and expect possible interface changes. Release walkthrough
Second, framework support does not mean identical capabilities. The documented LangChain integration refuses certain ADK-dependent operations, including dataset synthesis and automatic prompt optimization. Check the support matrix before designing your workflow. Framework documentation
Third, framework flexibility does not remove infrastructure dependencies. The demonstrated deployment uses Google Cloud. An organization committed to another environment should assess integration costs before adopting it.
Fourth, an extension that runs checks before deployment is a workflow mechanism, not sufficient evidence of organizational enforcement. The authoring documentation provides a way to bypass overrides. My recommendation is to enforce mandatory release controls through restricted deployment permissions and the approved build pipeline. Authoring documentation
Finally, ask whether you need an agent. A fixed ticket-status page may be easier to test and operate when users only need one predictable lookup.
6. A realistic enterprise use case
Imagine a fictional software company whose support employees regularly consult a handbook and check ticket status.
A small assistant could answer handbook questions and retrieve ticket details. It would have no ability to close tickets, issue refunds, or change customer records.
This limited scope makes the first deployment easier to evaluate.
The company’s support specialists define expected answers and escalation rules. Engineers implement tool access and failure handling. A platform team manages deployment and telemetry.
Suppose the ticket service times out. The desired response is: “I couldn’t retrieve the current status. Please try again or open the ticket system.”
A plausible invented status is a failure, even if the response sounds helpful.
This is an illustrative design, not a reported customer implementation.
7. Build a small project: a support assistant with a release check
Use synthetic information and keep the application narrow. You should understand basic Python functions, API calls, environment variables, and automated tests before starting.
Step 1: Define the contract. Write down what the assistant may answer, which tools it may call, and how it should handle missing information. A contract is simply an explicit agreement about expected behavior.
Step 2: Prepare a tiny dataset. Create ten fictional tickets and a short support handbook. Give the ticket lookup three possible results: found, not found, and unavailable. Return structured fields rather than an ambiguous paragraph.
Step 3: Start from the official LangChain template. Follow the source’s setup instructions and record the CLI, template, dependency, and model versions. The demonstrated route requires Python 3.11+, uv, the Google Cloud SDK, and a billing-enabled project. Setup walkthrough
Step 4: Write 20 evaluation cases. Include eight ordinary requests, four missing-information cases, four tool failures, and four requests outside the assistant’s scope. Record the expected behavior before running the agent.
Step 5: Grade observable behavior. Check ticket identifiers, tool arguments, and returned status with ordinary assertions. For handbook answers, review factual accuracy and whether unsupported claims appear. Avoid requiring one exact sentence when several phrasings are acceptable.
Step 6: Introduce a regression. Change a tool description or prompt so that a previously correct case fails. A regression is a change that breaks existing behavior. Compare the new results with the baseline.
Step 7: Add your own release check. Stop the release when a critical case fails. This project-specific rule is something you implement; it is not automatically supplied by the template.
Step 8: Test the deployed application. Repeat key cases against the deployed endpoint. Local tests do not exercise every deployment setting or permission. Keep test results and remove cloud resources after the exercise.
8. What skills does the project demonstrate?
The project shows more than familiarity with an agent framework.
It demonstrates interface design through structured tool responses, test design through deliberate failure cases, and debugging through execution traces.
It also demonstrates experimental discipline. Record which change produced which result, and repeat important cases to observe variation.
Twenty passing cases are evidence about those cases, not a statistical guarantee of reliability.
For your portfolio, include one failure you investigated. Explain whether it came from the model, tool, data, or deployment configuration—and why your fix addressed that cause.
9. Practical next steps
Begin with the read-only ticket tool. Add handbook retrieval after the basic workflow is understandable.
Keep a small set of evaluation questions separate from those you use while improving the prompt. Otherwise, you risk tailoring the assistant to examples it repeatedly sees.
Before claiming readiness for real users, examine authentication, access control, sensitive logging, cost, and recovery procedures.
My recommendation is to publish the project as a tested prototype. Include its scope, evidence, limitations, and a clear next engineering step.
That gives readers—and interviewers—a concrete basis for assessing your judgment.
10. Sources
Google Developers Blog: agent lifecycle extensions, October 21, 2026 — dated walkthrough and setup.
Agents CLI: Using Extensions — command customization and extension management.
Agents CLI: First-party frameworks — LangChain integration and supported operations.
Agents CLI: Authoring Extensions — extension implementation and override behavior.
Official Agents CLI repository — source code and project documentation.
Product capabilities are attributed to the primary sources. The company scenario, evaluation design, and release recommendations are proposed teaching examples; this article does not report a hands-on benchmark.