AI agents: from prototype to production

Anyone can build an AI agent demo in an afternoon. Add a language model, a few tools, and a loop, and within minutes you have something that looks like magic: it reads an email, queries a knowledge base, replies, acts. The trouble is that the demo and the product are different animals. What impresses in a controlled pitch tends to collapse in front of real users, messy data, and the cost of being wrong at scale.

Google's whitepaper Introduction to Agents, published in November 2025, makes that contrast explicit. It defines an agent as “language models in a loop with tools to accomplish an objective” and, more revealingly, as “a system dedicated to the art of context window curation.” The definition is simple; the engineering to reach production is not. This article unpacks what separates the prototype from the reliable system.

An agent is a system dedicated to the art of context window curation.Google · Introduction to Agents

What is an AI agent, anyway?

An AI agent is software that uses a language model to decide, step by step, which actions to take, calling tools, reading results, and continuing until an objective is met. Google describes its anatomy in four parts worth memorizing, because each one becomes a failure point in production:

• The Model is the brain: it reasons, plans, and decides the next action.
• The Tools are the hands: they give the model access to the world (APIs, databases, searches, actions).
• The Orchestration is the nervous system: the loop that coordinates planning, memory, and reasoning between one decision and the next.
• The Deployment is the body: the infrastructure that stands it all up, with scale, security, and monitoring.

The demo usually shows only the brain and the hands. Production lives or dies by the nervous system and the body, and that's exactly where most projects stumble.

From prompt engineering to context engineering

The big mindset shift, per Google, is to drop the idea of “prompt engineering” and embrace “context engineering.” A polished instruction isn't enough: what defines an agent's quality is curating what enters the model's limited attention window at each step. Instructions, relevant facts, available tools, and conversation history all compete for that scarce space, and choosing well is half the job.

This is where memory becomes a piece of engineering, not a detail. Google distinguishes two kinds: short-term memory, which holds the thread of the current conversation inside the context window; and long-term memory, which persists knowledge across sessions, in practice a RAG system over a vector database, queried on demand when the agent needs to recall something that no longer fits in the window.

How do you measure whether an agent is working?

You can't improve what you don't measure, and measuring agents is harder than measuring ordinary software, because the output isn't right or wrong, it's better or worse. Google calls this discipline “Agent Ops,” the natural evolution of DevOps and MLOps. The recipe is to instrument the agent's actual behavior, not just its uptime:

• Goal completion: did the agent actually solve the user's task, end to end?
• Satisfaction: was the response useful and appropriate in the eyes of the person who asked?
• Latency and cost: how much time and how many tokens did each interaction consume?
• “LM as Judge” evaluation: a model scores the agent's answers against a set of reference cases (a golden dataset).
• Tracing every step: logging every decision, tool call, and intermediate result so you can debug when something goes wrong.

With those metrics in hand, the decision to ship a version stops being a gut feeling and becomes a data-driven Go/No-Go. And there's one habit Google treats as non-negotiable: every bug that appears in production should be converted into a permanent test, added to the golden dataset, so that failure never slips by unnoticed again.

What makes an agent secure?

Giving a language model the power to act changes the nature of the risk. Google flags two primary threats: “rogue actions,” when the agent does something harmful or unintended, and “sensitive data disclosure,” when it leaks information it should protect. Unlike a chatbot that only talks, an agent that executes can cause real damage, which is why security is part of the design from the start.

The recommended answer is defense in depth, combining two complementary layers:

• Deterministic guardrails: hard, coded rules that bound what the agent can do, regardless of what the model “decides.”
• Reasoning-based defenses: the model itself (or a supervising model) judging whether an action is appropriate before executing it.
• Identity and least privilege: treating the agent as a new class of “principal,” with its own identity and minimal permissions, the way you'd grant access to an employee or a service.

How Charla applies this in production

At Charla, these principles are how the platform is built. Every assistant runs on a single, unified agentic loop with agentic retrieval: instead of passively injecting snippets of a knowledge base into the prompt (classic RAG), the agent calls tools like kb_search and wiki_search on demand, when it actually needs the information. It's Google's “context engineering” put into practice: the agent curates its own context, step by step.

The trust layer shows up in concrete product decisions. Responses are streamed over SSE, without exposing the raw chain-of-thought to the user. Every tool call and every privileged action is written to an append-only audit log. Each assistant (each “Charla”) is isolated, with its own knowledge base, access list, and prompt. Retrieval is filtered per assistant before ranking, reflecting exactly the principle of identity and least privilege.

Cost and human oversight are treated as first-class requirements too: per-assistant credit budgets cap spend, and a propose-then-approve posture keeps a person in the loop for knowledge and configuration changes. These are the whitepaper's production concerns (reliability, observability, security, cost, oversight) showing up in a real platform, without magic promises.

From bricklayer to director

Google's conclusion captures the changing role of whoever builds these systems: the developer stops being a “bricklayer,” laying each brick of logic by hand, and becomes a “director,” setting objectives, providing tools, establishing limits, and judging results. Building the demo will stay easy. The real work, and the competitive edge, lies in everything that comes after it: evaluating, observing, securing, controlling cost, and keeping the human in command. That's exactly the terrain where an agent stops being a trick and becomes a product.