DEV Community: Sampath Kumar Maddula

What’s New in A2A: v1.0, a Python DX Glow-Up, and a Fresh New Look

Sampath Kumar Maddula — Thu, 02 Jul 2026 00:01:19 +0000

A2A Documentations & New Updates.

🎉 A2A reached v1.0 — a production-ready, open standard for agents to talk to each other. It was created by Google but now it’s maintained under the Linux Foundation by a Technical Steering Committee(TSC) spanning eight companies (AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow).

I have been attending these TSC meetings and met Google’s Software Engineers who are working on A2A. Based on what I saw and understood, this v1.0 is really big news and we are planning more cool and exiting things 😀. For today let us focus on what’s new under the hood in A2A’s v1.0, a Python ( 📦 a2a-python SDK) developer-experience glow-up worth getting excited about, and a fresh new look on the surface to match. ✨

What’s new in v1.0

v1.0 is about making A2A protocol stable, standardized, and enterprise-grade — and building it so the A2A SDKs can keep evolving without breaking everyone down the line. The changes group into four themes: 1️⃣ protocol maturity, 2️⃣ stronger type safety, 3️⃣ a better developer experience, and 4️⃣ enterprise-ready features.

Here’s what’s worth your attention.

→ Enterprise-ready security and identity. Agent Cards can now be cryptographically signed and verified (JWS, per RFC 7515, with JSON Canonicalization per RFC 8785), so you can trust that an agent is who it claims to be. OAuth 2.0 support was modernized too: the Device Code flow (RFC 8628) is in for CLI, IoT, and headless agents, PKCE is supported, and the insecure implicit and password flows are gone.

→ Multi-tenancy, built in. A native tenant field means a single endpoint can serve multiple agents or tenants — no more bolting it on yourself.

→ Listing that scales. A new ListTasks operation adds filtering and cursor-based pagination, so task listing holds up as your agents get busy.

→ Consistent behavior across every transport. Errors are now standardized on google.rpc.Status / ErrorInfo, so you get the same error shape whether you're on JSON-RPC, gRPC, or HTTP+JSON. And version negotiation via the A2A-Version header — with the protocol version declared per interface — means a single agent can support multiple protocol versions at once. That's the mechanism that makes graceful, backward-compatible upgrades possible.

→ A cleaner data model. The big one: text, file, and data are unified into a single Part type — no more separate TextPart / FilePart / DataPart, and no kind discriminator to carry around. Enum values are standardized to SCREAMING_SNAKE_CASE for ProtoJSON compliance, timestamps are ISO-8601 with milliseconds, and tasks now carry createdAt / lastModified. IDs are simple UUIDs (no compound tasks/{id}), and the /v1 HTTP path prefix is gone.

Straight talk: yes, several of these are breaking changes. v1.0 is a genuine version bump, not a coat of paint. The payoff is a protocol that’s stable, standardized, and designed so that future versions won’t keep breaking your integrations.

Want more details? Three links cover it: the What’s new in v1.0 guide (five minutes to find out if anything affects you), the full specification for the canonical reference, and — if you’re on Python — the v1.0 migration guide. Stuck on something? The community hangs out in GitHub Discussions — a good place to ask.

Provably interoperable — the Integration Test Kit

The whole promise of A2A is that agents built by different teams, in different languages, actually interoperate — and the A2A Integration Test Kit (ITK) is how that gets proven rather than asserted. If you ship across SDKs or languages, the public ITK dashboard shows you which combinations are known-good — a daily snapshot of nightly cross-SDK runs (not a live or real-time view). For the full story on how it works, the ITK dashboard deep-dive covers it.

https://a2aproject.github.io/a2a-itk/dashboard/

The Python DX glow-up

Here’s the part I’m genuinely excited about. v1.0 didn’t just tighten the protocol — it gave the Python SDK a real developer-experience glow-up, and most of it lives in one new module: a2a.helpers.

Instead of hunting through scattered a2a.utils.* imports, you get a single consolidated import with friendly factory functions for the things you do all day: building messages, parts, tasks, and artifacts (new_text_message, new_task, new_text_artifact, …); creating the status and artifact update events you enqueue while streaming (new_text_status_update_event, new_text_artifact_update_event, plus data/raw/url variants); and pulling content back out (get_message_text, get_text_parts, get_stream_response_text). One import, far less boilerplate.

The before/after says it best — and spinning up a client got the same treatment, with create_client() (from a2a.client) collapsing the old ClientFactory dance into a single await:

##############################################################
# Before — v0.3: wrapper types by hand, and a client factory
##############################################################
message = Message(role=Role.user, parts=[Part(TextPart(text="hi"))])

factory = ClientFactory()
client = factory.create_client(url)

##############################################################
# After - v1.0: one helper each
##############################################################
from a2a.helpers import new_text_message
from a2a.client import create_client

message = new_text_message("hi", role=Role.ROLE_USER)
client = await create_client(url)

That’s the flavor of the whole release: fewer wrapper types, fewer lines, less to remember. Upgrading an existing agent? The v1.0 migration guide walks you through it — and you can run a v1.0 server with v0.3 compatibility enabled, so you don’t have to migrate every client at once.

A fresh look to match

A milestone like this deserves a face — so the parts you see first got attention too.

A friendlier home. a2a-protocol.org has a redesigned home page and navigation, reorganized around one question: what do you want to do next? Less overwhelming, easier to find your starting point — whether that’s a five-minute “what is A2A?”, the full spec, or the hands-on Python tutorial.

# New Homepage

At the top of the home page, we’ve added Get started and Read the spec buttons, allowing you to instantly jump straight to the resources you need based on your immediate goals.

A2A Home Page — https://a2a-protocol.org/latest/

# Restructured Navigation

We’ve reorganized our previous layout into highly focused, grouped sections, making it effortless to pinpoint your specific topic of interest and dive right into development.

A2A — restructured navigation

# New A2A logo

A cleaner, more consistent mark across the docs, the repo, and everywhere A2A shows up.

A2A New Logo

# Lastly, our new A2A Mascot

A2A now has one: a friendly orange-and-cream, a puppy — sitting, tongue out, wearing a collar with an “A2A” dog tag. It’s the warmth a spec and a governance doc can’t quite carry on their own: approachable, a little playful, and (fittingly for an interoperability protocol) happy to make friends with anyone.

The protocol is grown-up and production-ready; the project should still feel like somewhere you’d want to hang out and contribute.

A2A Mascot

Coming next

One more thing worth flagging: the next post digs into A2A multi-tenancy — how the native tenant model dramatically simplifies building multi-agent applications, letting a single deployment serve many agents and tenants cleanly. If you’re building anything beyond a single agent, it’ll be worth your time. More soon.

What to do next

To see what changed, check What’s new in v1.0 guide — five minutes to find out if anything affects you.
Need to upgrade your Python A2A Agent? Start with the migration guide — and remember you can run a v1.0 server with v0.3 compatibility while you transition.
To check inter-op for A2A app, start with ITK compatibility dashboard.

Community Request: We are actively looking to grow our A2A community and expand our A2A blog content. If you have ideas, feedback, or unique insights, your suggestions are incredibly welcome!

Docker for Agents: A Backend Engineer’s Introduction to A2A

Sampath Kumar Maddula — Mon, 15 Jun 2026 03:25:48 +0000

A2A Introduction Post

A2A is a lightweight wrapper — like Docker. Your app stays exactly as it is; you add the wrapper, and it gains the ability to talk to any agent in the world. In this posts, I share the three concepts you actually need to know.

Introduction

You built an agent. It works. Now someone asks the obvious next question: can it talk to the agent another team built?

Today, the answer is usually, “Only if we write a custom integration for each one”. That’s the same trap REST APIs solved for web services — and it’s exactly the trap A2A (Agent-to-Agent protocol) is built to get us out of.

Here’s the mental model I’d lead with, because every backend engineer already owns it:

A2A is a lightweight wrapper, like Docker. Your Agentic app lives exactly as it is. You wrap it with A2A, and it automatically gains the ability to be discovered by — and talk to — any agent in the world. You didn’t rewrite your app; you made it portable.

With Docker you wrap your app, and it runs anywhere. Similarly, wrap your agent with A2A, it talks to any Agents across the world. In this post, I share the three concepts you need to understand to make your agent interoperable.

This is Part 1 of a series. Later parts go deep on multi-tenancy (serving many agents behind one host), a 60-second Quickstart, and more. Today we stay at the intro: the smallest complete mental model you can hold in your head.

What you’ll learn

The Agent Card — how an agent advertises who it is and how to reach it (discovery).
Tasks & messages — how a client asks your agent to do work.
The EventQueue & status updates — why long-running work doesn’t block, and the weightlifting A2A does for you.

That’s it. Three concepts. Everything else (auth schemes, multi-tenancy, extended cards) is a later post — and you won’t need it to ship your first interoperable agent.

The mental model, in one diagram

The wrapper sits between any A2A client and your unchanged app:

A2A Intro — Mermaid Chart 1

And here’s the same interaction over time — discovery, then the task lifecycle:

A2A Intro — Mermaid Chart 2

Now the three concepts.

1. The Agent Card — discovery

Before two agents can work together, one has to find the other and learn what it can do. In A2A, every agent publishes an Agent Card : a small, structured description served at a well-known URL. It says who I am, what I can do (skills), where to reach me (interfaces/endpoints), and what features I support (e.g. streaming).

# Conceptual (trimmed from the hello-world sample)
public_agent_card = AgentCard(
    name="Hello World Agent",
    description="Just a hello world agent",
    version="0.0.1",
    capabilities=AgentCapabilities(streaming=True),
    supported_interfaces=[
        AgentInterface(protocol_binding="JSONRPC",
                       url="http://127.0.0.1:9999"),
    ],
    skills=[skill], # Not the same Agent skills
)

A client fetches this card from an A2A instance endpoint, reads it, and knows exactly how to talk to you — no out-of-band docs, no bespoke client. This is the part that makes “any agent in the world” literally true.

Tips: Discovery is the front door — if you publish a good Agent Card, everything else (including the routing tricks in the multi-tenancy post) falls out of it.

2. Tasks & Messages — asking an agent to do work

Once a client has your card, it sends a message (think: the request — text, and optionally files/structured parts). Your wrapper turns that into a Task — the unit of work A2A tracks from start to finish.

# Conceptual: the wrapper turns an incoming message into a Task
task = new_task_from_user_message(context.message)
await event_queue.enqueue_event(task)

A message is the “what I want.” A task is the “thing being worked on,” with a lifecycle and an id the client can follow. Your app’s actual logic — the LLM call, the database query, the tool use — runs unchanged underneath.

Tip: If you can think in request → unit-of-work → result, you already understand tasks and messages.

3. The EventQueue & Status updates — A2A does the weightlifting

Here’s the concept that earns A2A its keep. Agents are slow — a real task can take seconds or minutes. You don’t want to block, and you don’t want to hand-roll streaming, polling, and reconnects for every client.

So you don’t. Your app just posts events to an EventQueue — “working,” “here’s a partial result,” “done” — and A2A handles delivering them to the client however and whenever the client prefers (streaming now, or polling later).

# updater: Helper to update tasks
updater = TaskUpdater(event_queue, task_id=task.id,
                      context_id=task.context_id)

await updater.update_status(TaskState.TASK_STATE_WORKING,
                            message=new_text_message("Processing request..."))

# my_agent.invoke: your app's logic
# (for simplicity, below code assume text input and output)
result = await my_agent.invoke(query)

await updater.add_artifact(parts=[new_text_part(text=result)])

await updater.update_status(TaskState.TASK_STATE_COMPLETED,
                            message=new_text_message("Request is completed!"))

Read that again from the app’s point of view: you posted three updates and an artifact. You wrote zero networking code. That’s the weightlifting — A2A manages client communication so your agents are truly interoperable and can work across teams, services, and continents. You focus on your app and its executions.

Tip: Any work that isn’t instantaneous (i.e. almost all real agent work). Post updates as you go and let A2A meet each client where it is.

The Complete Flow

These three aren’t separate features you choose between — they’re one flow. Discovery (the card) tells a client how to send a message; the message becomes a task; the task streams updates back through the EventQueue.

Get the Agent Card right and the rest composes naturally. When you later have many agents behind one host, the same card-driven discovery is what makes routing tractable — which is exactly where Part 2 (multi-tenancy) picks up.

Recap/ Key Takeaways

A2A is Docker for agents. Wrap your app; it stays the same and gains interoperability. You don’t rewrite — you make portable.
Three concepts are the whole intro: the Agent Card (discovery), tasks & messages (the request and the unit of work), and the EventQueue (async status updates).
A2A does the weightlifting. You post status updates; A2A handles streaming/polling/reconnects so any client can keep up.
Discovery is the front door. A good Agent Card makes “talk to any agent” literally true — and sets up everything that comes later in the series.

Demo

To get started with a simple hands-on-demo:

A2A Server instance — Step

# To start an A2A instance
$ git clone https://github.com/a2aproject/a2a-samples.git
$ cd a2a-samples/samples/python/agents/helloworld
$ uv run .

Client instance in a new terminal

# To start an A2A instance
$ git clone https://github.com/a2aproject/a2a-samples.git
$ cd a2a-samples/samples/python/agents/helloworld
$ uv run test_client.py

To learn more:

Read the spec → https://a2a-protocol.org/latest/
Star the project → https://github.com/a2aproject/A2A

A question for you: what’s the first agent you’d wrap in A2A — and which other team’s agent would you most want it to talk to? That second answer is usually the one that proves the protocol’s worth.

Breaking Down Agent Silos: The A2A Integration Test Kit Dashboard is Here

Sampath Kumar Maddula — Tue, 26 May 2026 04:53:18 +0000

Interoperability shouldn’t be an afterthought. In a world of diverse AI frameworks, the A2A protocol is building the common language for agents to collaborate seamlessly. Today, we’re making that mission measurable.

Introduction

The A2A protocol is more than just a specification; it’s an open communication language designed for independent agents to talk and work together. Originally developed by Google and now part of the Linux Foundation, A2A is the definitive common language for agent interoperability in an ecosystem where agents are built by different vendors across diverse frameworks.

Why Interoperability Matters

Building a standalone agent is one thing, but getting a Python agent to collaborate with a Go or Rust agent without custom glue code is the real challenge. While the A2A protocol establishes the common language for agents to collaborate, the Integration Test Kit (ITK) and its Dashboard provide the vital verification and visibility needed to maintain consistency. The ITK acts as a toolkit to verify compatibility across different SDK implementations by routing test messages, while the Dashboard centralizes this data(test results) into a holistic interoperability matrix. This ensures that agents built across diverse frameworks can integrate robustly throughout the protocol’s evolution.

Note: We recently presented this dashboard to the A2A Technical Steering Committee (TSC) to gather feedback. Please share your feedback.

How the Dashboard Works

The A2A ITK dashboard performs automated interoperability checks between various A2A SDKs. For example, for Python SDK ITK tests, it utilizes the latest SDK code from its GitHub repository and runs cross-compatibility checks against the following versions:

Stable Versions: Python v1.0 and Go v1.0
Legacy Versions: Python v0.3 and Go v0.3

Support for additional SDK languages and versions will be expanded in future iterations.

Understanding the Dashboard Layout

To provide comprehensive and detailed metrics, the ITK Dashboard is organized into two distinct sections.

A. Summary Table (Holistic Picture)

The summary table below provides a holistic view of how the current SDK interoperates with others. This view includes checks for stable versions like Python v1.0 and v0.3, as well as other SDKs such as Go, evaluated across various behaviors and protocols (e.g., JSON-RPC, gRPC, and HTTP/JSON).

B. Pairwise Interoperability Matrices

The pairwise interoperability matrices in the section below drill down into pairwise compatibility. These matrices verify full compatibility between specific versions, ensuring robust integration throughout the protocol’s evolution.

Use this section to debug niche edge cases or to verify if a protocol upgrade will safely support legacy clients in production.

Status Legend

PASS: The feature is fully functional and compliant between the tested versions.
FAIL: A regression or incompatibility was detected. Investigation is required.
Not Covered: Test cases for this specific feature combination have not yet been implemented.

🚀 Get Involved & Next Steps

As an evolving tool designed to maintain the stability of the A2A ecosystem, we encourage your participation. Here is how you can take action right now:

Spot a Failure? If you notice a FAIL status on a feature you rely on, please check the active issues or sync with the team in the#a2a-tck Discord channel.
Contribute Test Cases: Help us expand our coverage! If you are developing new features for any A2A SDKs, ensure you add corresponding integration tests to theITK GitHub Repository.
Track Upcoming Support: We are actively working on expanding our test matrices to include TypeScript/Node.js , Java, Rust , and .NET environments soon. Keep an eye on our ITK Roadmap for delivery timelines.

Introducing the Whitepaper on building Secure Multi-Agent Framework on Google Cloud

Sampath Kumar Maddula — Thu, 23 Apr 2026 07:35:33 +0000

Building agents is one thing. Building them to be enterprise-ready and secure is a completely different challenge. When agents start acting across systems and making decisions autonomously, your security strategy has to evolve from model-level guardrails to full-system defense-in-depth.

This new whitepaper breaks down how to build a secure ‘Warranty Claim System’ (a practical usecase for your better understanding and) using the Gemini Enterprise Agent Platform.

https://services.google.com/fh/files/events/agent_security.pdf

Here’s the blueprint for securing the Agentic future:

🏗️ Build with Intent

→ Agent Development Kit (ADK): Native support for session management and tool-level authentication.

→ Deterministic Callbacks: Using BeforeToolCallback to validate inputs (like serial numbers) before they ever hit your backend.

→ Hybrid Runtimes: Seamlessly bridging managed Agent Runtimes with custom Cloud Run environments.

🚀 Scale Safely

→ Identity-Centric Design: Every agent gets a unique, cryptographic Agent Identity (SPIFFE-backed). No more over-permissioned service accounts.

→ Human-in-the-Loop (HITL): Built-in confirmation primitives to pause high-stakes actions for explicit approval.

→ Memory Isolation: Ensuring long-term context is securely mapped and isolated per user session.

🛡️ Govern & Protect

→ Agent Gateway: The central control plane for all ingress and egress. It intercepts every call to authenticate and authorize in real-time.

→ Model Armor Integration: Automatically scrubbing PII and neutralizing prompt injections/jailbreaks inline.

→ Dual Guardrails: Combining IAM boundaries (Access Control) with Semantic Governance (Intent Control) to prevent “Shadow AI.”

📊 Observe & Defend

→ Chain-of-Thought Tracing: Using Cloud Trace to visualize why an agent made a decision, not just what it did.

→ Virtual Red-Teaming: Automated, AI-driven adversarial simulations to stress-test your boundaries before attackers do.

💬 Closing thoughts: “Its time to shift from building chatbots to “Secure Autonomous Worker”.

📚 Here are some resources to get you started!

→ AgentSecurity PDF: https://services.google.com/fh/files/events/agent_security.pdf

→ Google SAIF (Secure AI Framework): https://saif.google/secure-ai-framework/saif-map

→ Agent Identity & SPIFFE : https://docs.cloud.google.com/iam/docs/agent-identity-overview#spiffe-identity

→ Cloud Trace: https://docs.cloud.google.com/trace/docs/overview

→ Agent Gateway: https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview

Master Your Workflow: Top Gemini CLI Commands You Should Know | Gemini CLI CheatSheet

Sampath Kumar Maddula — Fri, 30 Jan 2026 07:02:00 +0000

Picture this : you’re deep in your coding workflow. You need to refactor a complex function, write a clear and concise commit message for your latest changes, and then figure out an obscure shell command to deploy your work. Each task requires switching context — moving from your editor to a browser, then to your Git client, and back again. It’s a constant juggling act that breaks your focus.

What if you could do all of this from one place, your terminal? The Gemini CLI brings the power of Google’s state-of-the-art AI directly to your command line, acting as a seamless, context-aware pair programmer. It’s designed to understand your project, streamline your tasks, and keep you in the flow.

🚀 Getting Started: Your First Steps

Before you can master your workflow, you need to get set up and oriented. These commands are the foundation.

/init 🎬: This is where your journey should begin. Running /init in your project directory allows Gemini to analyze your codebase and create a GEMINI.md file.
/about ℹ️: Curious about your setup? This command quickly displays your Gemini CLI version, the underlying model being used, and your current authentication method.
/auth 🔑: Security and access are paramount. The /auth command lets you configure how you authenticate with Google's AI services.
/help & /docs 📚: The /help command is your go-to for a quick overview. For more details, /docs opens the full documentation in your browser.
/quit 👋: When you’re done for the day, simply use /quit to exit the Gemini CLI application.

🛠️ Core Workflow Commands

These are the commands you’ll use day-to-day to interact with Gemini and your codebase.

! (Shell Commands) 🐚: This is one of the most powerful features. Press SHIFT + 1 to enter "shell mode," allowing you to execute shell commands or describe them in natural language.
/tools 🧰: Ever wonder what capabilities Gemini has? The /tools command lists all available tools Gemini can use to help you.
/editor ✍️: Pro-Tip: For complex, multi-line prompts, use /editor to set your preferred external editor (like Vim or VS Code), then use Ctrl+X to open it.

💬 Managing Your Conversations

A conversation with Gemini is a valuable asset. Here’s how to manage it effectively.

/chat (save, resume, list, delete, share) 💾: The /chat command is a powerful tool for managing your session history. save a conversation, resume it later, or share it as a file.
/clear 🧹: Need a fresh start? /clear will wipe the screen and your current conversation history.
/compress 🧠: When a conversation gets long, /compress intelligently summarizes the context to keep things focused.

🎨 Customization and Stats

Tailor the CLI to your liking and keep an eye on your usage.

/theme 🖌️: Customize your experience. The /theme command allows you to change the look and feel of the Gemini CLI.
/stats 📊: Curious about your usage? /stats provides statistics for your current session, including model and tool usage.

⌨️ Gemini CLI Keyboard Shortcuts You Should Know

To work even faster, it’s worth learning a few essential keyboard shortcuts.

ESC: Cancel a long-running task or clear your input.
Ctrl+C: Quit the application (press twice).
Ctrl+X / Meta+Enter: Open your input in an external editor.
Enter: Send your query to Gemini.

✨ Common Use Cases to Try Today

Here are a few practical ideas to get you started:

Quick Refactoring: Use @ to provide a file as context (e.g., @src/utils.py) and ask Gemini: "Refactor the calculate_total function in this file to be more readable."
Commit Message Generation: Run !git diff --staged and then ask Gemini: "Based on the diff, write a conventional commit message."
Command-Line Coach: Paste a complex shell command and ask: tar -xzvf archive.tar.gz "What do each of these flags do?"

╭───────────────────────────────────────────────────────────────────────────╮
│ > tar -xzvf archive.tar.gz what does each flag do │
╰───────────────────────────────────────────────────────────────────────────╯

✦ Of course. The command tar -xzvf archive.tar.gz is used to decompress and extract files from a gzipped tar archive.

  Here is a breakdown of what each flag does:

   * -x: eXtract. This tells tar to get files out of the archive.
   * -z: gZip. This tells tar to decompress the archive using gzip. This is necessary for files ending in .gz.
   * -v: Verbose. This makes tar list each file as it is being extracted, so you can see the progress.
   * -f: File. This flag must be followed by the name of the archive file you want to process (in this case, archive.tar.gz).

  You can think of the command as saying: "eXtract the gZipped contents Verbosely from the File named archive.tar.gz."

🎉 Takeaway: You’re One Step Ahead!

Congratulations on making it through this guide! By familiarizing yourself with these commands and workflows, you’re already one step ahead of many developers who might not be tapping into the full potential of having an AI assistant directly in their terminal.

Thank you for investing the time to level up your skills. We encourage you to start integrating these commands into your daily routine. You’ll be surprised at how much time you can save and how much more you can accomplish.

Now we’d love to hear from you! What new command did you learn that you’re most excited to try? Share your thoughts in the comments below!

The Six Essential Protocols Powering the AI Agent Ecosystem

Sampath Kumar Maddula — Tue, 27 Jan 2026 08:19:00 +0000

AIAgents #Protocols #AIDevelopment #MCP #A2A #AgentEconomy #AIIntegration

TL;DR : Six protocols are emerging as the foundation of AI agent architecture: MCP (tool access), A2A (agent collaboration), AG-UI (UI communication), A2UI (UI generation), AP2 (payments), and UCP (commerce). Together, they enable agents to interact seamlessly with tools, other agents, users, and commerce systems. Understanding these protocols today positions you at the forefront of the AI agent revolution.

Intro

As AI agents become increasingly sophisticated, the need for standardized communication protocols has never been more critical. Just as the internet was built on protocols like HTTP and TCP/IP, the emerging AI agent ecosystem is being shaped by a new generation of protocols that enable seamless interaction between agents, tools, users, and commerce systems.

Having worked extensively with AI agents over the past year, I’ve identified six foundational protocols that are shaping how agents interact with the world around them. Each protocol addresses a specific challenge in the agent ecosystem, and together they form the backbone of what I believe will be the standard architecture for AI agent applications.

The Protocol Stack: From Tools to Commerce

1. MCP: Model Context Protocol (Agent 🤖 to Tools ⚙️)

Purpose: Connects agents to external tools and data sources seamlessly.

Key Concept: “One connector. Every tool.”

The Model Context Protocol solves a fundamental challenge: how do agents interact with the thousands of tools and data sources available today? Rather than building custom integrations for each tool, MCP provides a unified interface that allows agents to connect to databases, APIs, files, calendars, calculators, and virtually any other tool through a single protocol.

Why it matters: Without MCP, every agent would need custom code for every tool integration. With MCP, agents can instantly access any MCP-compatible tool, dramatically reducing development time and expanding capabilities.

2. A2A: Agent-to-Agent Protocol (Agent 🤖 to Agent 🤖)

Purpose: Enables agents to discover, coordinate with, and delegate tasks to other agents.

Key Actions: Discover, Coordinate, Delegate.

The A2A Protocol addresses the reality that no single agent can do everything. In complex workflows, agents need to collaborate. For example, an Inventory Agent might need to work with a Research Agent to understand market trends and a Pricing Agent to set optimal prices.

Real-world scenario: Imagine a supply chain optimization task where multiple specialized agents (logistics, inventory, demand forecasting) need to coordinate to minimize costs while maintaining service levels.

3. AG-UI: Agent-to-Frontend Protocol (Agent 🤖 to Frontend 📱)

Purpose: Manages the critical interaction layer between agents and user interfaces.

Key Functions: Streaming state updates, handling approval workflows, maintaining synchronization.

AG-UI an open, lightweight, event-based protocol that standardizes how AI agents connect to user-facing applications. AG-UI is designed to be the general-purpose, bi-directional connection between a user-facing application and any agentic backend.

Example: When an agent needs to access sensitive data or perform a high-stakes action, AG-UI manages the approval flow, presenting the request to the user and waiting for confirmation before proceeding.

4. A2UI: Agent-to-User Interface (Agent 🤖 to User Interface 📱)

Purpose: Empowers agents to create dynamic, context-appropriate user interface elements.

Key Concept: Moving beyond plain text to rich, interactive experiences.

A2UI is an open standard and set of libraries that allows agents to “speak UI.” Agents send a declarative JSON format describing the intent of the UI. The client application then renders this using its own native component library (Flutter, Angular, Lit, etc.)

Benefit: This creates a more intuitive and efficient user experience. For instance, instead of asking users to type out complex configuration options, an agent can generate a form with appropriate validation and helpful tooltips.

AG-UI vs A2UI : Think of A2UI as the blueprint for UI widgets and AG-UI as the secure communication channel moving them between the AI (backend) and your app (frontend).

5. AP2: Agent Payment Protocol (Agent 🤖 to Payment Interface 💳)

Purpose: Enables secure, auditable financial transactions for autonomous agents.

Key Features: Cryptographic proof at every step, granular permission controls.

The AP2 Protocol tackles one of the most challenging aspects of autonomous agents: handling money. It implements a three-stage mandate system:

Intent Mandate: What the agent is authorized to do (e.g., “Buy shoes under $150”)
Cart Mandate: What the agent has selected
Payment Mandate: The actual transaction execution

Security focus: Every step is cryptographically signed and auditable, ensuring agents can only act within their authorized boundaries.

6. UCP: Universal Commerce Protocol (Agent 🤖 to Commerce 🛍)

Purpose: Standardizes commerce interactions across different retailers and platforms.

Key Concept: “One standard. Every retailer.”

UCP solves the fragmentation problem in e-commerce. Instead of agents needing to understand dozens of different checkout flows, product schemas, and API formats, UCP provides a unified interface for product search, cart management, checkout, and delivery tracking across any compatible retailer. (UCP is built on top of AP2.)

Impact: This enables true shopping agent experiences where a single agent can help users find and purchase products from multiple stores without custom integrations for each retailer.

The Bigger Picture: An Integrated Ecosystem

These six protocols aren’t just independent standards — they work together to create a complete ecosystem:

Real-World Impact: How These Protocols Transform Daily Work

Let me share a practical example. My friend runs a small marketing agency and recently started using AI agents. Here’s what changed:

Before protocols : She had separate tools for project management (Asana), analytics (Google Analytics), client communication (Slack), and invoicing (QuickBooks). Her AI assistant could only help with basic tasks in isolation.

After MCP adoption : Her AI assistant now connects to all these tools through a single protocol. When a client emails about campaign performance, the assistant automatically:

Pulls the latest analytics data
Checks project status in Asana
Drafts a comprehensive update email with actual metrics
Suggests next steps based on the data

The game-changer? She didn’t need to build custom integrations for each tool. The MCP-compatible assistant just worked with everything out of the box.

The multiplier effect with A2A : When she needs deeper analysis, her main assistant delegates to specialized agents — one for competitive analysis, another for content optimization. They collaborate behind the scenes and return unified recommendations.

This isn’t some far-off vision. It’s happening now. The protocols are removing the friction that kept AI assistants from being truly useful in real business workflows.

Looking Ahead: The Protocol-First Future

As someone who’s been building with AI agents, I’m convinced that these protocols — or something very similar — will become as fundamental to AI applications as REST APIs are to web services today. The teams building on these protocols now are positioning themselves at the forefront of the AI agent revolution.

A question for the community: Which of these protocols do you see as most critical for your use cases? Are there gaps that need addressing? I’d love to hear about your experiences building agent-based systems and the integration challenges you’ve faced.

AIAgents #Protocols #AIDevelopment #MCP #A2A #AgentEconomy #AIIntegration

Originally published at https://www.linkedin.com.

Gemini 2.5 Flash vs. Gemini 2.0 Flash: A New Era for AI Image Generation

Sampath Kumar Maddula — Thu, 04 Sep 2025 18:20:22 +0000

Google has once again pushed the boundaries of generative AI with the release of Gemini 2.5 Flash Image (Preview), a significant upgrade to its predecessor, Gemini 2.0 Flash Image. While both models offer impressive image generation capabilities, Gemini 2.5 Flash introduces a suite of new features and enhancements that provide you with unprecedented creative control and higher-quality outputs. In this blog post, we will delve into the key differences between these two models, highlighting the advancements that make Gemini 2.5 Flash a game-changer for creators and developers.

(If you prefer, you can also read this post in Medium | Dev.to | Github)

Key Advancements in Gemini 2.5 Flash

Conversational Editing and Iterative Refinement: One of the most significant improvements in Gemini 2.5 Flash is its ability to engage in conversational editing. This means you can now refine and edit images through a natural language dialogue. Instead of starting from scratch with a new prompt for every minor adjustment, you can provide iterative feedback. For instance, you can ask the model to "make the sky a deeper blue" or "add a dog in the background," and it will make the changes while preserving the rest of the image. This feature was more limited in Gemini 2.0, making the creative process in 2.5 much more fluid and intuitive.

Multi-Image Fusion and Composition: Gemini 2.5 Flash introduces multi-image fusion, a powerful feature that allows you to combine up to three images to create a single, seamless visual. This opens up a world of creative possibilities, from placing a product in a new environment to creating surrealist art. While Gemini 2.0 had some capabilities in this area, 2.5 takes it a step further with more sophisticated blending and composition, resulting in more photorealistic and coherent images.

Character and Style Consistency: Maintaining a consistent character or style across multiple images has always been a challenge for AI image generators. Gemini 2.5 Flash addresses this with enhanced character and style consistency. You can now generate images of the same character in different scenes, outfits, or poses, and the model will maintain their key features and appearance. This is a massive leap forward for storytelling, branding, and any application that requires a consistent visual identity.
Improved Visual Quality(Aspect ratio) and Text Rendering: Gemini 2.5 Flash boasts a noticeable improvement in overall visual quality. The images generated are more detailed, vibrant, and photorealistic than those from Gemini 2.0. Furthermore, the model's ability to render text within images has been significantly enhanced. This means you can create posters, invitations, and other designs with clear, legible text, a task that was often a struggle for previous models.

Here is the link to download above image: https://msampathkumar.github.io/blog/gemini-2.5-flash-image-preview-final-download.png

The Verdict: A Leap Forward in Creative Control
While Gemini 2.0 Flash was a powerful tool in its own right, Gemini 2.5 Flash represents a significant evolution in AI image generation. The introduction of conversational editing, multi-image fusion, and enhanced consistency gives creators an unparalleled level of control over the final output. These advancements, combined with the improvements in visual quality and text rendering, make Gemini 2.5 Flash an indispensable tool for anyone looking to push the boundaries of their creativity. As AI-powered image generation continues to evolve, Gemini 2.5 Flash has set a new standard for what's possible.

Google Cloud's GKE tops 2025 Magic Quadrant for Container Management

Sampath Kumar Maddula — Mon, 25 Aug 2025 12:25:56 +0000

Thrilled to share that for the third year in a row, Gartner has recognized Google as a Leader in the 2025 Magic Quadrant for Container Management! 🎉

As someone who loves working with Google Cloud, GKE has always been a personal favorite of mine, right up there with GCLB and Gemini. It's fantastic to see this powerful tool get the recognition it deserves.

For me, GKE is a game-changer for container orchestration, making it so much easier to manage and scale containerized applications. It's a key part of modernizing our infrastructure and embracing a cloud-native approach.

Check out the full report here: https://cloud.google.com/blog/products/containers-kubernetes/2025-gartner-magic-quadrant-for-container-management-leader

Learn how to create a chatbot and deploy to Cloud in few mins.

Sampath Kumar Maddula — Thu, 10 Jul 2025 15:04:26 +0000

Sampath Kumar Maddula

Jul 9 '25

How to build & deploy a simple Streamlit chatbot using Gemini 2.5 Flash Lite

#gemini #streamlit #googlecloud

3 min read

How to build & deploy a simple Streamlit chatbot using Gemini 2.5 Flash Lite

Sampath Kumar Maddula — Wed, 09 Jul 2025 10:24:49 +0000

In this blog post, I will show you how to use the Gemini Flash model to build a chatbot using Streamlit. Compared to my previous post in Medium.com, here I use the latest version of Streamlit and also the new Google GenAI SDK.

Google has offered Gemini Models services in 2 -3 different ways. For those who are following regular updates, these are easy to grasp, but for the general crowd this has become a slight challenge due to the rapid changes and updates in AI/LLM topics.

Personally, I have felt that AI updates are like unexpected storms 🌪️. So here is the short version. From a programmer’s lens 🧐, Google offered Gemini Models access in 3️⃣ ways: (1) Google AI Studio API Keys (2) Google Cloud Project — Application Default Credentials (ADC) (3) Google Cloud Gemini API keys.

(Off-topic: I have used all these 3️⃣ ways and I find using Google Cloud ADC is my preferred option. This is because it is easy to use and feels more secure than others. In production environments, I prefer to use Terraform code to update my service accounts to have the required credentials.)

The Google-GenAI SDK acts as a standalone SDK for all these 3️⃣ ways of accessing Gemini Models. Also switching the access methods takes only a 2–3 lines of code. If you like to use ENVIRONMENT variables, or a .env file then your code becomes more portable. To learn more about, check https://github.com/googleapis/python-genai/

Now lets start with build Streamlit chatbot with Gemini 2.5. I have already written the necessary code in Github.

Download the code
Source: https://github.com/GoogleCloudPlatform/devrel-demos/tree/main/ai-ml/gemini-chatbot-app/lesson03

git clone git@github.com:GoogleCloudPlatform/devrel-demos.git
cd devrel-demos/ai-ml/gemini-chatbot-app/lesson03

Setup

Create a virtual environment to install dependencies.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

If you like to use UV, then

uv venv
uv add -r requirements.txt

Mandatory steps to access Gemini Models from your Google Cloud Project.
I have installed the Gcloud tool and used Application Default Credentials to get the credentials.

If you want to run the code in Google Cloud project, then you need to update respective service-account with the required permissions. For details, check out this user-managed service account article.

Run the code (locally in CLI)
Let’s run the code locally using the python command. This allows you to have a quick chat with Gemini from CLI and also allows you to do pre-check for the Streamlit Web application to authenticate and get the response from the Gemini Model.

python llm.py

Samples Logs:

(venv) sampath:lesson03 sampathm$ python llm.py 
Chat session ID: 4563963584
Enter your question (or 'exit' to quit)
User: Hi there
Model: Hello! 👋 How can I help you today?
User: exit
Exiting the chat session. Goodbye!
(venv) sampath:lesson03 sampathm$

Run the Application (locally in Google Chrome)

streamlit run streamlit_app.py

Samples Logs:

(venv) sampath:lesson03 sampathm$ streamlit run streamlit_app.py
 You can now view your Streamlit app in your browser.
  Local URL: http://localhost:8501
  Network URL: http://192.0.0.2:8501
  For better performance, install the Watchdog module:
  $ xcode-select --install
  $ pip install watchdog

Chat session ID: 4604152912
2025-07-07 18:54:50,592 - INFO - New chat session initialized.

Deploy the app to Cloud RUN

bash deploy.sh

Example Logs

(venv) sampath:lesson03 sampathm$ bash deploy.sh 
Building using Buildpacks and deploying container to Cloud Run service [simple-app] in project [...] region [europe-north1]
⠹ Building and deploying... Uploading sources.                                                      
  ⠹ Uploading sources...                                                                            
  . Building Container...                                                                           
✓ Building and deploying... Done.                                                                   
  ✓ Uploading sources...                                                                            
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds
  ;region=europe-north1/XXXX-XXX-XXXX-XXXX-XXXX?project=0001110001110].                 
  ✓ Creating Revision...                                                                            .
  ✓ Routing traffic...                                                                              
  ✓ Setting IAM Policy...                                                                           
Done.                                                                                               
Service [simple-app] revision [simple-app-00004-hs7] has been deployed and is serving 100 percent of traffic.
Service URL: https://simple-app-0001110001110.europe-north1.run.app
(venv) sampath:lesson03 sampathm$
(venv) sampath:lesson03 sampathm$

Wether you deploy to Cloud Run or run locally, here is a preview of the application.

Chatbot Preview

If you have reached this far, then I believe you have successfully deployed your Chatbot web application on Google Cloud Platform.

Congratulations! 🎉👏🎊

Conclusion

In this lesson, we learned how to deploy a simple web application using Google Cloud Run. We also learned about the different components of a container.

My Medium repost: https://medium.com/google-cloud/how-to-build-deploy-a-simple-streamlit-chatbot-using-gemini-2-5-flash-lite-8398e4d29819

DEV Community: Sampath Kumar Maddula

What’s New in A2A: v1.0, a Python DX Glow-Up, and a Fresh New Look

What’s new in v1.0

Provably interoperable — the Integration Test Kit

The Python DX glow-up

A fresh look to match

Coming next

What to do next

Docker for Agents: A Backend Engineer’s Introduction to A2A

Introduction

What you’ll learn

The mental model, in one diagram

1. The Agent Card — discovery

2. Tasks & Messages — asking an agent to do work

3. The EventQueue & Status updates — A2A does the weightlifting

The Complete Flow

Recap/ Key Takeaways

Demo

Breaking Down Agent Silos: The A2A Integration Test Kit Dashboard is Here

Interoperability shouldn’t be an afterthought. In a world of diverse AI frameworks, the A2A protocol is building the common language for agents to collaborate seamlessly. Today, we’re making that mission measurable.

Introduction

Why Interoperability Matters

How the Dashboard Works

Understanding the Dashboard Layout

A. Summary Table (Holistic Picture)

B. Pairwise Interoperability Matrices

Status Legend

🚀 Get Involved & Next Steps

Introducing the Whitepaper on building Secure Multi-Agent Framework on Google Cloud

Master Your Workflow: Top Gemini CLI Commands You Should Know | Gemini CLI CheatSheet

🚀 Getting Started: Your First Steps

🛠️ Core Workflow Commands

💬 Managing Your Conversations

🎨 Customization and Stats

⌨️ Gemini CLI Keyboard Shortcuts You Should Know

✨ Common Use Cases to Try Today

🎉 Takeaway: You’re One Step Ahead!

The Six Essential Protocols Powering the AI Agent Ecosystem

AIAgents #Protocols #AIDevelopment #MCP #A2A #AgentEconomy #AIIntegration

Intro

The Protocol Stack: From Tools to Commerce

1. MCP: Model Context Protocol (Agent 🤖 to Tools ⚙️)

2. A2A: Agent-to-Agent Protocol (Agent 🤖 to Agent 🤖)

3. AG-UI: Agent-to-Frontend Protocol (Agent 🤖 to Frontend 📱)

4. A2UI: Agent-to-User Interface (Agent 🤖 to User Interface 📱)

5. AP2: Agent Payment Protocol (Agent 🤖 to Payment Interface 💳)

6. UCP: Universal Commerce Protocol (Agent 🤖 to Commerce 🛍)

The Bigger Picture: An Integrated Ecosystem

Real-World Impact: How These Protocols Transform Daily Work

Looking Ahead: The Protocol-First Future

AIAgents #Protocols #AIDevelopment #MCP #A2A #AgentEconomy #AIIntegration

Gemini 2.5 Flash vs. Gemini 2.0 Flash: A New Era for AI Image Generation

Key Advancements in Gemini 2.5 Flash

Links:

Google Cloud's GKE tops 2025 Magic Quadrant for Container Management

Learn how to create a chatbot and deploy to Cloud in few mins.

How to build & deploy a simple Streamlit chatbot using Gemini 2.5 Flash Lite

How to build & deploy a simple Streamlit chatbot using Gemini 2.5 Flash Lite