DEV Community: Saquib Shahid

A2A + MCP — The Two Protocols That Were the Actual Story of Google Cloud NEXT '26

Saquib Shahid — Fri, 24 Apr 2026 22:37:59 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Hey, I'm Saquib. I've been deep in the backend trenches for a couple of years now, mostly building out Node and Go microservices. Like pretty much every dev in 2026, I spent the last few months messing around with AI. Wiring LLMs into APIs. Breaking stuff. Fixing it. Getting a prototype working on the first try and immediately assuming something is horribly wrong.

When Google Cloud NEXT '26 kicked off, I actually blocked out some calendar time to watch. My feed was absolutely flooded with hot takes on the Gemini Enterprise Agent Platform and the new 8th-gen TPUs. Everyone also had a very loud opinion about that "75% of Google's code is AI-generated" stat.

But honestly? I kept getting distracted by two boring acronyms.

A2A and MCP.

They barely got any stage time. No hype reel. But I genuinely think they were the most important things announced at the whole event. Let me try to explain why.

the problem nobody wanted to say out loud

Every vendor on stage was showing off agents. Salesforce has Agentforce. ServiceNow's got one. SAP too. Microsoft Copilot, obviously. Google's Gemini Enterprise. Basically everyone is shipping agents right now. Which is fine.

But the question I kept coming back to was way less glamorous: how do any of these things actually talk to each other?

In a normal backend setup, when two microservices need to chat, we have a playbook. REST, gRPC, Kafka queues, OpenAPI specs. The whole mess is solved. It's boring and it works.

But with agents? A year ago, the answer was they just didn't. Or worse, they did it through some horrible custom webhook adapter that someone is going to have to babysit from a Slack DM at 2am. Every system spoke its own language. Integration wasn't a feature—it was somebody's entire job.

A2A and MCP fix that exact problem. Google finally stopped treating them like research experiments and started treating them like actual infrastructure.

the mental model that finally made it click

I had to read the docs a few times before I really got it. Here is the summary I wish I had on day one.

MCP is HTTP for agents. A2A is DNS plus HTTP for agents talking to other agents.

MCP (Model Context Protocol) was Anthropic's baby originally. It standardizes how a model reaches out to your tools and databases. Before MCP, if you wanted Gemini to query a database, you had to write a bunch of glue code and pray the model didn't invent a table name. Now, the model speaks MCP, the server speaks MCP, and they just shake hands.

A2A (Agent2Agent) came from Google and got donated to the Linux Foundation. It standardizes how one agent talks to another autonomous agent.

The A2A docs say it best: build with whatever framework, equip with MCP, and communicate with A2A. They aren't competing standards. MCP is how your agent talks down to the database. A2A is how it talks sideways to another agent. That realization saved me a massive headache.

okay, so what did google actually ship?

A lot of this trickled out before NEXT, but the conference is where they put it all together into an actual strategy.

On the MCP side, we got fully managed servers for things like BigQuery, Cloud SQL, and Pub/Sub. You don't deploy anything. You just point your agent at an endpoint. They also turned Apigee into an MCP bridge. This means any REST API you already built instantly becomes a discoverable agent tool with your existing auth layered on top. As a guy who spent way too long last year hand-wrapping APIs for LLMs, that was a huge relief. Auth is all IAM-backed now too, so no more passing API keys around.

On the A2A side, it hit production grade with LangGraph and CrewAI support. Donating it to the Linux Foundation was a big move. They also announced Agent Registry (basically DNS for your internet of agents) and Agent Gateway.

Put it all together, and Google is basically saying they don't need to own the agent itself. They just want to own the highways the agents drive on.

show me the code

I hate architecture diagrams. I need to see the actual implementation. So here is a really minimal setup: a planner agent analyzing data, handing work off to a reporter agent in a completely different service.

Planner first. We'll set it up to hit BigQuery via MCP:

# planner_agent.py
from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool import MCPToolset
from google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams

# Point at Google Cloud's managed BigQuery MCP server.
# No infra to deploy. Auth handled by IAM.
bigquery_tools = MCPToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://bigquery.googleapis.com/mcp/v1",
    ),
)

planner = LlmAgent(
    name="sales_planner",
    model="gemini-3.1-pro",
    instruction=(
        "You analyze sales data in BigQuery and prepare a brief "
        "for the reporter agent. Findings as bullet points only."
    ),
    tools=[bigquery_tools],
)

Notice what's missing there. There are no BigQuery SDK imports or crazy prompt schemas. The managed MCP server just exposes the database as an agent tool. When I ran this the first time, I kept looking for the missing step. There isn't one.

Next, we expose the reporter agent over A2A:

# reporter_server.py
from a2a.server import A2AServer
from a2a.types import AgentCard, AgentSkill

# The Agent Card is the "business card" that other agents fetch.
# Served at /.well-known/agent-card.json automatically.
card = AgentCard(
    name="QuarterlyReporter",
    description="Turns sales briefs into formatted exec reports.",
    version="1.0.0",
    url="https://reporter.example.com",
    skills=[
        AgentSkill(
            id="write_exec_report",
            name="Write executive report",
            description="Takes bullet findings and produces a polished report.",
            input_modes=["text"],
            output_modes=["text", "application/pdf"],
        )
    ],
)

server = A2AServer(agent_card=card, handler=my_report_handler)
server.run(host="0.0.0.0", port=8080)

That Agent Card is the magic part. It's just a tiny JSON doc at a predictable URL. It tells any other agent from any cloud exactly what this bot can do and how to authenticate. It's basically robots.txt for AI.

Finally, we make them talk:

# orchestrator.py
from a2a.client import A2AClient, A2ACardResolver

# Discover what the reporter can do.
resolver = A2ACardResolver(base_url="https://reporter.example.com")
card = await resolver.get_agent_card()

# Open a client against it.
reporter = A2AClient(agent_card=card)

# Run the planner...
findings = await planner.run("Analyze Q1 2026 revenue by region.")

# ...and hand off to the reporter over A2A.
task = await reporter.send_task(
    message={"parts": [{"type": "text", "text": findings}]},
)

# A2A tasks have a real lifecycle so we stream updates back.
async for update in reporter.stream_task(task.id):
    print(update.status, update.artifacts)

Three files and we have a working cross-service handoff. The crazy part is that the reporter could be running on AWS or it could be a Salesforce agent. The planner code wouldn't need to change at all.

the detail most write-ups miss

A lot of the coverage I've seen just says "these are cool." True. But the interesting part is the underlying design.

A2A is basically stealing every good idea from how the early web scaled. Agent Cards live at /.well-known/agent-card.json. That's RFC 8615, the same pattern we use for security.txt. They're using JSON-RPC 2.0 over HTTP and Server-Sent Events. If your system speaks HTTP, it speaks A2A.

Tasks have a normal lifecycle too. Submitted, working, completed. It's the same shape as AWS Step Functions or GitHub Actions. It's boring—and coming from backend land, that's basically the nicest thing I can say about a tech. Clever protocols usually die because nobody wants to actually implement them. MCP and A2A are predictable.

stuff I'm still not sold on

Look, I'm not totally sold yet.

The security surface area here is terrifying. An agent that can auto-discover other agents and pass tasks around is an absolute nightmare for prompt injection or data exfiltration. I'd need a very solid threat model before letting this touch real production data.

Debugging is also going to be awful. Google says everything lands in Cloud Audit Logs. Cool. But tracing a failed task across three different agents built by three different vendors? Prepare for a lot of late nights.

Also, the spec is still moving. A2A is at the Linux Foundation, which means it will evolve. If you build heavily on it today, you will probably be rewriting parts of it next year.

what I'd actually do this week

If you want to get ahead of this, here is my unsolicited advice.

Go run the A2A Python quickstart. It takes maybe an hour and you get a working agent in 50 lines. Then hook a basic agent up to a managed MCP server. BigQuery is probably the easiest to test. Read a real Agent Card—just go look at the JSON and see how the auth and skills are structured. It grounds the whole concept. Just don't overbuild right away. Start with two agents and see what breaks.

Next '26 was Google quietly admitting that no single company will own the agent ecosystem. So they're building the infrastructure instead. A2A is the DNS. MCP is the HTTP. If you learn these protocols now, future-you is going to be really happy about it. That's my bet anyway.

If you are building with A2A or MCP, drop a comment. I'd love to swap notes, especially if you've hit weird OAuth snags between managed MCP servers and non-Google clients. I definitely spent a few hours stuck on that this week.

— Saquib

BrewOS 3000: The $47M Enterprise Coffee Platform That Has Never Made Coffee

Saquib Shahid — Thu, 09 Apr 2026 17:34:58 +0000

This is a submission for the DEV April Fools Challenge, Best Ode to Larry Masinter

What I Built

In 1998, Larry Masinter published RFC 2324 — the Hyper Text Coffee Pot Control Protocol. It defined a new HTTP method (BREW), a new status code (418 I'm a Teapot), and exactly zero practical applications. It was an April Fools joke. It became immortal.

BrewOS 3000 is my love letter to that joke.

It is a NASA mission-control-grade enterprise coffee procurement dashboard that:

Accepts your blood type (affects roast compatibility)
Requires you to select your Existential Mood State (Monday is a valid option)
Makes you pass a CAPTCHA to add milk ("Spell COFFEE backwards")
Asks you to agree that "coffee is a human right and you accept all karmic responsibility for choosing decaf"
Runs a live WebSocket diagnostics log that — I cannot stress this enough — logs [17:22:32] Querying Larry Masinter's ghost... 404
Tracks six real-time metrics including Bean Entropy, Grind Latency, and Quantum Roast Index
Executes a full 8-step async brew sequence with blockchain verification
Always fails with HTTP 418.

Every single time. Without exception. By design.

I am a teapot
Short and stout, here is my spout
Your coffee: denied

🔗 Live demo: htcpcp.vercel.app

Demo

htcpcp.vercel.app

![BrewOS 3000 dashboard showing brew parameters, live diagnostics log reading "Querying Larry Masinter's ghost... 404", and six real-time telemetry metrics in a dark CRT-style terminal UI]

SYSTEM UPTIME: 09:02:28 · ONLINE · NEVER BREWED

Code

saquib-shahid / htcpcp

Dev April fool challenge

title	BrewOS 3000: The $47M Enterprise Coffee Solution That Has Never Brewed a Cup
published	false
description	My submission for the DEV April Fools Content Challenge - Best Ode to Larry Masinter
tags	webdev, humor, javascript, aprilfools, react

🚀 The $47M Mission

Picture this: The year is 2021. Our CEO waited an agonizing four minutes for a latte at a hipster coffee shop. In a moment of pure unadulterated hubris, he decided what the world really needed was not another barista, but a distributed coffee infrastructure platform powered by Web3, Machine Learning, and arbitrary venture capital.

We raised $47M in Series B funding. We hired 200 engineers. We spent two years rewriting our microservices in Rust.

And we have never made a single cup of coffee.

Welcome to [BrewOS 3000], my wildly over-engineered submission for the DEV April Fools Content Challenge 2024 under the "Best Ode to Larry Masinter"…

View on GitHub

How I Built It

Stack: React + Vite, Tailwind CSS v4, deployed on Vercel.

Fonts: Bebas Neue for headers, Share Tech Mono for everything that needed to feel like a submarine terminal. Both doing serious work here.

The aesthetic: Full dark CRT mission-control theme. Amber-on-black. Scanline overlay. Real-time metrics that fluctuate via setInterval to make it look like the servers are working incredibly hard to do nothing.

The brew sequence is a React state machine — eight async steps with artificial delays, each one logging to the live diagnostics panel. Steps include:

Validating blood type against NASA coffee manifest
Verifying bean provenance on-chain
Checking municipal brew permit
Milk authorization CAPTCHA
Blockchain roast consensus (always times out)
Biometric mood analysis
Running 47 pre-flight safety checks
Attempting to brew → 418

The diagnostics log streams these in real time. The progress bar hits 99% and turns red. The 418 modal takes over the screen with the full RFC citation and the haiku.

I originally planned a real Node/Express HTCPCP backend, but realized the true startup move is to fake the entire infrastructure client-side to save on compute costs. We call this "serverless". Investors love it.

Keyboard shortcuts exist, because of course they do. Press B to initiate brew. Press Escape to acknowledge your failure and try again.

Prize Category

Best Ode to Larry Masinter.

Here's why this earns it:

RFC 2324 is one of the greatest pieces of technical writing in internet history. It's a fully specified protocol, complete with BREW and WHEN methods, error codes, and a clause prohibiting the addition of milk "to an Assam Darjeeling". It introduced 418 I'm a Teapot as a serious-looking status code for a joke that has since survived every attempt to remove it from the web. Developers rallied. The code stayed. Larry Masinter won.

BrewOS 3000 does not merely reference RFC 2324. It implements it — faithfully, reverently, and completely uselessly. The BREW request fires. The 418 returns. The teapot wins. Every time.

This is the only correct way to honor a man who made the internet laugh for 28 years and counting.