The agent demo is the easy part#
Google’s developer blog pulled five lessons from its Google Cloud AI Agent Bake-Off, a timed challenge where teams built autonomous agents for problems such as e-commerce returns, legacy banking modernization, and startup go-to-market automation.
The useful part is not the competition format. It is the failure mode Google describes: the gap between a chat-style LLM demo and a production agent is mostly architecture. Better prompts help, but they do not solve state, routing, tool access, validation, latency, or maintenance.
Google’s framing is blunt enough to matter. The “honeymoon phase” of simply chatting with an LLM is over. Agent systems now need clearer boundaries: specialized components, deterministic execution, strict schemas, and a plan for replacing parts when model capability moves.
That is a good lens for teams building with agents now. The question is less “Can the model do this once?” and more “Can this system recover, validate, route, swap tools, and fail safely?”
Split the agent before it becomes a liability#
One of Google’s main lessons is to avoid turning one large LLM prompt into the whole application.
A single agent asked to extract intent, retrieve data, reason over policy, call tools, and generate user-facing output will become hard to debug. It can also become slow. Google points to an example from the bake-off where tightly scoped agents running in parallel reduced processing time from about one hour to about ten minutes.
The broader pattern is familiar from software architecture: split the work. Treat agents more like microservices than like one all-purpose brain.
A practical multi-agent setup might include:
- an intent extraction agent
- a retrieval or database agent
- a policy or rules agent
- a visual generation or multimodal agent
- a supervisor that routes tasks and combines results
This does not make the system automatically safe or correct. It makes the system easier to inspect. If one component fails, drifts, or needs a new model, the team can change that part without rewriting the whole workflow.
The tradeoff is coordination cost. A multi-agent system adds orchestration, state handling, and more places for partial failure. But for production work, those costs are usually more manageable than a monolithic prompt that no one can reason about after the third iteration.
Build for replacement, not permanence#
Google’s second lesson is uncomfortable but realistic: the agent harness you write today may be obsolete soon.
The blog uses an e-commerce virtual try-on challenge as the example. Teams built multi-step solutions using Gemini 2.0 under a tight deadline. Google notes that soon after, a newer image model capability made similar work achievable with a much simpler prompt.
That is the agent builder’s trap. A complex workflow may be necessary today because the base model cannot yet do the task directly. But frontier model capability can absorb parts of the workflow later.
So the right design assumption is impermanence.
Do not build every agent harness as sacred infrastructure. Build it as a replaceable layer. Keep interfaces narrow. Keep model-specific code contained. Make it possible to remove a sub-agent, swap a tool, or collapse a multi-step flow when a model becomes good enough to handle it directly.
This matters for cost as much as elegance. Teams can spend months hardening an orchestration layer that becomes technical debt when native model capability catches up. The safer pattern is modularity with planned deprecation.
Multimodality is no longer a cosmetic feature#
Google also argues that multimodality should be designed into the agent system from the start, not bolted on after text works.
The retail example is simple. A text recommendation like “wear blue jeans” does not solve the real user problem if the task is visual fit, style, or product matching. The agent needs image input, visual context, and sometimes image generation to produce an answer the user can actually judge.
In agent terms, multimodality changes the prompt surface and the evidence surface. A user photo is not decoration. It can carry body shape, room context, object condition, product similarity, or a defect that text may describe poorly.
For developers, that means the architecture needs to handle more than text strings. It may need to ingest images, extract visual features, call generation tools, and return visual outputs. It may also need stronger privacy and retention rules, because images can contain sensitive information that plain text prompts do not.
The core point is sound: if the real workflow is visual, audio, or document-heavy, a text-only agent will either underperform or ask the user to translate the world into words. That creates friction and loses information.
Protocols matter when agents touch real systems#
Google’s fourth lesson is about integration. The blog names several emerging agent-related protocols and interfaces, including MCP, A2A, UCP, AP2, A2UI, and AG-UI. The practical advice is to avoid writing custom wrappers for every internal tool or enterprise system when a standard protocol can carry the connection.
The clearest example is MCP, the Model Context Protocol. The promise is standardized discovery and interaction: agents can find resources and tools through defined structures instead of relying on brittle one-off glue code.
This is not magic. Protocols do not remove the need for authorization, logging, rate limits, data governance, or secure transaction boundaries. They also do not guarantee that every vendor implementation will be equally mature.
But the direction is important. As agents move from demos into enterprise workflows, integration becomes the bottleneck. An agent that cannot safely reach inventory, CRM, banking, ticketing, or document systems is mostly a chat interface. An agent that reaches them through custom glue everywhere becomes expensive to maintain.
Open protocols are a bet on reducing that integration tax. Teams still need to choose carefully, but ignoring the protocol layer now may create migration pain later.
Let the model reason. Let code execute.#
The most important lesson is also the least glamorous: do not use the LLM as the execution engine for deterministic work.
Google cites a legacy banking challenge where teams tried to let AI handle mathematical work in financial transactions and ran into validation errors. The recommended pattern is direct: use the LLM for reasoning, classification, and intent extraction. Use deterministic code for math, transaction logic, validation, and state changes.
That boundary is not optional in serious systems.
An LLM can infer that the user wants to calculate interest, submit a return, update a supplier order, or compare loan options. But the calculation, database update, payment instruction, or compliance check should go through typed code paths with validation.
Strict schemas are part of that boundary. JSON schemas, Pydantic-style validation, and typed tool inputs reduce ambiguity between the model and the system. They also make failures visible. If the model produces invalid structure, the application can reject it, ask for repair, or route to a fallback path.
This is where many agent prototypes break. They look impressive because the model can narrate the right action. They are unsafe because the execution path is still probabilistic.
What to take from Google’s bake-off#
The useful takeaway is not that every team needs a complicated multi-agent framework. Some workflows are still better served by a single model call plus a few tools.
The stronger lesson is that production agents need explicit boundaries:
- split complex work into scoped components
- assume parts of the system will be replaced
- support multimodal inputs when the real task requires them
- use protocols where they reduce brittle integration code
- keep deterministic execution outside the model
- validate model outputs before they touch real systems
This is the difference between an agent that demos well and an agent that can survive contact with users, legacy systems, and changing model capabilities.
Google’s post is partly developer advocacy for its own ecosystem, including Gemini and its Agent Development Kit. That context matters. But the architectural advice is not limited to Google tools.
The production pattern is broader: agents should reason inside a controlled box, call tools through clear contracts, and hand deterministic work to deterministic systems. Anything else is just a prompt with production access.