Forem: Abraham Gomez

A Founder’s Blueprint to Creating a Technical Sales Team

Abraham Gomez — Fri, 27 Feb 2026 17:52:39 +0000

I have found that technical founders tend to treat Go-To-Market (GTM) as an afterthought (or a black box) instead of a creative venture. Just as you, as a technologist, know exactly when to use a SQL vs. NoSQL database or when to leverage Gemini vs. classical BERT models, you need to know exactly when to deploy DevRel, Sales Engineers, Forward Deployed Engineers, and Solutions Architects.

Startup Journey for Technical GTM Team

The Technical Founder’s Sales Dilemma

Over the past 5 years as a Startup Customer Engineer at Google Cloud, I’ve helped over 400 founders build and sell AI. Some have built unicorns, others have executed crazy pivots, and each journey has offered incredible lessons. With that kind of exposure, clear Go-To-Market patterns emerge.

For technical founders, the most common pitfall I see is flying blind into the art (and science) of designing a technical GTM team. While YC has taught founders how to obsess over product feedback, there is a massive blind spot when it comes to structuring the team that builds commercial traction in parallel. Let’s admit it: the idea that “if you build it, they will come” rarely works out in practice.

This guide aims to provide a simplified, highly actionable approach to designing your technical sales motion. First, we’ll demystify the roles of DevRel, Sales Engineer, Forward Deployed Engineer, Solutions Architect, and Technical Account Manager. Then, borrowing from the SQL relational model (think 1-to-many, 1-to-few, or 1-to-1), I’ll give you a mental model for understanding which roles make sense—and when to hire them without burning unnecessary runway.

I’m adopting the mindset that at a startup, everyone generally falls into one of two camps: the builders & the sellers (as investor Jack Altman succinctly put it).

// Detect dark theme var iframe = document.getElementById('tweet-1481834098347819013-533'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1481834098347819013&theme=dark" }

Consider this your baseline blueprint—mold it to your startup’s unique GTM goals.

VCs are Hungry for Capital Preservation

You hear it often: “We are on the cusp of seeing the world’s first single-employee unicorn.” This is driven by the sheer velocity at which developers can now go from MVP to production leveraging SOTA models and agent frameworks (read more on The Growth Mind blog).

Let’s look at the classic Open-Source-to-B2B founder pipeline. A founder launches a killer repo on GitHub (cough cough FastAPI, LangChain). Having captured developer mindshare, they deploy a managed, enterprise offering for their open-source tech (FastAPI Cloud, LangGraph).

Now, on top of managing a product feedback loop, that founder has to figure out:

How (and who) should focus on onboarding and retaining our paying customers?
How do we replicate our success in the Bay Area across the rest of the US, Europe, and Asia?
Who evangelizes our product to developers vs. enterprise buyers?
What do we do if a high-paying enterprise is blocked from deploying because of 3rd-party tech we don’t own?
How do we build educational content for specific, lucrative industry verticals?

Here is your golden rule: Your technical GTM team’s #1 mission is to decrease the friction and time-to-value (TTV) between acquiring a lead and turning them into a happy, paying customer.

Demystifying Key Technical GTM Roles: Who, What, and When?

I am giving you hard definitions below. But in full transparency: the earlier you are in your lifecycle (Pre-Seed/Seed), the more these roles bleed into one another. In the early days, your first technical GTM hire will likely wear all these hats to win over a customer.

As you scale, specialization is what drives ARR.

1) Developer Relations (DevRel)

DevRel professionals are your company’s bridge to the developer community. They foster engagement and advocate for your product within the broader technical ecosystem. They are less about direct quota-carrying sales, and more about creating top-of-funnel demand by making developers want to use your product.

What they really do: Create world-class documentation, write code samples, speak at conferences, live in developer forums/Discord, and funnel community feedback directly to your product team.
When You Need Them: Essential for developer-first products, platforms, or APIs (B2D models). Hire them when you are ready to build a self-sustaining ecosystem and drive organic adoption. They are often a strong early-stage hire (Seed to Series A).
When You Don’t Need Them (and why): If your product doesn’t have a direct developer audience, or if your sales motion is purely top-down enterprise (selling to CIOs, not SWEs), dedicated DevRel is a waste of capital. Forcing them to do direct sales will destroy their community credibility.
Aliases: Developer Advocate, Developer Evangelist, Community Engineer.

2) Sales Engineer (SE)

Sales Engineers are the technical backbone of your closing team. They bridge the gap between complex technology and business needs during the pre-sales process. They prove to the buyer that your product actually works for their specific environment.

What they really do: Deliver tailored product demos, scope and manage Proof-of-Concepts (PoCs), answer brutal technical security questionnaires, and overcome technical objections to get the deal signed.
When You Need Them: Crucial when your product requires deep technical validation, integration discussions, or custom scoping before a buyer will sign. Usually hired as you transition away from founder-led sales (Series A+ for B2B).
When You Don’t Need Them (and why): For self-serve Product-Led Growth (PLG) SaaS products, an SE is expensive overkill. Furthermore, they shouldn’t be your post-sales implementation team. Founder Sanity Check: The cost of a single SE needs to be easily justified by the pipeline they help close.
Aliases: Solutions Consultant, Pre-Sales Engineer, Solutions Engineer.

3) Forward Deployed Engineer (FDE)

Pioneered heavily by companies like Palantir, Forward Deployed Engineers are elite technical operators who go deep with customers post-sale. They embed themselves into the customer's environment to force successful integrations and sticky adoption.

What they really do: Lead complex custom integrations, write bespoke scripts, provide deep technical advisory, and solve post-sales blockers that require SWE-level code understanding.
When You Need Them: When your product requires significant customization, integration into messy legacy enterprise environments, or ongoing technical hand-holding. Common in Series B+ (or highly technical Series A) where churn prevention is tied to complex implementation.
When You Don’t Need Them (and why): If your product integrates in 5 minutes via a standard API, FDEs are an unnecessary drag on margins. Do not treat them as a glorified IT helpdesk—their ROI comes from unlocking massive enterprise deployments.
Aliases: Implementation Engineer, Professional Services Engineer, Deployment Strategist.

4) Solutions Architect (SA)

Solutions Architects design the overarching technical blueprint. They look at how your product fits into the buyer's broader tech stack. They are focused on macro-architecture rather than just pitching features, and often have deep industry/vertical specialization.

What they really do: Architect comprehensive technical solutions, assess enterprise feasibility, define scope for multi-million dollar rollouts, and translate complex designs to both engineers and C-suite executives.
When You Need Them: When deals require integrating your product into a massive, multi-cloud enterprise architecture, or when you are selling multi-product bundles. Typically seen at Series B+ when moving upmarket into the Fortune 500.
When You Don’t Need Them (and why): If your product is standalone software, a full-time SA is premature. SAs also shouldn't be bogged down writing day-to-day production code.
Aliases: Enterprise Architect, Cloud Architect, Technical Architect.

5) Technical Account Manager (TAM)

Technical Account Managers provide dedicated, proactive technical support to your most strategic paying customers. They ensure long-term health, adoption, and expansion.

What they really do: Serve as the trusted technical advisor for VIP accounts. They proactively identify scaling issues, manage massive technical escalations, and guide the customer on new feature adoption.
When You Need Them: For your highest-value enterprise accounts where losing them would physically hurt your ARR. Usually employed at Series B+ for Enterprise B2B models to drive Net Revenue Retention (NRR).
When You Don’t Need Them (and why): For SMBs or accounts with simple needs. TAMs are expensive; they should not be handling routine support tickets that a standard Customer Success team could manage.
Aliases: Strategic Account Engineer, Client Technical Advisor.

Putting It All Together: Your Technical GTM Playbook

Deciding who to hire and when is a strategic chess match. This table provides a concise overview of key roles and highlights their operational differences to help you hire accurately based on your current constraints.

Startup Journey for Technical GTM Team

As a founder, map your hires across two spectrums: pre-sales vs. post-sales challenges, and one-to-one vs. one-to-many engagement models.

Initially, most startups focus on a pre-sales, one-to-many approach (DevRel) and a one-to-few approach (Sales Engineers). As product-market fit solidifies and margins allow for GTM expansion, you introduce FDEs, SAs, and TAMs to capture and retain enterprise whales.

(Note: The diagram above isn’t absolute. While SAs and TAMs typically arrive later in the startup life cycle, we are seeing an increasing trend of early-stage, deeply technical AI startups hiring FDEs much earlier to ensure their first few pilots don't fail).

Technical GTM Role Comparison: A Founder’s Quick Guide

Table explaining difference between DevRel, SE, FDE, SA, and TAM

How to use the table above: Think of this table as your strategic compass, not a rigid checklist. As you budget for headcount, ask yourself:

What is our product’s technical complexity? Simpler products scale with Sales Engineers pre-sale. Highly complex, heavy-lift products require FDEs and TAMs post-sale to prevent churn.
What is our core sales motion? Is it developer-led (DevRel is key)? Is it top-down enterprise (SEs and SAs are vital)? Or is it heavily dependent on custom post-sale integration (FDEs)?

Strategic Team Building: The true power of a technical GTM team is how the roles complement one another. An SE wins the technical evaluation. An FDE ensures the complex deployment actually goes live. A TAM ensures the account expands next year. Building your team strategically means identifying the exact bottleneck in your revenue funnel and plugging it with the right persona.

Your New GTM Blueprint

Finding product-market fit is only half the battle. To truly scale and achieve the ARR metrics that drive Series A and B rounds, you need a technical Go-to-Market team engineered to collapse the sales feedback loop. It’s not just about "selling"—it’s about enabling, integrating, and evangelizing your tech in ways traditional Account Executives simply cannot do alone.

By understanding the distinct lanes of DevRel, Sales Engineers, FDEs, Solutions Architects, and TAMs, you now have a mental model to avoid costly mis-hires. This is about aligning your pre-sales and post-sales bottlenecks with the right one-to-many or one-to-one talent.

As you plan your next quarter, ask yourself: Where are deals stalling because we lack technical translation? Is your team actually built to handle the heavy lift of enterprise adoption, or are you hoping your core engineering team will just "figure it out" on the weekends?

What GTM strategies have worked for you so far, and what blind spots are you trying to solve right now?

Honorable Mentions

Note: I excluded Customer Success Managers (CSMs), Outbound PMs, Field CTOs, and standard Account Executives (AEs) for the sake of brevity.

Inspiration and further reading:

About the Author:
Abe is a Startup Customer Engineer at Google Cloud where he has helped over 400 founders build, scale, and sell AI products.

Questions/feedback/concerns? Let's connect: x.com/whoinvitedabe | linkedin.com/in/goabego

The 2026 Ultimate Guide to Google for Startups: Funding, Accelerators, and $350k in Credits

Abraham Gomez — Sun, 18 Jan 2026 03:55:28 +0000

Google offers a massive range of programs designed to support startups at every stage of their journey. Whether you're a pre-seed founder building your first MVP or a series B company scaling globally, Google provides access to technology, community, and expert guidance.

The headline benefit? Eligible startups can access Google Cloud credits ranging from $2,000 to $350,000, alongside mentorship from teams at DeepMind, Google Labs, and Google Cloud.

This guide is an updated 2026 version of my previous post, consolidating the newest launches from all Google programs (I will keep this updated quarterly).

I will covered 5 sections: Funding, Accelerators, Google Cloud Credits, Recommended White-papers, and In Person/Virtual events.

Mapping the 2026 Google Startup Ecosystem

Before diving into specific programs, it’s helpful to understand the different "Product Areas" (PAs) and teams you'll interact with:

labs.google – The home for AI experiments like Whisk, Flow and Jules.
google.org – The philanthropic arm focusing on AI for societal impact.
startup.google.com – The primary hub for Cloud credits, accelerators, and education.
DeepMind – The unified research engine providing frontier models (Gemini) and technical guidance.
Google Cloud – The infrastructure powerhouse for scale, credits, and enterprise GTM support.

1. Funding Opportunities

Google doesn't just provide tools; they provide capital. Here is the 2026 landscape of Google-backed investment arms:

AI Futures Fund (Equity + Research)

Launched at Google I/O, the AI Futures Fund is a collaborative effort between Google DeepMind and Google Labs. It is a hybrid program providing equity funding alongside deep technical collaboration.

Focus: Early-stage frontier AI startups.
Check Size: Typically co-invests up to $2 million in selected startups (e.g., via partnerships like Accel Atoms).
Value Add: Rolling evaluations (no batch deadlines) and direct support from DeepMind researchers.

Apply for the AI Futures Fund

Gradient Ventures

Founded in 2017, Gradient Ventures is Alphabet's AI-focused venture arm. It primarily invests in technical founders who are building disruptive AI products.

Focus: Seed to Series A AI-first companies.
Check Size: Typically ranges from $1 million to $30 million.

CapitalG

CapitalG (formerly Google Capital) is Alphabet's independent growth fund focusing on companies that have already achieved product-market fit.

Focus: Growth-stage and late-stage tech (Series C and beyond).
Check Size: Typically $50 million to $200 million.

GV (Google Ventures)

Operating since 2009, GV is a sector-agnostic venture capital arm that provides funding across all stages, from seed to growth.

Focus: AI, Life Sciences, Consumer, Enterprise, and Crypto.

2. Accelerator Programs

Google’s accelerators offer structured mentorship where you are mapped with a dedicated "Googler Buddy." In 2026, the distinction between "accelerator" and "fund" has blurred with the introduction of technical-first initiatives.

AI Futures Fund (Technical Mentorship)

While it provides funding, the AI Futures Fund also acts as an always-on technical accelerator. Unlike standard 10-week cohorts, it provides:

No Batch Model: Review and acceptance happen on a rolling basis.
DeepMind Access: Collaborative research opportunities with the same teams building Gemini.
Early Model Access: Test experimental features in Gemini, Veo, and Nano Banana before public release.

Core Accelerator Directories

Startup Directory: Features 15+ accelerators globally in 2025, including region-specific cohorts (e.g., Brazil, India, MENA).
Developer Directory: Includes impact-focused accelerators for Black, Latino, and Women founders.
Google.org Accelerator: Focused on nonprofits and social impact organizations harnessing Generative AI.

Note: The Google.org Accelerators and Startup Directory are still in progress and should have more information later this quarter.

3. Google Cloud Credits: 2026 Program Tiers

The Google for Startups Cloud Program has been updated for 2026 with higher limits for AI-first companies.

Tier	Eligibility	Cloud & Firebase Credits	Support & Perks
Start Tier	Pre-funded; < 5 years old.	Up to $2,000 (1 year)	$200 Skill Boost; Workspace discounts.
Scale Tier	Pre-seed to Series A.	Up to $200,000 (2 years)	$500 Skill Boost; Startup Success Manager.
Scale AI Tier	AI-first; Pre-seed to Series A.	Up to $350,000 (2 years)	Frontier model access (Gemini, Claude).
Web3 Tier	Blockchain-focused.	Specialized Web3 benefits	Partner perks (Alchemy, Nansen, etc).

You can read more about the eligibility for each below:

Start Tier: https://cloud.google.com/startup/pre-funded
Scale Tier: https://cloud.google.com/startup/early-stage
Scale Tier — AI: https://cloud.google.com/startup/ai
Scale Tier — Web3: https://cloud.google.com/startup/web3

Apply to Google Startups Program

Beyond Credits: The Perks

Google has partnered with industry leaders to offer deep discounts and exclusive access (https://cloud.google.com/startup/perks?):

Model Access: Up to $10,000 in credits for Anthropic (Claude) and Fireworks AI (Serverless inference).
Database & Ops: MongoDB Atlas, CockroachDB, and a full year of GitLab Ultimate for free.
Specialized AI Tools: ElevenLabs (33 million free credits), Contextual AI ($1.5k in credits), and more.

If there is a tool you think should be included, you can nominate it here.

4. Google’s 2026 Startup White Papers & Insights

Here is a collection of whitepapers and resources I recommend to bookmark for all founders using Google Cloud.

The Future of AI: Perspectives for Startups (2026): A definitive report for 2026 on building durable software.
The Future of AI 2025 for Startups: Insights from Startups and thought leaders like Founder of LangChain, CEO of Assembly.ai, VC Elad Gil and more.
Startup Setup Best Practices for Google Cloud: A deep-dive guide in setting up your account for Google Cloud
Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems Book by Antonio Gullí.

5. Community & Global Events

Google Cloud Next ‘26

Las Vegas, April 22-24, 2026. The Startup Hub at Mandalay Bay is your home base for Masterclasses on Gemini 3 and 1:1 sessions with Cloud Customer Engineers. Don't miss the Founders Toast!

Events Near You

Don't forget about the many many events both in person and virtual from Deepmind, Google Cloud, and Google developer communities.

Google DeepMind: Luma Event Calendar (Hackathons & Research Sessions)
Google Cloud for Startups (North America): Luma Event Calendar (Technical Office Hours & Workshops)
Google Developer Groups (GDG): Global Event List (Local meetups and DevFests)
Google for Developers: Global Events Directory (Conferences and Summits)

Any Questions?

Save this article for your application season! Got questions? Drop a comment below or connect with me on X/Twitter @WhoInvitedabe or on LinkedIn/in/GoAbeGo.

Talk soon!

Episode 3 of the AI Agent Bake Off: "Build a GTM Agent for Founders in 72 hours"

Abraham Gomez — Mon, 05 Jan 2026 19:33:55 +0000

Think British Bake Off Show... but with AI Agents instead of Cakes! By the way, I am Abe the host of the show.

We starter with a simple challenge…

The Prompt
Using #Gemini and #ADK build a GTM Agent for Founders that is both MultiModel (beyond text) and MultiAgent (not just an AI wrapper) in 72 hours.

The Setup
And that is what our 3 teams sign up for — 1 developer, 1 googler, an AI Studio API Key, and Google’s Agent Development Kit (ADK).

The Knowledge Base
We also provided them with a Go-To-Market Open Source Repo: https://github.com/goabego/ai-gtm-playbook to get them a head-start

And that's all we gave them (okay also we gave them lunch and plenty of coffee) but the learnings were a bountiful: from context stuffing best practices, to quick A2A deployments (but more on that later)...

What will you see in this episode?

We structured the video in three parts: Day of challenge, Demos, and Judges deliberation.

The Day Challenge

The day of shooting we surprised our teams with a mini 2 hour hackathon to really push their agents to the limit with 6 distinct tests - whoever did the completed the most, wins the challenge - full challenge details here.

Challenge 1: The Launchpad (Deployment)
Challenge 2: The Gauntlet (Load Testing)
Challenge 3: On-the-fly feature (Dynamic Adaptation)
Challenge 4: The Open GTM (MCP Exposure)
Challenge 5: The Ambassador (A2A Exposure)
Challenge 6: The Visionary (Multimodal Input)

All teams where able to accomplish at least 3 in a 2 hour period. Which is a big feat knowing they had no idea what the challenge were going to be and the competitive spirit of the teams. Challenges 1,4,5, and 6 where the was completed in the challenge by the teams.

The Demos

Next you will see the details of the teams building their AI Agents using ADK. You will learn about ADK Web, Gemini, Sub Agent architectures, tactics to manage context and so much more. Here is an example of one of the team's architecture diagram (note all is open source an available below).

Note: All code and reference architecturescan be found here

The Judges

Perhaps my favorite part the Q&A portion between the judges and our teams. In this episode we had Ivan (AI DevRel at Google Cloud), Shubham (AI Product Manager @ Google Cloud), and Annie (AI DevRel at Google Cloud). They asked their questions, shared their thoughts, and selected a winner.

Each team was granted 15 mins of Demo and Q&A back to back. The grading criteria where as follows:

TECHNICAL CRITERIA
Criteria	Assessment	Weightage
Proof of ADK Multi Agent System (MAS)	Showcase and the degree of usage of the ADK Loop, Parallel, and Sequential Agents	25%
Leverage a Gen Media Model	Showcase a the degree of usage of Gen Media model (live api, veo3, image, nano banana, etc)	25%
Handling day of shooting challenge	Showcase and the degree of agent handling the day of challenge	20%

CREATIVE CRITERIA
Criteria	Assessment	Weightage
Impact & Relevance	Level of impact and applicability to real-world problems identified	20%
Presentation & Communication	Clarity and persuasiveness of the solution designed through the pitch video	10%

Note: As well as the winner of the 2 hour challenge was considered in the selection process.

Insights

"Insane" AI agents are not reserved for research labs—it's something you can achieve in a weekend with the right tools like Gemini and the Agent Development Kit (ADK). In this episode, three teams raced to build the ultimate "AI Co-Founder" to rescue startups, and while the 72-hour deadline brought real drama—including surprise hackathons and frantic debugging—the results were accessible and inspiring.

You’ll see that you don't need a complex mesh of confusing code to succeed; judges praised simple, sequential patterns that anyone can learn, and the teams utilized open-source playbooks to fast-track their development. From generating superhero avatars to full validation plans in minutes, this challenge shows that once you break a big problem into small sub-agents, building with AI becomes less about coding magic and more about having fun with creativity.

I think one of our Judges said it best:

The best lesson developers can get from watching this hackathon is that don't build agents for agents sake. Leverage the right structure and frameworks that make sense for your use case. Try to work backgrounds not just forward.

Technical Insights

State Injection > Context Stuffing
- The Insight: "Context Window Management" is the hardest problem in agent engineering.
- What we saw: Team Launchpad relied on massive text files and prompt stuffing (2700% prompt density), which works for prototypes but degrades reliability.
- The Winner's Edge: Team Superpowers (Muhammad & Ayo) used State Injection. Instead of passing the entire chat history to every sub-agent, they extracted specific outputs (e.g., "target_audience_json") and injected only that structured data into the next agent's prompt.
- Takeaway: Don't treat your context window like a trash can. Treat it like a precise function argument.
The "Full-Stack Agent" Reality
- The Insight: An Agent is not just a Python script; it is a UI paradigm.
- What we saw: Every team spent ~50% of their code volume on TypeScript/React (.tsx).
- Why it matters: Agents work asynchronously and often slowly. You cannot just have a loading spinner. You need streaming UIs, intermediate state visualization (like GTM Forge’s dashboard), and "human-in-the-loop" confirmation screens.
- Takeaway: If you are an AI Engineer, you need to learn React (or partner with someone who knows it). The "Headless Agent" is a myth for consumer apps.
Parallelism is the only way to solve Latency
- The Insight: Sequential chains are too slow for real-time users.
- What we saw: Team GTM Forge (Daniel & Luis) reduced a 60-minute linear workflow down to ~15 minutes by running agents in parallel (Map-Reduce pattern).
- Takeaway: Architect your agents to fork. If an agent needs to generate a logo, a blog post, and a video script, those should happen simultaneously, not one after another.
Tools are the new API Standard (MCP)
- The Insight: The Model Context Protocol (MCP) is shifting how agents connect.
- What we saw: All teams had to expose tools via MCP. Team Launchpad used fastmcp for speed, while GTM Forge used the native ADK server for robustness.
- Takeaway: Stop writing custom API wrappers just for your bot. Build MCP Servers. This makes your tool portable—usable not just by your agent, but by any agent (or IDE) that speaks MCP.
Deterministic Guardrails Win
- The Insight: Pure probabilistic reasoning (LLM only) is dangerous for complex tasks.
- What we saw: The winning team (Superpowers) didn't just ask the LLM to "do research." They built a "Shared Preview Server" and local storage mechanisms to save artifacts deterministically.
- Takeaway: "Agentic" doesn't mean "Unstructured." The best agents use rigid schemas (Pydantic/Zod) and deterministic code to handle file saving, API calls, and state transitions, reserving the LLM only for the reasoning parts.

Last but not least, Want a more interactive viewing experience?

We created an even more educational experience with cards, code snippets, and useful links. Try it out here: ai-agent-bakeoff.com you can ask questions and we will answer, we also added the open source content there for easier learning.

Also we open source all the contestants source code and architecture diagrams is available in the first card on the web app.

Key Learnings in the WebApp

In the WebApp we dive deeper into the following insights from the Game Show including, but not limited to:

Build standardized MCP servers using Python and Google's ADK.
Implement discovery and execution handlers for seamless tool integration.
Connect agents to enterprise databases using the MCP Toolbox.
Enable collaboration between different AI frameworks using A2A.
Harness Gemini 3 Pro for advanced multimodal agent reasoning.
Deploy agents to production via Vertex AI and GKE.
Rapidly prototype and visualize agent flows using ADK Web.
Scale adoption using the open-source AI GTM playbook.
Optimize performance by using sub-agents to bypass context rot.

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

Abraham Gomez — Tue, 09 Dec 2025 23:46:12 +0000

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: It connects agents regardless of their underlying stack (LangGraph, CrewAI, Semantic Kernel), enabling composite systems.
Distributed Problem Solving: It 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. They share structured inputs and outputs but keep their 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?"

Ingest: The Orchestrator receives the query.
Route: It identifies the "Big Purchase" intent and delegates to the local Big Purchases Agent.
Bridge: Using A2A, the local agent calls the remote Cymbal Bank Agent.
Execution: The remote agent, secure inside the bank's backend, accesses internal tools and databases to fetch financial history.
Return: The data is returned via A2A to the Big Purchases Agent.
Synthesize: The agent calculates affordability, perhaps calling a Visualization Agent to chart a net worth forecast.
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 and 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

The Pattern: Executing multiple independent agents simultaneously and aggregating the results.
The Use Case: Loading a "Financial Health" dashboard. Instead of fetching Account Balances $\to$ Investment Performance $\to$ Rewards sequentially, a parallel flow triggers all three agents at once. This drastically reduces Time-To-First-Byte (TTFB) and perceived latency.

2. Loop Agents (Generator-Critic)

The Pattern: An iterative cycle where one agent produces an output and another critiques it until a threshold is met.
The 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.

By moving the ML directly to the data warehouse, they achieved:

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 data. When planning a trip to Paris, the agent doesn't just hallucinate a hotel; it queries r/travel for actual community recommendations. This "Social Proof" layer adds a level of human trust that raw data cannot provide.

Key Takeaways for Developers

Decompose your Agents: Monolithic prompts are hard to debug. specialized, multi-agent systems are modular and scalable.
Standardize Communication: Use protocols like A2A to prevent tight coupling between your agents.
Ground in Reality: Use SQL/BQML for math and APIs for facts. Don't let the LLM do arithmetic.
UI Matters: A creative interface (like Team Marcus and Sita's "Orchestra" theme) can make complex agentic operations feel intuitive.