From Chatbot to Agentic System: Lessons from the AI Agent Bake-off

Source: Dev.to

Introduction: The Challenge

In the recent Google Cloud AI Agent Bake‑off episode 2, developers faced a scenario all too common in legacy modernization: transforming Cymbal Bank’s basic, transactional chatbot into a trusted, proactive financial planner.

The goal wasn’t just to write better prompts; it was to engineer a sophisticated system where AI agents could work alongside existing infrastructure (without needing a rip‑and‑replace strategy) to deliver secure, personalized financial guidance.

This post dissects the architectural patterns and technologies—specifically the Agent‑to‑Agent (A2A) Protocol and the Agent Development Kit (ADK)—that made these solutions possible.

The Core Problem: The “Simple” Chatbot Ceiling

Most banking bots today hit a hard ceiling. They can fetch a balance or list transactions, but they lack the context to be true financial partners. The Bake‑off challenge was to break this ceiling by building an AI agent capable of orchestration, utilizing a robust backend to solve complex user goals like “Help me plan a trip to Paris on a budget.”

The Secret Sauce: Agent‑to‑Agent (A2A) Protocol

The linchpin of the winning architectures was the Agent‑to‑Agent (A2A) Protocol. A2A is a standardized communication layer that allows distinct AI agents to collaborate securely.

For developers building complex systems, A2A solves three massive headaches:

• Interoperability: Connects agents regardless of their underlying stack (LangGraph, CrewAI, Semantic Kernel), enabling composite systems.
• Distributed Problem Solving: Allows an orchestrator to delegate sub‑tasks to domain experts, handling complex workflows that would overwhelm a single context window.
• Encapsulation & Security: Agents interact as opaque services, sharing structured inputs/outputs while keeping internal memory, prompts, and tools private.

Architecture: The Multi‑Agent Hierarchy

The most successful teams moved away from the “Monolithic Agent” anti‑pattern. Instead, they built hierarchies of specialized agents—think of it like a microservices architecture, but for cognitive tasks.

An Orchestrator Agent acts as the interface layer, understanding user intent and delegating work to specialized Sub‑Agents via A2A.

How A2A Enables This Flow

• Capability Discovery: Through a handshake process, the Orchestrator discovers what registered agents are available and what tools they expose, without needing access to their source code.
• Standardized Transport: When delegating a task, A2A ensures the request and response are structured and secure. This is critical in fintech; the Orchestrator doesn’t need to see the raw SQL query the sub‑agent uses, only the sanitized result.

The Architecture in Action

Team Adrian and Ayo built a Router Agent that classifies user intent. If a user asks about a mortgage, it routes to a Big Purchases Agent; if they ask about coffee, it routes to a Daily Spending Agent.

Let’s trace a user request: “I want to plan a trip. Can you help me design a budget?”

1. Ingest: The Orchestrator receives the query.
2. Route: It identifies the “Big Purchase” intent and delegates to the local Big Purchases Agent.
3. Bridge: Using A2A, the local agent calls the remote Cymbal Bank Agent.
4. Execution: The remote agent, secure inside the bank’s backend, accesses internal tools and databases to fetch financial history.
5. Return: Data is returned via A2A to the Big Purchases Agent.
6. Synthesize: The agent calculates affordability, possibly calling a Visualization Agent to chart a net‑worth forecast.
7. Response: The Orchestrator presents the final, multi‑modal plan to the user.

The Tooling: Agent Development Kit (ADK) & Gemini

Teams utilized Google’s Agent Development Kit (ADK) to treat agents as software artifacts—giving them structure, state management, and deployment pipelines. This orchestrated a suite of models including Gemini 2.5 Pro, Gemini Flash for reasoning, and Veo for video generation.

Beyond Sequential: Advanced Patterns

While linear (sequential) workflows handle simple tasks, the ADK supports advanced patterns for higher intelligence and lower latency.

1. Parallel Agents

• Pattern: Execute multiple independent agents simultaneously and aggregate the results.
• Use Case: Loading a “Financial Health” dashboard. Instead of fetching Account Balances → Investment Performance → Rewards sequentially, a parallel flow triggers all three agents at once, drastically reducing Time‑To‑First‑Byte (TTFB) and perceived latency.

2. Loop Agents (Generator‑Critic)

• Pattern: An iterative cycle where one agent produces an output and another critiques it until a threshold is met.

• Use Case: Complex budgeting.

  1. Generate: Strategy Agent suggests “Increase loan payments by $500.”
  2. Critique: Feasibility Agent checks cash flow: “Rejected – this causes a deficit in the grocery budget.”
  3. Refine: Strategy Agent iterates: “Increase by $200 and cancel Netflix.”
  4. Finalize: The plan passes validation and is shown to the user.

Grounding with BigQuery ML (BQML)

To mitigate hallucinations—the kryptonite of financial AI—Team Adrian and Ayo integrated BigQuery ML.

Benefits:

• Data Gravity: No need to move sensitive transaction logs to an external inference endpoint.
• Accuracy: Training forecasting models on the user’s actual historical data ensures the “Net Worth Projection” is mathematically sound, not just an LLM guess.

Connecting to the Real World

An agent in isolation is a toy. An agent connected to services is a tool.

Identity‑Aware Agents (Firebase)

Personalization requires identity. By integrating Firebase Authentication, the teams created a secure session context. This user_id context is passed through the ADK state management to every sub‑agent, ensuring that when an agent asks “Get Transactions,” it only ever retrieves that user’s data.

Community Grounding (Reddit API)

While BQML handles quantitative data, the team used the Reddit API for qualitative insights. When planning a trip to Paris, the agent queries r/travel for actual community recommendations. This “Social Proof” layer adds a richer, real‑world grounding to the suggestions.