# Sampath Kumar | AI & Cloud Blog — full content for LLMs
> Full inlined Markdown of every page listed in /llms.txt, in the same
> order. Generated by scripts/gen_llms_full.py — do not edit by hand.
# Sampath Kumar | AI & Cloud Blog
## Cookbook
## Cookbook — Hub
Source: https://msampathkumar.github.io/cookbook/
# Cookbook
Hands-on, runnable recipes for building with AI on Google Cloud. Each cookbook
is a self-contained series that takes you from fundamentals to a deployed
application — written **agents-first**, so both AI agents and human developers
can follow along.
## Available cookbooks
### :material-star-four-points: Gemini Cookbook
Build practical applications with Google Cloud's Gemini models — from a basic
Streamlit chatbot to Retrieval-Augmented Generation and knowledge graphs, all
deployable to Cloud Run.
[Open the Gemini Cookbook →](google-cloud-gemini-cookbook/README.md){ .md-button }
### :material-transit-connection-variant: A2A Cookbook (coming soon)
Recipes for the **Agent-to-Agent (A2A) protocol**: exposing agents over A2A,
wiring multi-agent systems, and interoperating across frameworks. Coming soon —
watch this space (or the
[blog](https://msampathkumar.github.io/)).
## What to expect
- **Practical first** — every lesson ships runnable code.
- **Clear and incremental** — each lesson builds on the last.
- **Production-minded** — deployment, cost, and safety are treated as
first-class, not afterthoughts.
## Prerequisites
- Basic Python.
- A Google Cloud account with billing enabled and Vertex AI APIs on.
- Comfort with the command line and `git`.
---
## Gemini Cookbook — Overview
Source: https://msampathkumar.github.io/google-cloud-gemini-cookbook/
# 🧠 Google Cloud Gemini Cookbook
Welcome to the central hub for the Google Cloud Gemini Cookbook! This repository contains hands-on recipes and practical lessons designed to take your AI applications from idea to production using Google Cloud's cutting-edge models.
## 🛠️ Prerequisites
Before diving in, ensure your local environment has the following:
- A Google Cloud Platform account with Vertex AI APIs enabled.
- A working Python environment (Python >= 3.8).
- Installed [gcloud CLI](https://cloud.google.com/sdk/docs/install) and configured Application Default Credentials (`gcloud auth application-default login`).
## 🧰 Tech Stack
- **LLM SDK:** Official Google GenAI SDK to orchestrate Gemini models.
- **Frontend:** [Streamlit](https://streamlit.io/) for rapid, interactive UI development.
- **Deployment:** [Google Cloud Run](https://cloud.google.com/run) for scalable, serverless application hosting.
## 📚 Available Lessons
- **[Lesson 01: 🚀 Build a `Hello World` app with Gemini, Streamlit & Google Cloud Run](./lesson-01/README.md)**
Take your Python code from a simple idea to a live serverless container web application in minutes.
- **[Lesson 02: Deploy Your AI Chatbot to Google Cloud Run: Go Live! ☁️](./lesson-02/README.md)**
Build a smart, interactive conversational assistant leveraging chat sessions with memory.
- **[Lesson 03: 🚀 Build Your First Context-aware Gemini Chatbot in Minutes: The Secret to Speed and Relevance! ⚡](./lesson-03/README.md)**
Rapidly inject intelligence using In-Context Learning (ICL), System Instructions, and Context Caching.
- **[Lesson 04: 🔓 Unlock Enterprise AI: Grounding Gemini with RAG and Google Cloud Search 🚀](./lesson-04/README.md)**
Combat hallucinations by dynamically augmenting Gemini with your private knowledge base.
- **[Lesson 05: Review - Five Takeaways to enhance your Gemini Apps](./lesson-05/README.md)**
Level up your AI builds with strategic takeaways on layered architectures, latency, cost optimization, and simplicity.
______________________________________________________________________
*Happy building! Let's go beyond the basics and build outstanding generative AI experiences.* 🚀
---
## Lesson 1 — Basic Chatbot with Streamlit
Source: https://msampathkumar.github.io/google-cloud-gemini-cookbook/lesson-01/
# Cookbook Lesson 01: 🚀 Build a `Hello World` app with Gemini, Streamlit & Google Cloud Run
Welcome to the **Google Cloud Gemini Cookbook**! In this very first lesson,
we're going to embark on an exciting journey: taking your Python code from a
simple idea to a live web application in minutes. Forget complex setups; with
Streamlit and Google Cloud Run, deploying your first web app is incredibly fast
and fun! ✨
> This lesson is part of the
> [Google Cloud - Gemini Cookbook (GitHub Link)](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/).
______________________________________________________________________
## What You'll Learn 🎓
This lesson focuses on the essentials of getting a web application up and
running quickly:
1. **Build a "Hello World" with Streamlit:** Discover how effortlessly you can
create interactive web apps using just Python. Streamlit handles all the
front-end magic for you! 🐍
1. **Deploy to Google Cloud Run:** Learn to take your Streamlit app and deploy
it as a scalable, serverless container on Google Cloud Run. This means your
app can handle traffic effortlessly, and you only pay for what you use! ☁️💸
By the end of this lesson, you'll have a fully functional web application
accessible via a URL, demonstrating the incredible speed of modern cloud
development. 🚀
______________________________________________________________________
## Prerequisites 🛠️
Before we begin, ensure you have the following:
- A Google Cloud Project with billing enabled.
- The `gcloud` CLI installed and configured.
- Python 3.8+ installed on your local machine.
- `pip` (Python package installer).
For development, we recommend using the Google Cloud Shell, which comes
pre-installed with the necessary tools.
## What is Streamlit?
[Streamlit](https://streamlit.io/) is an open-source Python framework that
makes it easy to create and share beautiful, custom web apps for machine
learning and data science. In just a few lines of code, you can build and
deploy powerful data apps.
While Streamlit is not as feature-rich as full-fledged web frameworks like
Django or Flask, its strength lies in its simplicity and ability to create
highly interactive applications quickly. This makes it an excellent choice for
building demos and prototypes.
## What is Google Cloud Run?
[Cloud Run](https://cloud.google.com/run) is a fully managed serverless
platform that enables you to run stateless containers that are invocable via
web requests or Pub/Sub events. You can deploy your code to Cloud Run, and it
will automatically scale up or down based on traffic.
Here are some of the benefits of using Cloud Run:
- **Easy to use:** Deploy your application with a single command.
- **Serverless:** No infrastructure to manage.
- **Scalable:** Automatically scales to meet demand.
- **Cost-effective:** Pay only for the resources you use.
## 💻 Local Development: Your Streamlit "Hello World"
Let's start by creating a simple Streamlit application locally. Here's how you
can do it:
### 1. Set up your environment
Create a virtual environment and install the required dependencies:
```bash
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
```
### 2. Create a simple Streamlit app
Create a file named `streamlit_app.py` with the following content:
```python
import streamlit as st
st.title("Sample AI App")
st.text("This is a sample app.")
```
### 3. Run the app locally
To run the app locally, use the following command:
```bash
streamlit run streamlit_app.py --server.port 8080
```
You should see your Streamlit app open in your browser and navigating to
`http://localhost:8080`. Interact with it! This is your app running locally. 🚀
### 4. Deploy to Cloud Run
To deploy your app to Cloud Run, you'll need to create a `Procfile` and a
`deploy.sh` script.
**Procfile**
Create a file named `Procfile` with the following content:
```
web: streamlit run streamlit_app.py --server.port=8080 --server.address=0.0.0.0 --server.enableCORS=false --browser.gatherUsageStats=false
```
This file tells Cloud Run how to start your application.
**deploy.sh**
Create a file named `deploy.sh` with the following content:
```bash
#!/bin/bash
# Purpose: To deploy the App to Cloud Run.
# Google Cloud Project ID
PROJECT="your-gcp-project-id"
# Google Cloud Region
LOCATION="us-central1"
# Deploy app from source code
gcloud run deploy simple-app --source . --region=$LOCATION --project=$PROJECT --allow-unauthenticated
```
**Important:** Replace `"your-gcp-project-id"` with your actual Google Cloud
Project ID.
Now, run the deployment script:
```bash
bash deploy.sh
```
This command will build a container image from your source code, push it to the
container registry, and deploy it to Cloud Run. Once the deployment is
complete, you'll see a service URL in the output.
Congratulations 🎉! You have successfully deployed your Streamlit app to Cloud
Run.
## Cleanup
To avoid incurring future charges, delete the resources you created:
- Go to the [Cloud Run console](https://console.cloud.google.com/run) and
delete your application.
- Go to the [Container Registry](https://console.cloud.google.com/gcr) and
delete the container image.
## Learn More
- [Cloud Run Documentation](https://cloud.google.com/run/docs)
- [Streamlit Documentation](https://docs.streamlit.io/)
- [Authenticating to Cloud Run](https://cloud.google.com/run/docs/authenticating/overview)
---
## Lesson 2 — Chatbot with Memory & Gemma
Source: https://msampathkumar.github.io/google-cloud-gemini-cookbook/lesson-02/
# Cookbook Lesson 02: Deploy Your AI Chatbot to Google Cloud Run: Go Live! ☁️
Welcome to the second lesson in our Gemini Cookbook series! This time, we're
diving into the exciting world of conversational AI. You'll learn to build a
smart, interactive chatbot using the power of Streamlit and Google's Gemini 2.5
Flash model. We'll be using the official Google Cloud Vertex AI SDK, which has
powerful features like chat sessions that give your bot a memory.
> This lesson is part of the
> [Google Cloud - Gemini Cookbook (GitHub Link)](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/).
## What You'll Create
Get ready to build a sleek, web-based chatbot. With Streamlit as our frontend,
your chatbot will connect to the mighty Gemini 1.5 Flash model, enabling you to
have dynamic and stateful conversations. It's like having your own personal AI
assistant!
## What You'll Need
To get started, make sure you have the following essentials:
- A Google Cloud project with the Vertex AI API ready to go.
- Python 3.8 or a newer version.
- The `pip` package manager for installing our dependencies.
### Mandatory steps
This is a mandatory steps to access Gemini Models from your Google Cloud
Project.
I have installed the Gcloud tool and used
[Application Default Credentials](https://cloud.google.com/docs/authentication/provide-credentials-adc)
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](https://cloud.google.com/docs/authentication/set-up-adc-attached-service-account)
article.
## Let's Get Building!
1. **Get the Code:** First, clone the repository and hop into the right
directory:
```bash
git clone https://github.com/msampathkumar/msampathkumar.github.io.git
cd msampathkumar.github.io/docs/google-cloud-gemini-cookbook/lesson-02
```
1. **Set Up Your Workspace:** Create a virtual environment to keep things tidy:
```bash
python3 -m venv .venv
source .venv/bin/activate
```
1. **Install the Magic:** Time to install the necessary Python packages:
```bash
pip install -r requirements.txt
```
1. **Connect to Google Cloud:** Authenticate your local environment to use
Google Cloud services:
```bash
gcloud auth application-default login
```
## A Look Under the Hood
Let's take a peek at the code that makes our chatbot tick.
### The Chatbot UI: `streamlit_app.py`
This file is the heart of our Streamlit app. It's responsible for:
- Providing a chat interface for user input.
- Displaying the response from the model.
- Maintaining the conversation history.
While you would typically use Streamlit's `session_state` to store the
conversation history manually, the Vertex AI SDK simplifies this. We'll use a
`ChatSession` object from the SDK, which automatically handles the history for
us. We just need to store this one object in `st.session_state` to make our
chat stateful.
You can see the core logic below:
```python
import streamlit as st
import llm
# Initialize chat session in Streamlit's session state.
# This will be run only once, on the first run of the session.
if "chat_session" not in st.session_state:
st.session_state.chat_session = llm.start_chat()
# Display chat history from the session state
for message in st.session_state.chat_session.history:
with st.chat_message("assistant" if message.role == "model" else "user"):
st.markdown(message.parts[0].text)
```
### The Brains of the Operation: `llm.py`
This file handles all the communication with the Gemini 2.5 Flash model. As we
are using GenAI SDK, we can use environment variables to set up the required
details for authentication. Also, GenAI SDK provides us with `Client` class
which we can use to create a chat session and send messages to the Gemini Model
and receive.
```python
from google import genai
# Using environment variables to pass essential parameters to the client.
client = genai.Client()
# Create chat session
chat_session = client.chats.create("gemini-2.0-flash-lite-001")
```
#### To run chatbot in CLI
```bash
python llm.py
```
#### To run streamlit chatbot
```bash
streamlit run streamlit_app.py
```
## Deploy the application
You can deploy your chatbot to Google Cloud Run and share it with the world.
Use the `deploy.sh` script to package your app into a Docker image and send it
to the Google Artifact Registry.
```bash
./deploy.sh
```
The script will then deploy your app to Cloud Run, making it live on the web.
## You Did It!
High five! You've built and deployed a fully functional chatbot with Streamlit
and Gemini Pro. You've seen how to use the new Generative AI SDK and its chat
features to create a more natural and engaging conversational experience. Now,
go ahead and have a chat with your new AI friend!
---
## Lesson 3 — Multimodality with Vision
Source: https://msampathkumar.github.io/google-cloud-gemini-cookbook/lesson-03/
# Cookbook Lesson 03 🚀 Build Your First Context-aware Gemini Chatbot in Minutes: The Secret to Speed and Relevance! ⚡
**Scenario:** It's Tuesday, July 22, 2025, 12:26 PM CEST. You're a developer,
enjoying your morning coffee in Warsaw ☕, contemplating your next big feature.
Suddenly, your director bursts in: "We need a quick demo of a new,
context-aware chatbot for our internal knowledge base – and the meeting is in
30 minutes! Can you get something ready?" 🤯
Panic? Absolutely not! Not with Gemini and Streamlit. This lesson is your
secret weapon to rapidly inject intelligence into your chatbot, focusing on
direct, consistent, and reusable context methods that get you up and running
with meaningful interactions fast.
> This lesson is part of the 5 part series
> [Google Cloud - Gemini Cookbook (GitHub Link)](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/).
______________________________________________________________________
## 1. Understanding Context: Why It's Your Chatbot's Superpower 🦸♀️
Large Language Models (LLMs) like Gemini are incredible, but they're not
clairvoyant. Without explicit guidance, their responses can be generic, vague,
or even incorrect when faced with specific or domain-sensitive questions.
Context is the "secret sauce" that transforms a generic LLM into a specialized,
helpful chatbot. It's the information you provide to guide the model's
understanding and shape its output. 💡
Consider a simple chatbot built with Gemini and Streamlit. If you ask it a very
specific question without any context, it might struggle.
**Example: A Generic Chatbot Responding to a Specific Query**
Let's say your basic Streamlit app simply forwards user input to Gemini. If you
ask about an internal project:
```bash
$ python llm.py
Chat session ID: 4383160272
Enter your question (or 'exit' to quit)
User: What are the key milestones for Project Alpha in Q3?
Model: I need a little more information to tell you about
Project Alpha's Q3 milestones! Could you please tell me
more about what "Project Alpha" refers to? 😊
```
or via chatbot UI:
```
streamlit run streamlit_app.py
```
This is where context comes in. By providing context, you tell Gemini exactly
what "Project Alpha" means in _your_ world. ✨
______________________________________________________________________
## 2. In-Context Learning (ICL): Guiding with Examples, Instantly ✨
In-Context Learning (ICL) is the quickest way to demonstrate a desired output
pattern to Gemini. You provide explicit examples directly within your prompt,
and Gemini learns from these patterns without needing any fine-tuning. It's
like teaching by showing!
### One-Shot Learning: A Single Guiding Example ☝️
For simple tasks, one example might be all you need. You show Gemini a single
input-output pair, and it follows that pattern for subsequent queries.
**Use Case:** Simple classification, rephrasing, or straightforward
translation. 🌐
**Example: One-Shot Translation**
```
User: Translate this English to French.
English: Hello.
French: Bonjour.
English: What is your name?
French:
Chatbot (With one-shot example): Quel est votre nom?
```
### Few-Shot Learning: Reinforcing Complex Patterns 📚
When the task is more nuanced or requires a specific output format, providing a
few examples helps Gemini better grasp the pattern. It's like providing
multiple reference points for complex concepts.
**Use Case:** More nuanced categorization, structured data extraction, or
adhering to specific stylistic requirements. 📋
**Example: Few-Shot Sentiment Analysis**
```
User: Review: The delivery was fast!
Sentiment: Positive.
Review: The product broke immediately.
Sentiment: Negative.
Review: The customer service was okay, but the delivery was slow.
Sentiment:
Chatbot (With few-shot examples): Mixed/Neutral
```
**Considerations:** While powerful for quick guidance, ICL consumes tokens with
every prompt, which can impact cost and latency for very long examples or many
turns. 💸🐢
______________________________________________________________________
## 3. System Instructions: Setting Your Chatbot's Personality and Rules 📜
System instructions define your chatbot's overarching persona, tone, and
behavioral guardrails. This is a foundational layer of context that applies to
_all_ subsequent user turns in a chat session, making Gemini's responses
consistent and aligned with your brand or application's requirements. It's like
giving your bot a permanent job description! 🧑💻
You define the "rules of engagement" for your chatbot, ensuring it behaves
predictably. 🚦
**Code Sample: llm.py (LLM Interaction Logic)**
System instructions are defined in the `llm.py` file.
```
chat_session = client.chats.create(
model=MODEL_NAME,
config=GenerateContentConfig(
system_instruction=[
"You're a helpful Gemini AI Chatbot.",
"Answer user's questions and use simple and clear language."
"When possible, reply to user's question with a single sentence or a few sentences.",
"Free to use emojis."
"Be open and friendly. Don't be afraid to ask questions or clarify things.",
]
),
)
```
______________________________________________________________________
## 4. Context Caching: Reusing Static Information Efficiently 📦
______________________________________________________________________
Imagine your chatbot needs to be an expert on a fixed set of documents, like
internal reports, product manuals, or, in our case, specific research papers.
Sending these large documents with every single API call would be slow and
expensive. This is where **Context Caching** becomes a game-changer.
Gemini's Context Caching allows you to process and store static,
frequently-referenced content once. You then refer to this cached content using
a simple, lightweight name in your subsequent API calls. This drastically saves
tokens, reduces latency, and lowers costs, especially when dealing with large
files.
**Example Use Case**: Efficient retrieval of information from large, static
knowledge bases, optimizing token usage, and simplifying your requests to
model. 📦
Let update our chatbot a chatbot to be expert on the Gemini family of models,
using two key research papers as its knowledge base.
- Paper 1: Gemini: A Family of Highly Capable Multimodal
Models.([2312.11805v3.pdf](https://storage.cloud.google.com/cloud-samples-data/generative-ai/pdf/2312.11805v3.pdf))
- Paper 2: Gemini 1.5: Unlocking multimodal understanding across millions of
tokens of context
([2403.05530.pdf](https://storage.cloud.google.com/cloud-samples-data/generative-ai/pdf/2403.05530.pdf))Instead
of feeding these PDFs to the model repeatedly, we'll cache them and let our
chatbot use that cached knowledge.
## How It Works: A Two-Step Process
**Step 1: Create the Cache**
First, you need to upload your static files and create a CachedContent object.
This is a one-time operation. You'll save the name of the cache to use in your
application later.
Full code:
https://github.com/GoogleCloudPlatform/python-docs-samples/blob/main/genai/content_cache/contentcache_create_with_txt_gcs_pdf.py
```python
system_instruction = """
You are an expert researcher.
You always stick to the facts in the sources provided, and never make up new facts.
Now look at these research papers, and answer the following questions.
"""
cache_objects = [
Part.from_uri(
file_uri="gs://cloud-samples-data/generative-ai/pdf/2312.11805v3.pdf",
mime_type="application/pdf",
),
Part.from_uri(
file_uri="gs://cloud-samples-data/generative-ai/pdf/2403.05530.pdf",
mime_type="application/pdf",
),
]
content_cache = client.caches.create(
model="gemini-2.5-flash",
config=CreateCachedContentConfig(
contents=[Content(role="user", parts=cache_objects)],
system_instruction=system_instruction,
display_name="example-cache",
ttl="86400s",
),
)
```
**Note**: Cache is created with a TTL (time to live). After a specific amount
of time, the cache will be deleted.
Once the cache is created you will a cache name (e.g.,
cachedContents/f1e2d3c4-a5b6-7890-a1b2-c3d4e5f6a7b8), which we will use with
chatbot.
**Step 2: Use the Cache in Your Chatbot**
Once the cache is created, you can use it in your chatbot by passing its name
in the `GenerateContentConfig` object. For example:
```python
system_instruction = "..."
cache_name = ("projects/.../locations/us-central1/keyRings/.../cryptoKeys/...",)
chat_session = client.chats.create(
config=GenerateContentConfig(
cached_content=cache_name,
system_instruction=None if cache_name else system_instruction,
)
)
```
Since the Cache has a defined timelimit, it required a little attention to
avoid any potential issues. So I hae created a CacheManager to manage the
cache, which will automatically clean up expired caches.
Here is the content for `cache.py`
Examples:
**Here is the example of not using Context Cache:**
**Here is the example of using Context Cache:**
## **To Deploy This Application on Google Cloud Run:**
1. Clone this repository and navigate to the directory
```bash
git clone https://github.com/msampathkumar/msampathkumar.github.io.git
cd docs/google-cloud-gemini-cookbook/lesson-03
```
2. Setup your virtual environment and install dependencies:
```bash
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
```
3. Run the application locally to make sure it works as expected.
```bash
streamlit run streamlit_app.py
```
4. To deploy to Google Cloud Run, you can use the `deploy.sh` script:
```bash
bash deploy.sh
```
Github:
https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook
## Congratulations 🎉 ( ◠‿◠ )
Congratulations, You've Achieved a Milestone!
You successfully deployed a content-aware chatbot application to Google Cloud
Run.
In the next lesson, we will delve into two more features that will further
enhance your chatbot's context awareness:
1. **RAG**: Retrieval Augmented Generation (RAG)
1. **Grounding**: Using Google Search
Let's continue learning and exploring these innovative tools together!
---
## Lesson 4 — Knowledge Base Q&A with RAG
Source: https://msampathkumar.github.io/google-cloud-gemini-cookbook/lesson-04/
# Cookbook Lesson 04: 🔓 Unlock Enterprise AI: Grounding Gemini with RAG and Google Cloud Search 🚀
Welcome back! 👋 In Lesson 03, we built fast, relevant chatbots using direct
context methods like In-Context Learning ✨, System Instructions 📜, and Context
Caching 📦. Those are fantastic for quick demos and consistent persona. But what
if your chatbot needs to know the _latest_ company sales figures, details from
an obscure internal report, or specific client history? That's where Large
Language Models (LLMs) hit their limit – they hallucinate! 😵💫
Today, we tackle the next frontier: **Grounding** your Gemini models in
real-time, external, and even proprietary data using **Retrieval Augmented
Generation (RAG)**, with Google Cloud Search as your powerful engine. 🔍
> This lesson is part of the 5 part series
> [Google Cloud - Gemini Cookbook (GitHub Link)](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/).
______________________________________________________________________
## 1. Grounding LLMs: Combating Hallucinations with External Knowledge 🛡️
LLMs are brilliant pattern matchers, trained on vast amounts of internet data.
However, their knowledge is frozen at their last training cut-off date. They
don't have real-time access to the internet, nor do they inherently know your
company's internal documents, recent sales data, or specific client
interactions. When asked about such information, they might:
- **Refuse to answer:** "I don't have information on that." 🤷♀️
- **Generate generic or outdated information:** "According to general industry
trends..." 🗓️
- **"Hallucinate":** Make up plausible-sounding but entirely false information.
This is the most dangerous! 🚨
**Example: A Chatbot Hallucinating on Project Status**
Let's revisit our chatbot. If you ask about specific, latest information:
```
User: What is the status of our CRM project - Alpha?
Model: I'm sorry, but I don't have access to specific project details like the status of your CRM project Alpha. 😟 I can only provide general information.
User: What is today's date ?
Model: Today's date is June 16, 2024. 📅
```
This is a problem. In enterprise settings, accuracy is paramount. We need a way
to connect Gemini to our actual, verifiable knowledge. This is called
**grounding**. 🌱
______________________________________________________________________
## 2. Introduction to Retrieval Augmented Generation (RAG): Your LLM's Research Assistant 🧑🎓
Retrieval Augmented Generation (RAG) is an architectural pattern that solves
the hallucination problem by giving LLMs access to external, up-to-date, and
domain-specific information.
Think of RAG as giving your LLM a brilliant research assistant: 🧐
1. **Retrieve:** When you ask a question, the "research assistant" first
searches a vast library (your knowledge base) for relevant documents or
snippets. 📚
1. **Augment:** It then takes the most relevant findings and gives them to the
LLM. 🧩
1. **Generate:** Finally, the LLM uses this specific, retrieved information
(along with your original query) to formulate an accurate and grounded
response. ✅
**Key Components of a RAG System:**
- **Knowledge Base:** Your source of truth – internal documents, databases,
websites, etc. 📁
- **Retriever:** A system (like a vector database combined with an embedding
model, or a powerful search engine like Google Cloud Search) that can quickly
find the most relevant pieces of information from your knowledge base based
on a query. 🔎
- **Generator:** The LLM (Gemini) that synthesizes the answer using the
retrieved context. 🧠
**Benefits of RAG:**
- **Factuality:** Grounding responses in real data dramatically reduces
hallucinations. ✅
- **Currency:** LLMs can answer questions about information that wasn't in
their training data or is constantly changing. ⏰
- **Domain-Specific Knowledge:** Access to proprietary or niche topics. 💼
- **Attribution:** Potential to show users _where_ the information came from
(e.g., "Source: Policy Manual v2.1"). 🔗
**RAG vs. Context Cache: A Crucial Distinction** 🚨
It's vital to differentiate RAG from Context Caching (Lesson 03).
- **Context Cache:** _Reuses_ small, static pieces of pre-loaded or
conversational context. It's about efficiency for fixed data, avoiding
redundant token usage. Think of it as a persistent "sticky note" or
short-term memory for repeated instructions or small data blocks. 📝
- **RAG:** _Dynamically retrieves_ specific, often large, and always relevant
chunks of information from a vast, external knowledge base _on demand_ for
each query. It's about expanding the LLM's factual knowledge with new,
current, or private data. 🌐
______________________________________________________________________
## 3. Application Architecture
This application is designed to be a flexible and extensible chatbot that can
leverage different grounding techniques. Here's a breakdown of the core
components:
```mermaid
graph TD
subgraph User Interface
A[streamlit_app.py]
end
subgraph Core Logic
B(llm.py)
end
subgraph Optional Add-ons
C[cache.py]
D[rag.py]
end
A -- "Initializes and calls" --> B
B -- "Optionally uses" --> C
B -- "Optionally uses" --> D
```
**Core Application Logic:**
- **`streamlit_app.py` (UI):** This is the user-facing component of the
application, built with Streamlit. It provides the chat interface, handles
user input, and displays the LLM's responses. It's the "skin" of our
application.
- **`llm.py` (The Brain):** This module is the central nervous system of our
chatbot. It's responsible for all interactions with the Gemini API. It takes
the user's prompt, and based on the selected mode (Default, Context Cache, or
RAG), it constructs the appropriate request to the Gemini model.
- **`cache.py` (Optional Battery):** This module manages the Context Cache.
When the "Use Context Cache" option is selected, `llm.py` uses this module to
create and manage a cache of context, which can be reused across
conversations to improve speed and reduce costs.
- **`rag.py` (Optional Battery):** This module handles the Retrieval-Augmented
Generation (RAG) functionality. When the "Use RAG as Tool" option is
selected, `llm.py` uses this module to create and manage a RAG corpus. This
allows the LLM to retrieve information from a knowledge base to answer
questions.
**Code Links:**
- [streamlit_app.py](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/lesson-04/streamlit_app.py)
- [llm.py](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/lesson-04/llm.py)
- [cache.py](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/lesson-04/cache.py)
- [rag.py](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/lesson-04/rag.py)
## 4. RAG Implementation Flow
Here’s a more detailed look at how the RAG process works within our application
when the "Use RAG as Tool" option is enabled:
```mermaid
sequenceDiagram
participant User
participant Streamlit UI (streamlit_app.py)
participant LLM Brain (llm.py)
participant RAG Corpus (rag.py)
participant Gemini API
User->>Streamlit UI (streamlit_app.py): Enters a prompt
Streamlit UI (streamlit_app.py)->>LLM Brain (llm.py): Sends prompt to get chat session
LLM Brain (llm.py)->>RAG Corpus (rag.py): Initializes RAG corpus
RAG Corpus (rag.py)-->>LLM Brain (llm.py): Returns RAG corpus name
LLM Brain (llm.py)->>Gemini API: Creates chat session with RAG tool
Gemini API-->>LLM Brain (llm.py): Returns chat session
LLM Brain (llm.py)-->>Streamlit UI (streamlit_app.py): Returns chat session
Streamlit UI (streamlit_app.py)->>LLM Brain (llm.py): Sends user prompt
LLM Brain (llm.py)->>Gemini API: Sends prompt to Gemini
Gemini API->>RAG Corpus (rag.py): Retrieves relevant documents
RAG Corpus (rag.py)-->>Gemini API: Returns documents
Gemini API-->>LLM Brain (llm.py): Generates response based on retrieved documents
LLM Brain (llm.py)-->>Streamlit UI (streamlit_app.py): Returns grounded response
Streamlit UI (streamlit_app.py)-->>User: Displays response
```
## 5. Application Screenshots
Youtube: https://youtu.be/JIx4Fr4V6Mw
______________________________________________________________________
## Conclusion
This lesson demonstrated how to ground Gemini models with external knowledge
using RAG. By leveraging RAG, we can build more accurate, factual, and useful
AI applications that can reason about private and real-time data.
---
## Lesson 5 — Advanced RAG with Knowledge Graphs
Source: https://msampathkumar.github.io/google-cloud-gemini-cookbook/lesson-05/
# **Cookbook Lesson 05: Review - Five Takeaways to enhance your Gemini Apps**
Welcome to Lesson 05 of my Gemini Cookbook series :)
The potential of Gemini is limitless, but unlocking its true power requires
more than just a ‘hello world’ app. It demands a strategic approach to
performance, cost, and design. In this lesson 05, we’ll transform that
potential into reality by exploring 5️⃣ key takeaways that will elevate your
Gemini applications to the next level.
In Lessons 01 through 04, we covered essential topics, from building a “_hello
world_” app to creating powerful, context-aware chatbots. In this Lesson 05,
we’ll do a quick recap of those earlier lessons and then dive into some
important tips and takeaways for building great Gemini features applicable to
most users.
> This lesson is the last part of the 5 part series
> [Google Cloud - Gemini Cookbook (GitHub Link)](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/).
## **Takeaway 01: Multi-Layered Application**
Let me quote from a Google Developer Advocate.
“To effectively monitor your agent, it’s best to adopt a practical, **layered
approach**. Here’s a guide to setting up observability at every stage of the
development lifecycle.” -
[Alvin Prayuda Juniarta Dwiyantoro](https://medium.com/google-cloud/prepping-your-agent-for-production-observability-for-agent-development-kit-adk-a6d74c744ef2)
Building an application and its features can become a cascading challenge,
especially when you aim for an app that can be used, maintained, updated, and
deployed to production environments. As mentioned in the quote, building
applications with a layered approach can help streamline the overall
development flow.
### **Flow chart**
_[Lesson 04 Github-Link](https://github.com/msampathkumar/msampathkumar.github.io/tree/master/docs/google-cloud-gemini-cookbook/lesson-04)_
This tutorial series built a sophisticated chatbot over four lessons.
- **Lesson 01:** We started with streamlit_app.py to create a basic “hello
world” page and learned deployment fundamentals.
- **Lesson 02:** We developed llm.py, the chatbot’s “brain,” using Google’s
GenAI SDK, and designed the user interface for interactive chat sessions.
- **Lesson 03:** We added contextual awareness using System Instructions and a
Context Cache to maintain coherent conversations.
- **Lesson 04:** We expanded the chatbot’s context to external resources like
Google Search and external data stores via Retrieval Augmented Generation
(RAG).
To maintain simplicity, Lessons 03 and 04 utilize a layered architecture (for
code), adding new features as distinct modules. This actually differs with the
initial approach, where a single file facilitated early development. As
features expanded, I realized the benefits of dedicated modules like RAG.py and
Cache.py over modifying existing files, which significantly streamlined
development, testing, and debugging.
This layered approach proved effective in our application. The following
sections detail further takeaways from my experiments and explorations.
## **Takeaway 02: Improve your speed**
Large Language Models (LLMs) are extensive software applications that utilize
significant CPU, memory, and network resources. Much like services such as
BigQuery or Cloud SQL, these models are globally hosted, serving users
worldwide. In this section, we will observe how you can improve model responses
speed.
### **021 Global Endpoints (GE):**
This section presents my personal explorations and hypotheses.
It’s common to assume that proximity to the LLM’s physical location ensures
optimal performance. While reduced network latency is a factor, it doesn’t
account for the entire picture. LLMs operate as shared services, inherently
utilizing a first-in, first-out queuing system. Therefore, the ideal location
selection hinges on the equation: **_min_response(Nearby locations + shorter
queue)_**. When incorporating additional variables like time and potential
datacenter disruptions (e.g., maintenance, power failures, or even submarine
cable issues), the optimal solution evolves to **_min_response(Nearby
\*available\* locations + shorter queue)._**
However, forecasting all these conditions is challenging. Continuously querying
every Gemini model globally to assess response times could paradoxically impede
overall performance. This is precisely where **_Global Endpoints_** demonstrate
their value! They intelligently determine which LLM model will deliver the
quickest response, thereby accelerating your interactions.
Back in March 2024, I whipped up a demo app that hit a global endpoint instead
of a specific regional one, like us-central1 or europe-central2. Since I was
working from my place in Warsaw, Poland, with an old router, I figured there
might be some lag. But honestly, the huge performance difference between the
global endpoint and my go-to europe-west1 was pretty wild-in a good way!
Based on my personal explorations and practical experience, employing Global
Endpoints(GE) can significantly enhance the speed of your Gemini application.
While **_GE_** are an excellent choice, they do have some limitations.
1. Data Localization: If your app needs to keep data in a specific place (like
for GDPR), **_GE_** might not be the right choice.
1. LLM’s Features Limitation: Certain features, such as RAG (Vector Search)
built in specific locations (e.g., Europe or US-Central), may not be
available for use.
### **022 Using Gemini-Lite Models**
Upon the initial announcement of the Gemini Live API, I was quite enthusiastic,
particularly regarding the integration of WebSockets, which I find to be
remarkably efficient compared to standard HTTPS requests. Following
exploration, I determined that a text-based chat proved to be the optimal
choice for my needs, rather than audio or video conferencing.
Although the Live API offers robust transcription options for both input and
output
(https://cloud.google.com/vertex-ai/generative-ai/docs/live-api#transcribe_audio),
I found text-based interaction more effective(simple and fast enough) as it
allowed me to review my queries before submission.
These two considerations led me to consistently utilize the gemini-flash-lite
models for straightforward chatbot applications.
## **Takeaway 03: Cost Saving**
### **031 Use Context Caching**
When leveraging Gemini for token usage tracking through observability, you
might encounter a pleasant surprise: Gemini’s Implicit Context Caching (ICC)
and Explicit Context Caching (ECC) features. By default, ICC is active but can
be disabled if necessary.
As with any caching mechanism, the effectiveness is determined by the cache-hit
to cache-miss ratio. With ICC, cost savings are not guaranteed. For instance,
if you process 100–200 distinct queries across various languages, a common
token cache is not feasible, and Gemini cannot provide cost savings in such
scenarios.
In contrast to ICC, ECC offers a guaranteed cost reduction. While ECC is a
powerful feature, its implementation is a design choice. Achieving
cost-effectiveness with ECC, akin to reaching escape velocity, requires hitting
a specific mathematical threshold. It’s not magic, just pure mathematics!
My recommendation is to consider using ECC when you have about 200+ queries and
need a large context (dataset) in a short duration. For example, (1) you are
building an Astro-Science Chatbot knowledgeable in a dozen physics, chemistry,
and astrophysics books (2) You have to deal with really smart kids (I hope AI
could handle those queries).
Here is a quick recap of takeaway 031.
### **032 Provision Throughput (PT)**
This is Vertex AI only feature.
Provisioned Throughput is a fixed-cost, fixed-term subscription available in
several term-lengths that reserves throughput for supported generative AI
models on Vertex AI. To reserve your throughput, you must specify the model and
available locations in which the model runs.
It is important to note that exceeding your Provisioned Throughput limit will
not halt your requests. While this ensures uninterrupted service by preventing
errors, it also means you cannot cap your Gemini costs if budget constraints
are a concern.
## **Takeaway 04: Context Awareness**
Whether it’s Gemini or some other LLMs, it’s always the same rule. People are
calling context the king but when I was learning data science, I heard a
similar quote about Data / Information.
Let me take a personal example here. Back in 2015, my colleagues had a simple
classification challenge but the difficult part was the data distribution.
Client has provided 1 TB of data positive data and 10 MB of negative data.
(1,000,000 MB of positive data set and 10 MB is -tive dataset). The substantial
disparity in data distribution made all our initial models predominantly
classified queries as positive, achieving approximately 99.999% accuracy.
However it was not the solution we needed.
When I say context, it is the data relevancy. If your queries are not relevant
to the context or theme you have set for the model, then you may be doing
something fundamentally wrong. Imagine studying poetry to improve painting.
So to keep your model responses relative to what users need, with gemini I have
tested the following approaches
### **041 Use System Instructions:**
Define all the critical details that your model needs to remember. For example,
“You are Bill Nye, the science guy. You are an American science communicator,
television presenter, and former mechanical engineer. You are best known as the
host of the science education television show Bill Nye the Science Guy and as a
science educator in pop culture.” (Copied from wikipedia)
### **042 Use Grounding with Google Search:**
To the scope limited, many times LLM models are not connected to search engines
like Google (or DuckDuckGo or Yahoo). By enabling this, you can allow Gemini
Model to browse the internet and get the latest information like date, climate
and so on.
### **043 Use RAG:**
Similar to Grounding with Google Search, you may find your in a case where you
want the model to automatically learn information about a certain project or
certain dataset that is private to you or your team or organization. In such
cases, using RAG has turned out to be an amazing investment.
Using Vertex AI’s RAG feature, all the provided data is converted into vectors
and stored in a Vector database. When user queries, relevant data is identified
from this Vector database and included as part of the overall context for the
Model. As you may expect now this allows the model to get relevant answers.
Here is a quick recap of takeaway 04.
## **Takeaway 05: Simplicity**
Simplicity stands as a crucial principle. Throughout my development and
refinement of applications, I’ve experimented with various LLM assisting tools.
The[ Gemini CLI](https://github.com/google-gemini/gemini-cli) consistently
proved most effective. Yet, even with this preference, it occasionally
exhibited hallucinations, while other selections yielded even less favorable
results. One time as an experiment, I allowed these changes to persist,
meticulously reviewing each. This process finally led to a visually very
appealing application with substantial code. During testing, as errors emerged,
the model would rectify them. After several iterations, I realized I no longer
genuinely enjoyed the application I had built. While aesthetically pleasing, I
lacked the confidence to assume ownership for future feature additions or bug
fixes. Gemini handled much of the work, but my engineering accountability kept
me on edge.
Consider this: if a bug exists within 10 lines of code, the probability of
quickly identifying it is 10%; however, in 500 lines of code, that probability
drops to 0.2% (The layered approach in modules 03 and 04 simplified my code,
resulting in faster debugging and error correction.)
Simple designs are easier to understand, build, and maintain. As mentioned in
Takeaway 01, a layered approach is helpful, but always prioritize simplicity in
its execution. Ultimately, ensure your code is readable and simple for humans.
## **Conclusion:**
When building Gemini applications, a clear, layered, and straightforward design
leads to robust, debuggable, and maintainable solutions, enabling powerful,
efficient, and cost-effective Gemini-powered experiences.
As this series concludes, remember that simplicity is key to great Gemini apps.
These five takeaways are your secret ingredients for success. The next
adventure awaits with the Google Agent Development Kit.
Don’t stop here! Our next post will explore the Google Agent Development Kit
(ADK), built on the Google Gen AI SDK, to enhance your Gemini development
journey. Lets go beyond the basics and build something outstanding in Gen AI.
______________________________________________________________________
Now something for fun :)
---
## Writing — Agent-to-Agent (A2A)
## Docker for Agents: A Backend Engineer's Introduction to A2A
Source: https://msampathkumar.github.io/writing/a2a/intro/
> Originally published on
> [dev.to](https://dev.to/sampathm/docker-for-agents-a-backend-engineers-introduction-to-a2a-3h0p)
> /
> [Medium](https://medium.com/google-cloud/a2a-protocol-blog-post-01-introduction-8294ca1d6a61).
 _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
1. **The Agent Card** — how an agent advertises who it is and how to reach it
(discovery).
1. **Tasks & messages** — how a client asks your agent to do work.
1. **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).
```python
# 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.
```python
# 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).
```python
# 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:**
1. A2A Server instance — Step
```shell
# To start an A2A instance
$ git clone https://github.com/a2aproject/a2a-samples.git
$ cd a2a-samples/samples/python/agents/helloworld
$ uv run .
```
2. Client instance in a new terminal
```shell
# 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/](https://a2a-protocol.org/latest/)
- Star the project →
[https://github.com/a2aproject/A2A](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.
______________________________________________________________________
---
## What's New in A2A: v1.0, a Python DX Glow-Up, and a Fresh New Look
Source: https://msampathkumar.github.io/writing/a2a/v1-release/
> Originally published on
> [dev.to](https://dev.to/sampathm/whats-new-in-a2a-v10-a-python-dx-glow-up-and-a-fresh-new-look-1hek)
> /
> [Medium](https://medium.com/google-cloud/whats-new-in-a2a-protocol-v1-release-b36dc6b4febd).
 _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](https://github.com/a2aproject/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](https://a2a-protocol.org/latest/whats-new-v1/) guide (five
minutes to find out if anything affects you), the
[full specification](https://a2a-protocol.org/latest/specification/) for the
canonical reference, and — if you’re on Python — the
[v1.0 migration guide](https://github.com/a2aproject/a2a-python/blob/main/docs/migrations/v1_0/README.md).
Stuck on something? The community hangs out in
[GitHub Discussions](https://github.com/a2aproject/A2A/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](https://a2aproject.github.io/a2a-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](https://dev.to/sampathm/breaking-down-agent-silos-the-a2a-integration-test-kit-dashboard-is-here-4m60)
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:
```python
##############################################################
# 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](https://github.com/a2aproject/a2a-python/blob/main/docs/migrations/v1_0/README.md)
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](https://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**](https://a2a-protocol.org/latest/)\
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**](https://github.com/a2aproject/A2A/blob/main/mkdocs.yml#L20)\
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**](https://a2a-protocol.org/latest/assets/a2a_logo/color/SVG/a2a_color.svg)\
A cleaner, more consistent mark across the docs, the repo, and everywhere A2A
shows up.
 _A2A New Logo_
[**# Lastly, our new A2A Mascot**](https://github.com/a2aproject/A2A/blob/main/docs/assets/a2a_logo/mascot/PNG/a2a_ada.png)
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_](https://a2a-protocol.org/latest/whats-new-v1/)
guide — five minutes to find out if anything affects you.
- **Need to upgrade your Python A2A Agent?** Start with the
[migration guide](https://github.com/a2aproject/a2a-python/blob/main/docs/migrations/v1_0/README.md) — 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](https://a2aproject.github.io/a2a-itk/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!
______________________________________________________________________
---
## Three Agents Behind One Door: Multi-Tenancy in A2A
Source: https://msampathkumar.github.io/writing/a2a/multi-tenancy/
> Originally published on
> [dev.to](https://dev.to/sampathm/three-agents-behind-one-door-multi-tenancy-in-a2a-1pih)
> / [Medium](https://medium.com/google-cloud/a2a-multi-tenancy-ebfbc255497a).
 _A2A Multi-Tenancy: 3 ways to scale
your Agentic Apps real fast 🚀_
### 1. Introduction
With the launch of the new **ADK v2.0** SDK, building and customizing agents
has become simpler and easier. But the moment your team ships its second or
third agent, an infrastructure question shows up: _do we really want a separate
hostname or endpoint for every agent — and how do we connect them all?_
A quick bit of history: last year Google open-sourced the **A2A Protocol**
(Apache 2.0) to give agents a standard way to talk to each other and
collaborate on tasks, then donated it to the Linux Foundation. Over the past
year A2A has matured — sharpening the protocol standards, improving the
developer experience, and reaching enterprise readiness with the recent **A2A
v1.0** release.
New to A2A? Here’s the one-line recap: **just as MCP is a wrapper over your
tools and services, A2A is a wrapper over your agents** — both bring
portability, simplicity, and scalability to agentic systems.
One of A2A’s newer features is **multi-tenancy**. Now that building agents is
easy, multi-tenancy lets you host multiple independent agents (agentic apps)
under a single system. Each app shares the same A2A server but is reachable at
its own URL endpoint — and, just like a standalone A2A app, each keeps its own
Agent Card, Agent Skills, communication standard, and the rest of the A2A
features.
To show it off, this post walks through **three ways to build multi-tenant
applications in A2A** , then builds a small interactive demo that shows how
multi-tenancy makes agentic apps easy to build and scale.
### 2. What you’ll learn
By the end of this post, you’ll walk away with:
- **What A2A multi-tenancy is** — many independent agents behind one server,
each reachable at its own endpoint.
- **The three ways to route** a request to the right agent — and a rule of
thumb for when to reach for each.
- **Why it stays simple** — routing config lives in each agent’s Agent Card,
so clients don’t hard-code anything.
- **How to build it** — a small, runnable demo: one server hosting three
agents, and one interactive client that discovers and talks to them.
### 3. Three ways to add multi-tenancy
A2A is deliberately unopinionated about routing. It doesn’t prescribe an
implementation; it gives you **three composable mechanisms** , and routing
config always lives in the **Agent Card** — so your clients stay simple and
your topology stays discoverable.
#### Approach 1 — URL sub-path routing
Give each agent its own URL prefix, and let each Agent Card advertise that URL.
Clients need **no special awareness** — they read the card and send requests
where it points. (This is the approach our demo uses.)
 _A2A Multi-tenancy with URL sub-path
routing_
👉 **Tip:** Use this when you have a small, fixed set of agents and want the
setup that’s easiest to build, scale and debug — the route shows up right in
your access log.
#### Approach 2 — Authentication header-based routing
When several agents share _the same_ URL, a gateway can route based on the
credential already in the request. Because A2A declares auth requirements in
the Agent Card (securitySchemes / securityRequirements), this stays fully
discoverable — and the A2A message itself is never modified.
 _A2A Multi-tenancy with header-based
routing_
**Common patterns:** a **bearer token** whose claims (audience, scope) identify
the target agent, or an **API key** the gateway maps to a particular agent.
👉 **Tip:** Use this when you already have solid auth (+ access) management and
want routing to come for free from it. Every agent shares one URL, your routing
layout isn’t exposed.
#### Approach 3 — Body-based routing with the tenant field
Every A2A request can carry an optional tenant field — an **opaque string**.
The protocol imposes no format or meaning; the value is whatever the server
operator decides (an agent id, a workspace slug, an org id). The value a client
should send is advertised on the agent's AgentInterface.
**The one rule you must not break:** the client **MUST** echo the tenant value
from the selected AgentInterface back in _every_ request message. If the
interface doesn't set tenant, the field **MUST** be omitted. (This is the
normative client rule in spec §8.3.2.)
 _A2A Multi-tenancy with tenant field_
👉 **Tip:** Use this when you want a single URL and give options to the client
to select the routing direction.
#### Bringing it all together
These aren’t mutually exclusive. A realistic large deployment might use
**sub-path routing** to separate major product lines and the **tenant field**
to separate individual customers within each line — while **header-based
routing** quietly handles auth the whole time. The right combination depends on
your gateway and architecture, not on the protocol.
And it all rides on discovery: when several agents live behind a shared domain,
**each agent publishes its own Agent Card**. Clients fetch each card
independently and use its supportedInterfaces data — including any tenant
value — to reach the right agent. Get the cards right, and the routing takes
care of itself.
### 4. Building the demo app
To make this concrete, we’ll stand up **three agents behind one host** and talk
to each of them — using Approach 1 (URL sub-paths).
Sub-pathAgentWhat it does/helloHello World AgentReplies with a friendly
hello/palindromePalindrome AgentSays whether your text is a
palindrome/reverseWord Reverse AgentReverses the order of the words in your
text
These three are intentionally trivial echo-style mocks — the focus is on
_routing_, not on what the agents do. (We also drop the authenticated
“extended” Agent Card; each agent has a single, public card so the example
stays about routing.)
#### How it works
- **server.py** starts one Starlette/uvicorn server and, in a short loop,
mounts each agent's Agent Card + JSON-RPC endpoint on its own sub-path. Every
agent shares one small AgentExecutor parameterized by a plain text -> text
function — so adding a fourth agent is a one-liner.
- **client.py** hard-codes nothing. It fetches each agent's Agent Card
(discovery), shows a menu, prints an "about this agent" summary from the card
(endpoint, protocol, input/output formats, skills), then sends your messages
to the agent you picked. An empty message exits.
#### Run it
```console
pip install "a2a-sdk>=1.0.3" uvicorn starlette httpx
python a2a_server.py # serves all three agents on :9999
python a2a_client.py # in another terminal (add --mode stream to stream)
```
#### The code
[**a2a_server.py**](https://github.com/a2aproject/a2a-samples/blob/main/samples/python/agents/multitenancy/a2a_server.py) — hosts
the three agents on sub-paths:
```python
"""a2a_server.py -- Multi-tenancy demo: three A2A agents behind ONE host.
Companion to the "A2A Multi-Tenancy" blog post. Run it, then run a2a_client.py.
pip install "a2a-sdk>=1.0.3" uvicorn starlette httpx
python a2a_server.py
It hosts three tiny "echo-style" agents, each on its own URL sub-path:
http://127.0.0.1:9999/hello -> Hello World agent (says hello)
http://127.0.0.1:9999/palindrome -> Palindrome agent (is it a palindrome?)
http://127.0.0.1:9999/reverse -> Word-reverse agent (reverses word order)
Each agent publishes its own Agent Card at /.well-known/agent-card.json,
so a client just reads the card and sends requests where it points.
"""
import os
from collections.abc import Callable
import uvicorn
from a2a.helpers import (
get_message_text,
new_task_from_user_message,
new_text_message,
new_text_part,
)
from a2a.server.agent_execution import AgentExecutor, RequestContext
from a2a.server.events import EventQueue
from a2a.server.request_handlers import DefaultRequestHandler
from a2a.server.routes import create_agent_card_routes, create_jsonrpc_routes
from a2a.server.tasks import InMemoryTaskStore, TaskUpdater
from a2a.types import AgentCapabilities, AgentCard, AgentInterface, AgentSkill
from a2a.types.a2a_pb2 import TaskState
from a2a.utils.constants import AGENT_CARD_WELL_KNOWN_PATH
from starlette.applications import Starlette
BIND_HOST = os.environ.get("A2A_BIND_HOST", "127.0.0.1")
PORT = int(os.environ.get("A2A_PORT", "9999"))
PUBLIC_URL = os.environ.get("A2A_PUBLIC_URL", f"http://127.0.0.1:{PORT}")
# --- The three agent "brains": trivial text -> text functions. ---
def hello_world(text: str) -> str:
"""Classic hello-world echo."""
return f'Hello, World! You said: "{text}"'
def palindrome(text: str) -> str:
"""Report whether the input reads the same forwards and backwards."""
cleaned = "".join(ch.lower() for ch in text if ch.isalnum())
if not cleaned:
return "Send me some text and I will check if it is a palindrome."
verdict = "is" if cleaned == cleaned[::-1] else "is not"
return f'"{text}" {verdict} a palindrome.'
def reverse_words(text: str) -> str:
"""Reverse the order of the words in the input."""
if not text.strip():
return "Send me a sentence and I will reverse the word order."
return f'Reversed: {" ".join(reversed(text.split()))}'
# --- One small AgentExecutor, parameterized by a transform function. ---
class SimpleAgentExecutor(AgentExecutor):
"""Runs one text -> text transform; A2A does the rest of the work."""
def __init__(self, transform: Callable[[str], str]) -> None:
self.transform = transform
async def execute(self, context: RequestContext, event_queue: EventQueue) -> None:
"""Process user request."""
# 1. Collect a task from the request context.
if context.current_task:
task = context.current_task
else:
# 1.1 If there is no task, create one and add it to the event queue.
task = new_task_from_user_message(context.message)
await event_queue.enqueue_event(task)
# 2. Update task status in the EventQueue using a TaskUpdater object.
updater = TaskUpdater(
event_queue=event_queue, task_id=task.id, context_id=task.context_id
)
await updater.update_status(
state=TaskState.TASK_STATE_WORKING,
message=new_text_message("Working on it..."),
)
# 3. Collect the user's text and run this tenant's transform on it.
query = get_message_text(context.message)
result = self.transform(query) if query else "No text input was provided!"
# 4. Add the generated response as an artifact to the EventQueue.
await updater.add_artifact(
parts=[new_text_part(text=result, media_type="text/plain")]
)
# 5. Mark the task completed.
await updater.update_status(
state=TaskState.TASK_STATE_COMPLETED,
message=new_text_message("Done!"),
)
async def cancel(self, context: RequestContext, event_queue: EventQueue) -> None:
"""Raise exception as cancel is not supported."""
raise NotImplementedError("Cancel is not supported.")
def build_card( # noqa: PLR0913 - demo helper: one clear arg per card field
path: str,
name: str,
description: str,
skill_id: str,
skill_name: str,
examples: list[str],
) -> AgentCard:
"""Each agent advertises its OWN card, pointing at its OWN sub-path."""
return AgentCard(
# Basic identity information for this tenant's A2A server.
name=name,
description=description,
version="1.0.0",
# Default media types for the agent's interactions.
default_input_modes=["text/plain"],
default_output_modes=["text/plain"],
# Supported A2A features (here, streaming responses).
capabilities=AgentCapabilities(streaming=True),
# The endpoint(s) where this agent can be reached. This is the heart of
# sub-path routing: each card points clients at its own URL prefix.
supported_interfaces=[
AgentInterface(
protocol_binding="JSONRPC",
url=f"{PUBLIC_URL}{path}",
protocol_version="1.0",
)
],
# The list of AgentSkill objects this agent offers.
skills=[
AgentSkill(
id=skill_id,
name=skill_name,
description=description,
input_modes=["text/plain"],
output_modes=["text/plain"],
tags=["a2a", "echo-example", "multi-tenancy"],
examples=examples,
)
],
)
# One (sub-path, card, executor) entry per tenant agent.
AGENTS = [
(
"/hello",
build_card(
"/hello",
"Hello World Agent",
"Replies with a friendly hello.",
"hello",
"Say hello",
["hi", "hello there"],
),
SimpleAgentExecutor(hello_world),
),
(
"/palindrome",
build_card(
"/palindrome",
"Palindrome Agent",
"Tells you whether your text is a palindrome.",
"palindrome",
"Palindrome check",
["racecar", "hello"],
),
SimpleAgentExecutor(palindrome),
),
(
"/reverse",
build_card(
"/reverse",
"Word Reverse Agent",
"Reverses the order of the words in your text.",
"reverse",
"Reverse words",
["hello world", "agents talking to agents"],
),
SimpleAgentExecutor(reverse_words),
),
]
def build_app() -> Starlette:
"""Mount each agent's card + JSON-RPC endpoint on its own sub-path."""
routes = []
for path, card, executor in AGENTS:
# The RequestHandler processes incoming requests and manages tasks for
# this one tenant, backed by its own in-memory task store.
handler = DefaultRequestHandler(
agent_executor=executor,
task_store=InMemoryTaskStore(),
agent_card=card,
)
# Publish this agent's Agent Card under /.well-known/... so
# clients can discover it independently of the other tenants.
routes.extend(
create_agent_card_routes(
card, card_url=f"{path}{AGENT_CARD_WELL_KNOWN_PATH}"
)
)
# Mount this agent's JSON-RPC endpoint on its own sub-path.
routes.extend(create_jsonrpc_routes(handler, rpc_url=path))
# A single Starlette app fronts all three agents on one host/port.
return Starlette(routes=routes)
if __name__ == " __main__":
print(f"Serving three A2A agents (bind {BIND_HOST}:{PORT}, public {PUBLIC_URL}):")
for sub_path, agent_card, _ in AGENTS:
print(f" {PUBLIC_URL}{sub_path} -> {agent_card.name}")
uvicorn.run(build_app(), host=BIND_HOST, port=PORT)
```
[**a2a_client.py**](https://github.com/a2aproject/a2a-samples/blob/main/samples/python/agents/multitenancy/a2a_client.py) — discovers
the agents and chats with your pick:
```python
"""a2a_client.py -- Interactive client for the multi-tenancy demo (a2a_server.py).
Companion to the "A2A Multi-Tenancy" blog post.
pip install "a2a-sdk>=1.0.3" httpx
python a2a_server.py # in one terminal
python a2a_client.py # in another (non-streaming, default)
python a2a_client.py --mode stream # streaming replies
Flow:
1. The client discovers the agents the server hosts (one Agent Card each).
2. It prints a menu -- press 1, 2 or 3 to pick which agent to connect to.
3. Type a message; the chosen agent replies (hello / palindrome / word-reverse).
4. Press Enter on an empty message to exit.
The only CLI option is --mode, which selects how replies are received:
--mode message non-streaming: one reply per message (default)
--mode stream streaming: events arrive as the agent works
"""
import argparse
import asyncio
import os
from collections.abc import Iterable
import httpx
from a2a.client import A2ACardResolver, ClientConfig, create_client
from a2a.helpers import get_message_text, new_text_message
from a2a.types import AgentCard
from a2a.types.a2a_pb2 import Artifact, Role, SendMessageRequest, StreamResponse
PORT = int(os.environ.get("A2A_PORT", "9999"))
BASE_URL = f"http://127.0.0.1:{PORT}"
# The sub-paths a2a_server.py exposes, in menu order.
AGENT_PATHS = ["/hello", "/palindrome", "/reverse"]
def _print_artifacts(artifacts: Iterable[Artifact]) -> None:
for artifact in artifacts:
for part in artifact.parts:
if part.text:
print(f"agent > {part.text}")
def print_reply(event: StreamResponse) -> None:
"""Print the human-readable reply from a StreamResponse (either mode)."""
kind = event.WhichOneof("payload")
if kind == "task": # non-streaming: full task
_print_artifacts(event.task.artifacts)
elif kind == "artifact_update": # streaming: the result chunk(s)
_print_artifacts([event.artifact_update.artifact])
elif kind == "message":
print(f"agent > {get_message_text(event.message)}")
# 'status_update' (working/completed) is progress noise -- ignored here.
async def discover_agents(
http: httpx.AsyncClient,
) -> list[tuple[str, AgentCard]]:
"""Fetch each agent's card from its own sub-path."""
found: list[tuple[str, AgentCard]] = []
for path in AGENT_PATHS:
# A2ACardResolver reads the Agent Card from /.well-known/...
# Because each tenant has its own sub-path, we resolve one card per path.
resolver = A2ACardResolver(httpx_client=http, base_url=f"{BASE_URL}{path}")
try:
card = await resolver.get_agent_card()
found.append((path, card))
except Exception as exc: # noqa: BLE001 - demo: show why an agent is skipped
print(f"(skipping {path}: {exc})")
return found
def choose_agent(
agents: list[tuple[str, AgentCard]],
) -> tuple[str, AgentCard] | None:
"""Print the menu and return the (path, card) the user picks, or None."""
print("\nWhich A2A agent do you want to connect to?")
for i, (path, card) in enumerate(agents, start=1):
print(f" {i}. {card.name} ({BASE_URL}{path}) - {card.description}")
choice = input("Select 1, 2 or 3 (Enter to quit): ").strip()
if not choice:
return None
if choice.isdigit():
idx = int(choice) - 1
if 0 <= idx < len(agents):
return agents[idx]
print("Invalid choice.")
return None
# Friendly labels for the Agent Card's protocol binding.
PROTOCOL_LABELS = {
"JSONRPC": "JSON-RPC over HTTP",
"HTTP+JSON": "HTTP + JSON",
"GRPC": "gRPC",
}
def describe_agent(card: AgentCard) -> None:
"""Print a short, friendly summary built from the agent's Agent Card."""
iface = card.supported_interfaces[0] if card.supported_interfaces else None
protocol = (
PROTOCOL_LABELS.get(iface.protocol_binding, iface.protocol_binding)
if iface
else "unknown"
)
endpoint = iface.url if iface else "n/a"
inputs = ", ".join(card.default_input_modes) or "text"
outputs = ", ".join(card.default_output_modes) or "text"
skills = ", ".join(skill.name for skill in card.skills) or "-"
print(f"\nYou're connected to the {card.name}.")
print(f" {card.description}")
print(" --- from its Agent Card ---")
print(f" - Endpoint : {endpoint}")
print(f" - Protocol : {protocol}")
print(f" - Format : {inputs} in -> {outputs} out")
print(f" - Skills : {skills}")
async def main(mode: str) -> None:
"""Discover the agents, let the user pick one, and chat with it."""
async with httpx.AsyncClient() as http:
agents = await discover_agents(http)
if not agents:
print("No agents reachable. Is a2a_server.py running?")
return
picked = choose_agent(agents)
if not picked:
print("Bye!")
return
_path, card = picked
# Build a client for the chosen agent. The card carries the endpoint, so
# the client knows where to send requests; streaming is toggled by --mode.
client = await create_client(
agent=card,
client_config=ClientConfig(streaming=(mode == "stream")),
)
describe_agent(card)
print("\nType a message (empty to exit).")
try:
while True:
# input() is blocking, so run it off the event loop.
text = (await asyncio.to_thread(input, "you > ")).strip()
if not text: # empty message -> exit
print("Bye!")
break
# Wrap the user's text in an A2A message and send it. Replies are
# streamed back as events, which print_reply renders per mode.
request = SendMessageRequest(
message=new_text_message(text, role=Role.ROLE_USER)
)
async for event in client.send_message(request):
print_reply(event)
finally:
# Always close the client to release the underlying HTTP connection.
await client.close()
if __name__ == " __main__":
parser = argparse.ArgumentParser(
description="Interactive A2A multi-tenancy client."
)
parser.add_argument(
"--mode",
choices=["message", "stream"],
default="message",
help="how replies are received: 'message' (non-streaming, default) or 'stream' (streaming)",
)
args = parser.parse_args()
asyncio.run(main(args.mode))
```
#### See it in action
[](https://www.youtube.com/watch?v=RCmq0igoX3E "Agent2Agent (A2A) Protocol Multi-Tenancy Demo (Python)")
### 5. Takeaways & resources
#### Takeaways
- **Infrastructure Efficiency:** Hosting many agents behind one host requires a
small loop, not a massive rewrite. One shared server, with logically separate
endpoints.
- **Flexible Routing:** A2A gives you three routing primitives — sub-path, auth
header, and the tenant field. You can compose them to fit your exact gateway
needs.
- **Decentralized Config:** Routing config lives in the Agent Card. Clients
stay simple and your topology stays discoverable without hard-coded URLs.
- **The Single Client Rule:** Always echo the tenant field when the interface
sets it; omit it when it doesn’t.
#### Resources to get started
- **Multi-tenancy guide:**
[https://a2a-protocol.org/latest/topics/multi-tenancy/](https://a2a-protocol.org/latest/topics/multi-tenancy/)
- **A2A spec & docs:**
[https://a2a-protocol.org/latest/](https://a2a-protocol.org/latest/)
- **A2A on GitHub (⭐):**
[https://github.com/a2aproject/A2A](https://github.com/a2aproject/A2A)
- **Hello-world sample:**
[a2a-samples/samples/python/agents/helloworld](https://github.com/a2aproject/a2a-samples/tree/main/samples/python/agents/helloworld)
**A question for you:** when you put several agents behind one host, do you
reach for sub-paths, auth, or the tenant field first — and why?
**#A2A #AIAgents #MultiAgent #Python #PlatformEngineering**
______________________________________________________________________
---
## Breaking Down Agent Silos: The A2A Integration Test Kit Dashboard
Source: https://msampathkumar.github.io/writing/a2a/test-kit/
> Originally published on
> [dev.to](https://dev.to/sampathm/breaking-down-agent-silos-the-a2a-integration-test-kit-dashboard-is-here-4m60)
> /
> [Medium](https://medium.com/google-cloud/breaking-down-agent-silos-the-a2a-integration-test-kit-dashboard-is-here-71b5b85c290d).
#### 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](https://a2a-protocol.org/latest/) 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)](https://github.com/a2aproject/a2a-itk#readme) and
its [Dashboard](https://a2aproject.github.io/a2a-itk/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](https://a2aproject.github.io/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:
1. Stable Versions: Python v1.0 and Go v1.0
1. 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](https://github.com/a2aproject/a2a-itk/issues) or sync with
the team in
the[#a2a-tck](https://discord.com/channels/1362108044737253548/1392611003711094835)
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
the[ITK GitHub Repository](https://github.com/a2aproject/a2a-itk/tree/main/test_suite).
- **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](https://github.com/a2aproject/a2a-itk/tree/main#-task-backlog)
for delivery timelines.
______________________________________________________________________
---
## Introducing the Whitepaper on Building Secure Multi-Agent Frameworks on Google Cloud
Source: https://msampathkumar.github.io/writing/a2a/security-whitepaper/
> Originally published on
> [dev.to](https://dev.to/sampathm/introducing-the-whitepaper-on-building-secure-multi-agent-framework-on-google-cloud-11hc)
> /
> [Medium](https://medium.com/@maddula/introducing-the-whitepaper-on-building-secure-multi-agent-framework-on-google-cloud-dd16f65360bb).
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](https://services.google.com/fh/files/events/agent_security.pdf)
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://cloud.google.com/products/gemini-enterprise-agent-platform).
[https://services.google.com/fh/files/events/agent_security.pdf](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](https://services.google.com/fh/files/events/agent_security.pdf)\
→ Google SAIF (Secure AI Framework):
[https://saif.google/secure-ai-framework/saif-map](https://saif.google/secure-ai-framework/saif-map)\
→ Agent Identity & SPIFFE :
[https://docs.cloud.google.com/iam/docs/agent-identity-overview#spiffe-identity](https://docs.cloud.google.com/iam/docs/agent-identity-overview#spiffe-identity)\
→ Cloud Trace:
[https://docs.cloud.google.com/trace/docs/overview](https://docs.cloud.google.com/trace/docs/overview)\
→ Agent Gateway:
[https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview)
---
## Writing — Google Cloud Next 2026 series
## Part 1 — Intro & Next-Gen Infrastructure
Source: https://msampathkumar.github.io/writing/cloud-next-2026/infrastructure/
# Google Cloud Next 2026 (1/5) - Intro, Agentic Cloud & Next Gen Infrastructure
> This is from my personal collection/notes. Hope you find it informative :)
## Keynote by Thomas Kurian, CEO of Google Cloud: The Agentic Cloud ☁︎
At Next, Thomas Kurian signaled a major transition from the
`experimental phase 🧪` of generative AI toward
`building and deploying agentic systems at a global scale 🌍`. This shift
fundamentally moves AI away from being just a standalone tool or chatbot,
transforming it into a vertically optimized operating layer that orchestrates
hardware, data, and security in a single, cohesive stack.
For those unable to attend the conference, my core takeaway is the emergence of
a "unified control plane." The ultimate value of a cloud provider will no
longer be defined by raw storage or compute units, but by its ability to
securely manage swarms of specialized agents that successfully delegate complex
business outcomes.
______________________________________________________________________
# Next-Generation Infrastructure
The architectural requirements for autonomous agents differ substantially from
the batch-processing and training-intensive workloads of the previous decade.
To address these needs, Google Cloud unveiled its **eighth generation** of
custom silicon, strategically bifurcating its Tensor Processing Unit (TPU)
architecture to optimize for the two distinct phases of the AI lifecycle:
training and inference.
## 8th Generation TPUs for Agentic Training and Inference
The TPU 8t (Training) and TPU 8i (Inference) represent a significant
philosophical shift in hardware design. They are moving away from
general-purpose accelerators toward specialized chips co-designed with the
Gemini 3.x model family.
To put this into perspective, let's look at a practical example. Suppose you
have an AI workload that typically costs $100 and takes 1 hour. Using the
Ironwood chips released at Google Next 2025, you could complete that same work
in 15 to 30 minutes for about $70. That wasn't just a 30% cost savings—it cut
completion time by over 50%. Now, with the new 8th Gen TPUs, that same workload
could potentially be completed in just 10 minutes for training workloads, or a
lightning-fast 5 minutes (300 seconds) for inference workloads.
Here is how we are beginning to measure AI workloads now:
```mermaid
flowchart LR
A("In 2024 - Hours") -- "Google 7th Gen TPU Ironwood" --> B("In 2025 - Minutes")
A -- "Google 8th Gen TPUs 8i & 8t" --> C("In 2026 - Seconds")
```
To read more:
https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/eighth-generation-tpu-agentic-era
## Virgo Network: Google’s New Scale-Out Data Center Fabric
Massive compute power only goes so far if the networking fabric cannot keep
accelerators fed with data. Google Cloud introduced the Virgo Network, a
custom-built data center fabric designed to connect massive supercomputers with
deterministic, low latency. With foundational model parameters growing
exponentially, traditional networks are reaching their limits. Think of it as
removing every stoplight and intersection on a highway so data can move in a
straight line. It isn't just faster hardware; it's a fundamental shift in
network topology.
This Virgo Network can link **134,000 chips (TPU 8t)** with up to **47
petabits/sec** of non-blocking bi-sectional bandwidth in a single fabric.
Imagine training your AI models on this infrastructure - the speed and
performance would be simply mind-blowing!
To read more:
https://cloud.google.com/blog/products/networking/introducing-virgo-megascale-data-center-fabric
## Axion (ARM) Processor
Axion Processors are Google's custom Arm-based CPUs designed specifically for
the data center. Compared to current-generation x86-based instances, these
processors offer up to 50% better performance and 60% better energy efficiency.
While Google announced the processors a while ago, they are now becoming
**generally available (GA)** to Google Cloud customers. For businesses looking
to slash their carbon footprint without sacrificing speed, Axion provides a
clear path forward.
To read more:
https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu
______________________________________________________________________
*In my next blog post, I will be diving into the brain of the Agentic Cloud—the
Gemini Enterprise Agent Platform (GAP) and the newest additions to Google’s
foundational model family. Stay tuned!*
---
## Part 2 — GAP & Foundational Models
Source: https://msampathkumar.github.io/writing/cloud-next-2026/foundational-models/
# Google Cloud Next 2026 (2/5) - GAP & Foundational Models
> This is from my personal collection/notes. Hope you find it informative :)
In our first post, we explored key hardware developments such as 8th-Gen TPUs,
Axion processors, and Virgo Networks. Today, let's review the framework tying
them together: Google Cloud's Gemini Enterprise Agent Platform. For simplicity,
*I like to refer* to it as Google's Agent Platform (GAP) or simple Agent
Platform (AP).
One could easily assume GAP is simply a rebranding of Vertex AI, but it goes
much further. It represents the natural evolution of Vertex AI, reflecting
Google's intent to simplify the developer journey for building cloud-native
agentic systems. GAP unites model selection, building, and agent development
alongside advanced DevOps, orchestration, integration, and security.
**Quick Tip**: I've shared a list of these products with brief descriptions
below. Skim through and bookmark this page as a handy reference!
______________________________________________________________________
# Google Agent Platform (GAP)
*Note: For my easy of use, I casually refer to it as Google Agent Platform
(GAP) or simply Agent Platform (AP).*
## 🛠️ Build
- [**Agent Development Kit (ADK)**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/adk):
A code-first, graph-based framework for defining complex multi-agent logic
and reasoning.
- [**Agent Studio**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/agent-studio/overview):
A low-code, visual interface enabling developers to seamlessly move from
simple prompting to deploying sophisticated agents.
- [**Agent Garden**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/agent-garden):
A curated library of pre-built templates designed for specific operational
tasks like financial analysis and invoice processing.
- **Native Ecosystem Integrations**: A plug-and-play architecture to securely
connect agents to internal enterprise data and tools without custom code.
- [**Workspaces**](https://studio.workspace.google.com/): A hardened, sandboxed
environment for agents to safely execute bash commands and manage files.
## 🌎 Scale
- [**Agent Runtime**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime):
A high-performance execution engine providing sub-second cold starts and
native support for multi-day workflows.
- [**Agent Memory Bank**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank):
Dynamically generates and curates long-term "memories" to maintain context
across numerous user interactions.
- [**Agent Sessions**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/sessions):
A management tool mapping AI interaction history directly to internal CRM or
database records using custom IDs.
- [**Agent Sandbox**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/sandbox/code-execution-overview):
A secure environment for agents to execute model-generated code and carry out
browser-based automation.
- **Bidirectional Streaming**: A robust protocol utilizing WebSockets to enable
lag-free, real-time audio and video interactions.
## 🕹️ Govern
- [**Agent Identity**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity):
Assigns a unique, cryptographic ID to every agent, ensuring actions remain
auditable and secure.
- [**Agent Registry**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-registry):
A centralized enterprise library for indexing and discovering approved
agents, tools, and skills.
- [**Agent Gateway**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview):
The main control hub governing connectivity and consistent security policy
enforcement across agent swarms.
- [**Agent Policy**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/policies/overview):
Deterministic rules enforced via a Policy Engine to govern access controls
and business constraints by intercepting agent messages.
- [**Agent Anomaly Detection**](https://docs.cloud.google.com/bigquery/docs/anomaly-detection-overview):
Real-time monitoring leveraging statistical models to flag unusual reasoning
or suspicious agent behavior.
- [**Agent Security Dashboard**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/view-security-findings):
A unified interface integrated with Security Command Center to visualize
threats and monitor vulnerabilities.
- [**Model Armor**](https://cloud.google.com/security/products/model-armor?hl=en):
An advanced AI firewall screening all prompts and responses against specific
threats, including prompt injection, jailbreaks, and sensitive data leakage.
## 🧮 Optimize
- [**Agent Simulation**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/evaluate-simulated):
A robust testing environment generating synthetic user interactions to score
agent success and safety before production.
- [**Agent Evaluation**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/agent-evaluation):
Continuously scores live traffic using multi-turn "autoraters" to judge
entire conversation flows.
- [**Agent Observability**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/observability/overview):
Delivers execution traces and visual lenses into agent reasoning to
streamline developer debugging.
- [**Agent Optimizer**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/optimize-agent):
Automatically clusters real-world failures and suggests instruction
refinements to boost precision.
______________________________________________________________________
# ✨ Google Foundational Models
While GAP provides the operational architecture, the underlying Gemini 3.x
family drives the "intelligence" of the agentic era. Here is a great review to
get started on the new models:
- [**Gemini 3.X Models**](https://deepmind.google/models/gemini/): Google's
most capable models for complex reasoning, large-scale data analysis, and
sophisticated multi-agent orchestration.
- [**Nano Banana 2**](https://deepmind.google/models/gemini-image/flash/): A
high-speed, multimodal model optimized for low-latency visual reasoning and
image processing.
- [**Lyria 3**](https://deepmind.google/models/lyria/): A specialized model
engineered for high-fidelity audio generation and advanced musical AI
applications.
- [**Gemma 4**](https://deepmind.google/models/gemma/gemma-4/): The newest
generation of lightweight, open models built with core Gemini technology for
efficient edge deployments (available under the Apache 2.0 License!).
Notably, Google Cloud doesn't restrict developers to first-party options.
Thanks to robust partnerships, the
[**Model Garden**](https://console.cloud.google.com/agent-platform/overview)
grants access to over 200 first-party, open-source, and third-party models
including Anthropic's Claude series, LLaMA, Mistral, Qwen, DeepSeek, Nemotron,
and more.
To read more:
- [Gemini Models](https://blog.google/products-and-platforms/products/gemini/)
- [Gemini 3.1 Flash-Lite: Built for intelligence at scale](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-flash-lite/)
______________________________________________________________________
*Curious about how developers actually interact with all this? In my next post,
we will cover Google’s modern Developer Tools, guides, and new MCP Servers!*
---
## Part 3 — Developer Tools & MCP Servers
Source: https://msampathkumar.github.io/writing/cloud-next-2026/dev-tools-mcp-servers/
# Google Cloud Next 2026 (3/5) - Developer Tools, Guides, and MCP Servers
> This is from my personal collection/notes. Hope you find it informative :)
In my first post, we reviewed hardware updates like 8th-Gen TPUs, Axion
processors, and Virgo Networks. In my second, we peeked into Google Cloud's
Gemini Enterprise Agent Platform and its underlying models. For this third
part, let's shift our focus to the Developer Tools that Google Cloud makes
available to users.
______________________________________________________________________
## 👨🏻💻 Developer Tools, Guides, and MCP Servers
- [**Google ADK**](https://adk.dev/): The open-source agent development
framework that lets you build, debug, and deploy reliable AI agents at
enterprise scale. Available in Python, TypeScript, Go, and Java.
- [**Agent CLI**](https://github.com/google/agents-cli): Serves as both a CLI
tool and a **Skill package** for your agentic developer environments
(including Gemini CLI, Antigravity, Codex, Claude Code, and others).
- [**Agent Skills**](https://github.com/google/skills/tree/main): Pre-packaged
agent skills tailored for Google products and technologies, including Google
Cloud integrations.
- [**Google Antigravity**](https://antigravity.google/): An advanced agentic
development platform that evolves the traditional IDE into an autonomous,
multi-surface "mission control" where AI agents plan, execute, and verify
complex software tasks.
- [**Google Cloud Data Agent Kit**](https://docs.cloud.google.com/data-cloud-extension/vs-code/install):
A rich Visual Studio Code extension designed for data engineers, scientists,
and app developers to efficiently manage data assets, run queries, and deploy
data pipelines.
## 🔌 MCP Servers
- [**Google Workspace MCP Servers**](https://docs.cloud.google.com/mcp/supported-products#google-workspace-mcp-servers):
A collection of MCP server your agents can use to interact with Google
Workspace products(Calendar, Gmail, Drive, etc).
- [**Google Cloud MCP Servers**](https://docs.cloud.google.com/mcp/supported-products#google-cloud-mcp-servers):
A collection of MCP server your agents can use to interact with Google Cloud
products(Agent Registry, BigQuery, Cloud Run, Cloud Sql, Firestore,
Memorystore, Pub/Sub, etc).
## 📚 Free Learning Resources & References
- **Professional Certification**:
[Google AI Professional Certificate](https://www.coursera.org/professional-certificates/google-ai)
(8 hrs)
- **Hands-on Labs**: Over 75 free codelabs available at
[Google Cloud Next 2026 Codelabs](https://codelabs.developers.google.com/?event=googlecloudnext2026)
- **Sub-Agents Deep Dive**: Read "Mastering Gemini CLI Subagents" on Medium
([Part 1](https://medium.com/google-cloud/mastering-gemini-cli-subagents-part-1-a4666091c154)
&
[Part 2](https://medium.com/google-cloud/mastering-gemini-cli-subagents-part-2-tool-isolation-advanced-governance-af4cbb287204))
- **White Paper**: Dive into enterprise security with
[Agent Security Overview](https://services.google.com/fh/files/events/agent_security.pdf)
- **Atlas Agents (WIP)**: Check out the work-in-progress book by A. Gulli on
[GitHub](https://github.com/agulli/atlas-agents)
______________________________________________________________________
*In my fourth post, I will unpack the "Agentic Data Cloud"—from Spanner Omni to
the standardized Iceberg data layer, along with the newly governing A2A & MCP
protocols. Stay tuned!*
---
## Part 4 — Data Cloud, Protocols & Security
Source: https://msampathkumar.github.io/writing/cloud-next-2026/data-protocols-security/
# Google Cloud Next 2026 (4/5) - The Agentic Data Cloud, Agent Protocols & Agentic Security
> This is from my personal collection/notes. Hope you find it informative :)
In this post, we’ll focus on the "Agentic Data Cloud," the open protocols
allowing systems to communicate securely, and the next-generation security
required to protect them.
______________________________________________________________________
## The Agentic Data Cloud
An AI agent is ultimately only as intelligent as the data it understands.
Therefore, enterprise data is shifting from a passive, siloed resource into a
dynamic "System of Action." To support this, Google Cloud announced a new data
architecture optimized specifically for the speed and scale of agentic
reasoning.
### Knowledge Catalog and the Semantic Layer
The **Knowledge Catalog** (formerly the Dataplex Universal Catalog) serves as
the semantic map of an organization. Using Gemini, it autonomously tags and
connects data points across an enterprise's estate. This ensures agents
accurately understand corporate nomenclature, solving a common point of failure
where agents cannot execute tasks because they lack access to legacy databases
or unstructured files.
To read more: https://docs.cloud.google.com/dataplex/docs/introduction
### Cross-Cloud Lakehouse and Apache Iceberg Standardization
In a deliberate push for interoperability, Google Cloud has standardized its
data layer on [Apache Iceberg](https://iceberg.apache.org/). The new
[Cross-Cloud Lakehouse](https://cloud.google.com/products/lakehouse) allows
organizations to store data anywhere—including AWS or Azure—and query it
seamlessly. By positioning BigQuery as the foundational "reasoning surface"
rather than just storage, Google Cloud is directly answering the demands of
modern multi-cloud enterprises.
To read more:
https://docs.cloud.google.com/lakehouse/docs/about-cross-cloud-lakehouse
### Spanner Omni: True Database Portability
For developers, one of the most impactful announcements was
[Spanner Omni](https://cloud.google.com/products/spanner/omni), a downloadable
edition of Google’s flagship distributed database. Spanner Omni lets
enterprises run Spanner in their own data centers, multi-cloud architectures,
or even local development environments while maintaining industry-leading
consistency and availability. This is crucial for regulated sectors like
finance, where data residency and strict jurisdictional control are
non-negotiable.
To read more: https://cloud.google.com/products/spanner/omni
______________________________________________________________________
## The Agentic Protocols
The strategic narrative at Next 2026 was dominated by ecosystem leadership over
proprietary lock-in. To champion this, Google Cloud is heavily promoting two
major open protocols:
### Model Context Protocol (MCP) Everywhere
Google Cloud has integrated the
[Model Context Protocol (MCP)](https://docs.cloud.google.com/mcp/supported-products#google-cloud-mcp-servers)
across its major services by default. This allows agents to securely connect to
external tools (like BigQuery, AlloyDB, Firestore, or third-party CRMs) without
needing custom API layers. Managed MCP servers eliminate the operational
friction of securely anchoring models to production data.
### The Agent2Agent (A2A) Protocol
Reaching [version 1.0](https://a2a-protocol.org/latest/) and now governed by
the Linux Foundation’s Agentic AI Foundation, the **A2A protocol** provides a
standardized language for disparate agents (such as AWS Bedrock, Microsoft
Copilot, or Salesforce Agentforce) to route tasks and communicate securely.
Over 150 organizations already leverage A2A in production using
cryptographically signed "Agent Cards" to strictly define agent capabilities.
______________________________________________________________________
## Protecting the Agentic Enterprise: Autonomous Security
As machines generate more code and agents act autonomously, the enterprise
threat landscape changes entirely. Google Cloud introduced
[Agentic Defense](https://cloud.google.com/blog/products/identity-security/next26-redefining-security-for-the-ai-era-with-google-cloud-and-wiz),
deploying AI as the primary hunter and automated responder to secure
organizations from within.
### Agentic SecOps & Dark Web Intelligence
The
[Agentic SecOps](https://cloud.google.com/security/products/security-operations)
platform deploys specialized autonomous threat-intelligence agents. For
instance, the Dark Web Intelligence agent (powered by the Google Threat
Intelligence Group) maps an enterprise's specific vulnerabilities and evaluates
millions of daily external events. Internal tests show it can reach 98%
accuracy in threat triage, allowing human security analysts to focus strictly
on complex investigations rather than sorting false positives.
To read more: https://cloud.google.com/security/products/security-operations
______________________________________________________________________
*For more amazing updates, stay tuned!*
---
## Part 5 — Workspace Reimagined & AI Agents
Source: https://msampathkumar.github.io/writing/cloud-next-2026/workspace-ai-agents/
# Google Cloud Next 2026 (5/5) - Workspace Reimagined & AI Agents
> This is from my personal collection/notes. Hope you find it informative :)
In our final post covering Google Cloud Next 2026, we examine how the agentic
era manifests for the everyday workforce—evolving Google Workspace into a
unified "agentic taskforce."
______________________________________________________________________
## Productivity Reimagined: Workspace and "Skills"
For the broader workforce, Google Workspace has transitioned from traditional
productivity tools into a cohesive platform for orchestrating automated work.
The key innovation here is **Skills**—modular AI integrations that allow
organizations to orchestrate and deploy targeted automation across their entire
employee base.
### Workspace Studio and the No-Code Future
**Workspace Studio** is a robust, no-code platform that allows business users
to build and deploy Skills natively across Gmail, Docs, Drive, and Meet.
Organizations can easily create Skills to automate highly repetitive
operations, such as parsing vendor invoices or synthesizing multi-platform
meetings. Best of all, these Skills are as simple to share as a Google Doc,
making crowdsourced organizational efficiency genuinely achievable.
### Video Reimagined: Google Vids
**Google Vids** anchors the multimedia story of the agentic era, now offering
fully realistic AI avatars in 24 distinct languages. Teams can direct these
avatars to deliver tailored, on-brand messaging—including customized branded
clothing and backdrops—without ever needing a physical studio. Already,
millions of active users leverage Vids to convert static presentations into
narrated, highly engaging video assets.
To read more: https://workspace.google.com/products/vids/
### Collaborative Meeting Intelligence
- **Smart Meetings**: The "Take Notes for Me" capability has transcended Google
Meet. It now actively captures key summaries and action items from in-person
conversations or calls placed via mobile devices, Zoom, and Teams.
- **Sheets Canvas**: Transforms standard spreadsheets into dynamic, interactive
workspaces. Users can build visually appealing heat maps, Kanban boards, and
customized dashboards without writing a single line of code.
- **Gemini Enterprise App**: Acts the primary daily gateway for millions of
workers. The app now natively integrates with Calendar for frictionless
scheduling and features a "Canvas Mode" allowing direct, tab-free document
editing.
To read more: https://workspace.google.com/solutions/ai
______________________________________________________________________
*That concludes my summary of Google Cloud Next 2026! I hope you found this
series helpful. Next week, I will be taking a close look at how to get started
with autonomous development using Google Antigravity. Let me know your thoughts
in the comments!*
---
## Writing — Gemini guides
## Gemini CLI Cheatsheets
Source: https://msampathkumar.github.io/writing/gemini/cli-cheatsheets/
# Gemini CLI Cheatsheet Printout
Google's Gemini models are a powerful family of multimodal AI models. For developers and power users who live in the terminal, `gcloud` provides a robust command-line interface to interact with Gemini on Vertex AI.
To help you keep the most common commands at your fingertips, I've created a handy CLI cheatsheet available in both light and dark themes. Download your preferred version and get started!
## Light Theme
**Download Links**: [PNG](gemini-cli-cheatsheet-printout/cheatsheet.png) & [PDF](gemini-cli-cheatsheet-printout/cheatsheet.pdf).
## Dark Theme
**Download Links**: [PNG](gemini-cli-cheatsheet-printout/cheatsheet-dark-theme.png) & [PDF](gemini-cli-cheatsheet-printout/cheatsheet-dark-theme.pdf).
## Getting Started
Before you can use these commands, you need to set up your local environment and Google Cloud project. Follow the [Gemini Cookbook Setup guide](https://github.com/google-gemini/gemini-cli?tab=readme-ov-file#-installation) to get everything configured correctly.
Happy coding!
---
## Gemini CLI — Top Commands
Source: https://msampathkumar.github.io/writing/gemini/cli-top-commands/
# Master Your Workflow: Top Gemini CLI Commands You Should Know
I've always been a terminal dweller. There's something uniquely satisfying about staying in the command line, but as my workflows grew, I found myself constantly context-switching—jumping to the browser to check docs, to a GUI for Git, and back. It was a focus killer.
That changed when I started integrating the Gemini CLI into my daily routine. Instead of leaving the terminal, I now have Google's AI models directly in my command line as a context-aware pair programmer. It's drastically streamlined my workflow, and I wanted to share the commands I find most useful.
## 🚀 Getting Started: The Essentials
Here are the foundational commands I use to get oriented in a new project.
* **/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?"
```aiexclude
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ > 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."
```
## Final Thoughts
Integrating these commands took a bit of muscle memory at first, but it's vastly improved how I work day-to-day. If you're also trying to maximize your terminal time, I definitely recommend giving some of these a shot.
What does your terminal setup look like? I'm always looking for ways to optimize my workflow, so let me know if you have any favorite CLI tricks.
---
## Gemini 2.5 Flash Image Preview
Source: https://msampathkumar.github.io/writing/gemini/flash-image-preview/
## **Gemini 2.5 Flash vs. Gemini 2.0 Flash: A New Era for AI Image Generation**
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.
______________________________________________________________________
### **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.
You can find my final image at the [link](gemini-2.5-flash-image-preview.png).
**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.
## 
### **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.
### Links:
- [Gemini 2.5 Flash Image Preview](https://cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-flash#image)
- [Gemini 2.0 Flash Image](https://cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-0-flash#image-generation)
---
## Gemini as your Culinary Guide
Source: https://msampathkumar.github.io/writing/gemini/culinary-guide/
# Gemini: Your Culinary Guide in Italy 🇮🇹 🍕
Savoring Italy, One Personalized Recommendation at a Time
## The Challenge: Vegetarian Food Abroad
Last week I had a wonderful trip to Bologna, Italy. Since I don’t speak italian
🇮🇹my biggest concern was how do I ask for Indian vegetarian food ? Indian
Vegetarian also known as lato-vegeterian. In short, they are vegans who also
eat any milk products.
Usually my trips are planned ahead of time, but this trip was n’t. Luckily the
Gemini proved invaluable. Instead of manually searching for answers to various
inquiries, I leveraged its capabilities for real-time recommendations.
## How Gemini Helped
To Gemini, I'd provide restaurant details I am in, and it would swiftly analyze
reviews to offer a curated list of top choices based on my criteria. I visited
3-4 restaurants, and by maintaining the same chat thread, Gemini developed a
clear understanding of my preferences, ensuring each recommendation was highly
tailored.
With Gemini assistance, I am looking forward to visiting more Italian
restaurants 🇮🇹🍕😋 #LLM #AI #Gemini #EverydayTech #TravelTips #Innovation
---
## Writing — Technical articles
## The Six Essential Protocols Powering the AI Agent Ecosystem
Source: https://msampathkumar.github.io/writing/technical/six-essential-protocols/
# The Six Essential Protocols Powering the AI Agent Ecosystem
Six protocols are quietly emerging as the foundation of AI agent architecture: MCP, A2A, AG-UI, A2UI, AP2, and UCP. Together, they map out how agents will interact with tools, each other, users, and commerce systems. I've put together a quick breakdown of what they are and why they matter for the future of development.
| Protocol | Purpose | Key Benefit |
|----------|---------|-------------|
| **MCP** | Agent → Tools | One connector for every tool |
| **A2A** | Agent → Agent | Discover, coordinate, delegate |
| **AG-UI** | Agent → Frontend | Secure state & approval flows |
| **A2UI** | Agent → UI Generation | Rich interfaces, not just text |
| **AP2** | Agent → Payments | Cryptographic transaction safety |
| **UCP** | Agent → Commerce | One standard, every retailer |
As AI agents become increasingly sophisticated, standardizing how they communicate is critical. Just as the early web relied on HTTP and TCP/IP, the emerging agent ecosystem is being shaped by a new generation of open protocols.
Over the past year, I've spent a lot of time building and experimenting with AI agents. Through that work, I've identified six foundational protocols that are shaping the ecosystem. Here is how they form the backbone of modern 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](https://modelcontextprotocol.io/docs/getting-started/intro) 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](https://a2a-protocol.org/latest/) 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](https://docs.ag-ui.com/introduction) 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](https://a2ui.org/) 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](https://github.com/google-agentic-commerce/AP2) 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](https://ucp.dev/) 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 protocols—they work together to create a strong ecosystem:
## Real-World Impact: How These Protocols Transform Daily Work
Let me share an example. Say 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
---
## The Role of Python in Google Cloud
Source: https://msampathkumar.github.io/writing/technical/python-in-google-cloud/
# **Python in Google Cloud: More Than Just Examples for Gemini**
Is Python the ultimate language for Google Cloud development? Is it Google's
official recommendation, or do alternatives like Java, Go, or Rust hold sway in
specific scenarios? These are crucial questions for any developer building on
Google Cloud, particularly when diving into Generative AI with Gemini. This
article offers an opinionated, yet fact-driven, perspective on Python's
prominent role, clarifying why you often encounter Python examples in Google
Cloud documentation, especially for Gemini features.
## **The Genesis of a Preference: Python's Rise in My Early Career**
My journey into advanced programming and data analysis began long before "Data
Science" became a household term. Before an internship at Standard Chartered
Bank in 2012, my programming toolkit was dominated by C and Java, with Python
being more of a personal project companion.
The internship presented a unique challenge: sifting through mountains of Unix
system health and performance data to predict maintenance needs and identify
system improvements. My initial inclination was to leverage Java, given my
familiarity. However, my mentor, Asjorn, encouraged me to explore Python. This
pivotal decision unveiled Python's unexpected power and laid the groundwork for
its consistent presence in my projects.
Over the years, Python became the language of choice for almost all data
science initiatives I led, driven by several compelling advantages:
1. **Code Readability and Maintainability:** Python's clean, intuitive syntax
drastically lowered the learning curve, making code easier to understand,
write, and debug. This is a benefit Google itself recognizes and
[inspired Go language](https://techcrunch.com/2009/11/10/google-go-language/)
development in certain ways.
1. **Efficiency for Lean Teams:** Python's conciseness allowed smaller
development teams to achieve significant outcomes, often comparable to what
larger teams using more complex or "low-code" solutions might accomplish.
Its extensive ecosystem contributes to rapid development.
1. **Prioritizing Availability Over Raw Performance:** For many projects, the
immediate availability of services, scripts, and tools proved more critical
than bleeding-edge performance. With compute power becoming increasingly
affordable, Python enabled rapid deployment and iteration. This is
particularly true for scripting and prototyping.
1. **"Batteries Included" for Data-Intensive Tasks:** Python boasts a rich
standard library and a vast ecosystem of third-party packages, particularly
beneficial for data manipulation and analysis. This extensive library
support is a consistent benefit for cloud development.
## **Python's Enduring Reign in Data Science and Cloud Computing**
Python's appeal in data science continued to grow for two additional reasons,
deeply intertwined with cloud development:
1. **Rapid Prototyping:** The interactive interpreter and tools like
[Google Colab](https://colab.google.com/) make Python invaluable for agile
data analytics workflows. This capability is essential for quickly testing
ideas and developing proofs of concept.
1. **Robust Community and Specialized Libraries:** Public libraries such as
NumPy, Pandas, and Scikit-learn, despite often having performance-critical
core logic written in lower-level languages like C or Fortran, offer
user-friendly Python interfaces. Google taps into Python's extensive library
ecosystem, with machine learning and AI projects benefiting from libraries
like [TensorFlow](https://en.wikipedia.org/wiki/TensorFlow).
## **Decoding Python's Presence in Google Cloud's Generative AI (Gemini)**
This brings us to Python's specific role within
[Google Cloud's Generative AI](https://github.com/GoogleCloudPlatform/python-docs-samples/),
particularly with Gemini. You'll find a significant number of Python examples
for Gemini features, and this isn't by accident.
The primary reason for the prevalence of Python samples is its **readability
and speed of prototyping**. For quickly demonstrating capabilities, enabling
developers to get started swiftly, and iterating on ideas, Python excels. The
official
[Google GenAI SDK is indeed available for Python, alongside JavaScript/TypeScript, Go, and Java](https://cloud.google.com/vertex-ai/generative-ai/docs/sdks/overview).
The Python GenAI SDK provides an interface to integrate Google's generative
models into Python applications, supporting both the Gemini Developer API and
Vertex AI APIs.
While Python is a
[widely-used, high-level programming language known for its simplicity and readability](https://survey.stackoverflow.co/2025/technology),
it's crucial to understand the nuance: these Python examples are provided for
ease of use and quick experimentation, ***not as an exclusive recommendation
for all production environments***. Google Cloud itself supports a variety of
popular languages, each suited for different development needs.
Lastly, about the absence of official GenAI SDKs for languages like Rust or C#
is often a matter of *demand and ecosystem focus*, though Google Cloud
generally supports a broad range of languages for various services. In fact,
[Google Cloud Service Extension](https://github.com/GoogleCloudPlatform/service-extensions)
uses a very interesting mix of GO, Java, Python and Web Assembly.
## **Beyond Python: A Polyglot Approach to Cloud Development**
Google Cloud's philosophy embraces a polyglot environment, recognizing that no
single language fits every use case. While Python shines in data science,
scripting, and rapid development, other languages are vital:
- **Go:** Developed by Google, Go is a natural fit for GCP, known for
performance, simplicity, and efficiency in cloud computing, distributed
systems, and microservices.
- **Java:** A robust, object-oriented language, Java is a powerhouse for
enterprise applications, offering strong performance and security features,
integrating seamlessly with GCP services.
- **Node.js (JavaScript):** Excellent for web applications, real-time
applications, and API services, Node.js allows JavaScript to run on the
server side efficiently.
[Google's Gemini Code Assist](https://cloud.google.com/gemini/docs/codeassist/supported-languages#coding-languages)
even supports a wide array of programming languages for AI-assisted
development, including Python, Java, JavaScript, C++, Go, and Rust,
highlighting Google's commitment to diverse developer ecosystems.
## **Choosing Your Cloud Language: A Strategic Decision**
Ultimately, the "best" programming language for Google Cloud – or for any\*
cloud platform – depends on *your specific use case, project requirements,
performance needs, and team expertise*. Python's ease of use, extensive
libraries, and strong community make it an excellent choice for (initial)
development, data-intensive tasks, and rapid prototyping, especially within the
Generative AI space. However, for highly performant, scalable, or
enterprise-grade applications, Go, Java, or Node.js could be more suitable.
Google Cloud provides the tools and flexibility to choose the language that
best empowers your team to build innovative solutions. So, while Python
examples for Gemini are abundant and incredibly useful for getting started,
remember to select the language that truly aligns with your project's long-term
goals.
---
## Advanced Memory Management for Agentic AI Development
Source: https://msampathkumar.github.io/writing/technical/memory-management-agentic-ai/
# Advanced Memory Management for Agentic AI Development
*Transforming stateless LLMs into intelligent agents with proper memory architecture.*
One of the biggest hurdles I've faced while building AI assistants is their inherent amnesia. Large Language Models are stateless by default—every conversation starts from zero. It's frustrating to watch an agent you've worked hard to configure immediately forget a user's preferences the moment the API call ends.
To build truly intelligent, stateful agents that can handle long-term interactions, I've had to dive deep into **Context Engineering**—the art of dynamically assembling and managing the information an LLM needs to reason and act.
The challenge I quickly ran into is that while past data is essential for intelligence, managing it effectively is a massive hurdle.
## The Data Explosion Problem
In agentic applications, every message, tool call, tool output, and intermediate
thought is an "Event" appended to the active conversation log, or **Session**.
This history rapidly spirals out of control, introducing four major challenges:
- **Context Window Limits**: The conversation transcript can exceed the maximum
token count the LLM can process, causing the API call to fail.
- **Cost and Latency**: Most LLM providers charge by tokens sent and received.
Larger contexts increase costs and latency, resulting in a slower response
time for the user.
- **Noise and Context Rot**: As the context grows, its quality diminishes. The
LLM's ability to focus on critical information suffers from **context rot** as
conversational filler and irrelevant details flood the prompt.
- **Reliability Issues**: As context approaches limits, agents become unpredictable—
sometimes forgetting critical instructions or failing to complete tasks as the
relevant information gets pushed out of the window.
Consider a simple conversation that quickly explodes:
```
User: "What's the weather today?"
Agent: [Tool call: weather_api] → 500 tokens
Agent: "It's 72°F and sunny..."
User: "Should I bring an umbrella?"
Agent: [Tool call: forecast_api] → 400 tokens
Agent: "No rain expected..."
User: "What about tomorrow?"
Agent: [Tool call: extended_forecast] → 600 tokens
...
# After 20 interactions: 15,000+ tokens of history!
```
## Challenge 2: The Master Data Management (MDM) Challenge for Agents
To create a continuous, personalized experience, I've found that an agent needs to transform the transient chaos of a single Session into a highly organized "filing cabinet" of persistent knowledge.
This feels a lot like the enterprise concept of **Master Data Management (MDM)**—essentially, maintaining a single, accurate source of truth for user-specific knowledge.
For this long-term knowledge (or **Memory**) to be useful, it has to be carefully curated. Without a curation process, simple extraction just leads to a noisy, contradictory log. I focus on four key areas of consolidation:
- **Conflict Resolution**: Handling cases where a user's preferences change over time.
- **Deduplication**: Merging similar facts mentioned in different ways.
- **Information Evolution**: Updating simple facts as they become more nuanced.
- **Forgetting**: Pruning old, stale, or low-confidence memories to keep things relevant.
## My Approach: Leveraging Google ADK and Vertex AI
Managing this effectively usually requires two complementary strategies: one for short-term (in-session) memory, and one for long-term (cross-session) memory.
### 1. Short-Term Memory via ADK Content Compaction
For managing the immediate Session history and fitting it within the LLM's
context window, the **Google Agent Development Kit (ADK)** offers compaction
techniques. These methods act as short-term MDM by trimming the verbose log
while preserving core context:
- **Token-Based Truncation**: Before sending the history, the agent includes
messages starting with the most recent and works backward until a token limit
(e.g., 4000 tokens) is reached, cutting off the rest.
- **Recursive Summarization**: Older messages are periodically replaced by an
AI-generated summary, which is then used as a condensed history. For instance,
ADK's EventsCompactionConfig can trigger this LLM-based summarization after a
configured number of turns.
**Example: Implementing ADK Compaction**
```python
import asyncio
from google.adk.runners import InMemoryRunner
from google.adk.agents.llm_agent import Agent
from google.adk.apps.app import App, EventsCompactionConfig
from google.adk.apps.llm_event_summarizer import LlmEventSummarizer
from google.adk.models import Gemini
root_agent = Agent(
model="gemini-2.5-flash-lite",
name="greeter_agent",
description="An agent that provides a friendly greeting.",
instruction="Be Humble, Respectable and keep your answers short and sweet.",
)
# Define the AI model to be used for summarization:
summarization_llm = Gemini(model="gemini-2.5-flash")
# Create the summarizer with the custom model:
my_summarizer = LlmEventSummarizer(llm=summarization_llm)
# Configure the App with the custom summarizer and compaction settings:
app = App(
name="root_agent",
root_agent=root_agent,
events_compaction_config=EventsCompactionConfig(
compaction_interval=3,
overlap_size=1,
summarizer=my_summarizer,
),
)
# Set a Runner using the imported application object
runner = InMemoryRunner(app=app)
async def main():
print("\n################################ START OF RUN")
print("Tip: Use `exit` or `quit` to exit the app.\n---")
user_query = input("User: ")
while user_query.strip() not in ["exit", "quit"]:
try:
await runner.run_debug(user_query)
except Exception as e:
print(f"An error occurred during agent execution: {e}")
user_query = input("User: ")
print("#---")
print("################################ END OF RUN\n")
if __name__ == "__main__":
asyncio.run(main())
```
### 2. Long-Term Memory with Vertex AI Memory Bank
For persistent, cross-session memory management, I rely on **Vertex AI Memory Bank** (also known as Agent Engine Memory Bank).
This managed service operates like an LLM-driven pipeline that automatically manages the lifecycle of long-term memory. It ensures the agent becomes an expert on the *user*, not just on static facts.
Vertex AI Memory Bank addresses the long-term challenges through:
- **Extraction and Consolidation**: It uses LLMs to intelligently extract
meaningful facts from the conversation history (Sessions) and performs the
critical **consolidation** step to resolve conflicts and deduplicate
information.
- **Asynchronous Generation**: Critically, memory generation and consolidation
run as an **asynchronous background process** after the agent has responded to
the user, ensuring zero latency on the "hot path" of user interaction.
- **Persistent Storage and Retrieval**: It durably stores these memories,
linking them to a specific user ID, and makes them available for intelligent,
similarity-search based retrieval in future sessions.
**Example: Integrating Vertex AI Memory Bank**
```python
print("🧠 Creating Memory Bank configuration for hotel concierge...\n")
basic_memory_config = MemoryBankConfig(
# Which embedding model to use for similarity search
similarity_search_config=SimilaritySearchConfig(
embedding_model=f"projects/{PROJECT_ID}/locations/{LOCATION}/publishers/google/models/text-embedding-005"
),
# Which LLM to use for extracting memories from conversations
generation_config=GenerationConfig(
model=f"projects/{PROJECT_ID}/locations/{LOCATION}/publishers/google/models/gemini-2.5-flash"
),
)
print("✅ Memory Bank configuration created!")
print("\n🛠️ Creating Agent Engine with Memory Bank...\n")
print("⏳ This provisions the backend infrastructure for guest memory storage...")
agent_engine = client.agent_engines.create(
config={"context_spec": {"memory_bank_config": basic_memory_config}}
)
agent_engine_name = agent_engine.api_resource.name
print("\n✅ Agent Engine created successfully!")
print(f" Resource Name: {agent_engine_name}")
print("💬 Creating a session for guest check-in...\n")
# Generate a unique guest identifier
guest_id = "guest_emma_" + str(uuid.uuid4())[:4]
# Create a session for this guest
session = client.agent_engines.sessions.create(
name=agent_engine_name,
user_id=guest_id,
config={"display_name": f"Check-in conversation for {guest_id}"},
)
session_name = session.response.name
print("✅ Session created successfully!")
```
**Complete code:** [Link](https://github.com/GoogleCloudPlatform/generative-ai/blob/main/agents/agent_engine/memory_bank/get_started_with_memory_bank.ipynb)
Integrating ADK's short-term compaction with the managed capabilities of Vertex AI Memory Bank has allowed me to confidently build agents that truly remember and adapt, without facing the inevitable data explosion challenges.
## Final Thoughts
Memory management isn't just a technical optimization—it's the foundation that transforms LLMs from impressive demos into useful applications. In my experience, without a proper memory architecture, agents remain trapped in a cycle of forgetting and re-learning, which is frustrating for users and expensive to run.
Adopting a two-tiered approach—using ADK for session compaction and Vertex AI for long-term persistence—has been a game-changer for my projects. It provides the balance needed between immediate context availability and long-term knowledge retention.
If you're building agentic applications, I highly recommend thinking about your memory strategy early on. Your users—and your token budget—will definitely notice the difference.
For those interested in exploring the tools I've mentioned, the [ADK documentation](https://google.github.io/adk-docs/) is a great place to start.
References:
- [Vertex AI Agent Engine Memory Bank overview][2]{:.external}
- [Sessions Overview - Agent Development Kit][3]{:.external}
- [Session Context compression - Agent Development Kit][4]{:.external}
- [Memory - Agent Development Kit][5]{:.external}
[1]: https://en.wikipedia.org/wiki/Master_data_management
[2]: https://docs.cloud.google.com/agent-builder/agent-engine/memory-bank/overview
[3]: https://google.github.io/adk-docs/sessions/session/
[4]: https://google.github.io/adk-docs/context/compaction/
[5]: https://google.github.io/adk-docs/sessions/memory/#choosing-the-right-memory-service
---
## Vibe Coding — Introduction
Source: https://msampathkumar.github.io/writing/technical/vibe-coding-intro/
## Vibe Code? The What, Why, and How (And When I Hit the Brakes)
What is Vibe Coding? To me, it's about using AI to generate code from a
high-level intent or "vibe." I think of it less like a co-pilot and more like
an automated sidekick. I describe what I want, the AI generates the code, and I
run it. The focus shifts from syntax to the desired outcome—a workflow of
describe-generate-run-refine.
This is a stark contrast to how I approach responsible, production-ready
development, where I remain firmly in the driver's seat, meticulously reviewing
every line. Vibe coding is fast and fluid, often done when I need a quick
result or a throwaway script.
## When I Ride the Vibe 🏄
Vibe coding has become a superpower for specific tasks in my workflow.
- **Rapid Prototyping**: When I have a weekend idea for a simple web app or a
data script, I vibe code it. I can spin up a proof-of-concept in hours rather
than days.
- **Automating Repetitive Tasks**: If I need a quick Python script to rename
files or parse logs, a simple prompt saves me the boilerplate.
- **Learning New Libraries**: Want to see how a new library works? Asking an AI
to generate a simple example is like having personalized, instant
documentation.
## When I Hit the Brakes 🛑
Just as I wouldn't take a sports car on a family road trip, I've learned where
vibe coding has its limits.
- **Critical Systems**: I never vibe code mission-critical or
security-sensitive logic. The risk of unknown flaws and the eventual cost of
debugging far outweigh the initial speed.
- **Long-term Projects**: If I know a project needs to be maintained for
months, a vibe-coded mess quickly becomes a nightmare. It accumulates
technical debt that cripples scalability.
- **Code Quality**: Vibe-coded solutions often lack documentation and robust
error handling. It's easy to fall into an "entropy loop" where every fix
introduces two new problems.
## My Personal Vibe-Coding Guardrails
The true danger isn't the AI—it's over-relying on it. Here are the pitfalls I
actively guard against in my own workflow:
1. **The Security Trap 🔒** *The Mistake*: Blindly accepting AI-generated code.
I've seen assistants naively use `eval()` on user input or hardcode API
keys. *My Fix*: I maintain a strict "human in the loop" mindset. I always
review AI code for common security flaws and ensure secrets are handled
properly via environment variables.
1. **The Technical Debt Vortex 🌪️** *The Mistake*: Treating a prototype as a
production-ready solution. It works, but it's a tangled mess. *My Fix*: I
refactor aggressively. If a vibe-coded prototype proves useful, I treat it
as pseudo-code and rewrite it with proper modular structure and tests.
1. **The Skills Erosion 🧠** *The Mistake*: Using AI as a crutch to the point of
forgetting the fundamentals. *My Fix*: I use AI to explore, not just to
execute. I always ask the AI *why* it made a certain choice so I continue
learning.
---
## Vibe Coding — Dos and Don'ts
Source: https://msampathkumar.github.io/writing/technical/vibe-coding-dos-donts/
## DO's and DOnt's with Vibe Coding
Summary notes of
https://www.infoworld.com/article/4029093/9-habits-of-the-highly-ineffective-vibe-coder.html
## The Do's
- Do experiment with different models. Different LLMs have varying strengths
and weaknesses, and you might need to try a few to find the right one for
your specific coding problem.
- Do treat the AI as a search tool. LLMs excel at finding and recalling
information from their vast training data, such as obscure documentation or
code snippets.
- Do use the AI for simple, repetitive tasks. The article suggests AI can be
helpful for basic programming chores.
## The Don'ts
- Don't trust the LLM completely. The article warns that LLMs can provide
incorrect information and even "hallucinate" non-existent code or URLs.
- Don't treat the LLM like a "dumpster." Avoid dumping large blocks of code on
the AI, as this can be inefficient, costly, and even confuse the model.
- Don't assume all models are the same. Each LLM has a unique internal
structure, parameter count, and training data, which can significantly affect
its performance.
- Don't ignore the costs. AI tools charge by the token, and repetitive requests
or large inputs can lead to surprisingly high costs.
- Don't hand over full control. The article highlights the risk of trusting an
LLM with critical tasks, as their inherent randomness can lead to
unpredictable and destructive outcomes.
- Don't expect the AI to "think" like a human. LLMs are clever mimics and
excellent at information retrieval, but they are not always good at deep
synthesis or providing novel insights.
- Don't create inconsistent code. The randomness in LLM output can lead to a
"patchwork quilt" of different coding styles, making the codebase messy and
hard to maintain.
---
## Writing — Reflections
## 10 Principles of Miyamoto Musashi
Source: https://msampathkumar.github.io/writing/personal/miyamoto-musashi/
# 10 principles of Miyamoto Musashi
## About Miyamoto Musashi
Miyamoto Musashi, a legendary figure in the annals of Japanese history, stands
as a symbol of unparalleled mastery in the way of the sword. Renowned not only
for his exceptional martial skills but also for his profound philosophical
insights, Musashi is a name that resonates through the ages. Born in the late
16th century, during a tumultuous period of Japan’s history, Musashi’s life was
marked by a relentless pursuit of perfection in the art of swordsmanship. His
remarkable journey led him to become the author of the timeless classic, “The
Book of Five Rings,” which continues to inspire warriors and thinkers alike,
transcending both time and culture. This introductory glimpse into the life and
legacy of Miyamoto Musashi only scratches the surface of his remarkable story,
a tale of discipline, relentless ambition, and the quest for martial and
spiritual enlightenment.
## The 10 Principles
1. Accept everything just the way it is.
1. Do not seek pleasure for its own sake.
1. Do not under any circumstances, depend on a partial feeling.
1. Think lightly of yourself and deeply of the world.
1. Be detached from desire your whole life long.
1. Do not regret what you have done.
1. Never be jealous.
1. Never let yourself be surrounded by a separation.
1. Resentment and complaint are appropriate neither for oneself nor others.
1. Do not let yourself be guided by the feeling of lust or love.
Source:
[Link](https://medium.com/@zakinabdul.jzl/10-principles-of-miyamoto-musashi-2a8394e59b10)
---
## Sky, Sea, and Truth
Source: https://msampathkumar.github.io/writing/personal/sky-sea-truth/
# Sky, Sea and Truth
A vast blue canvas, Sea and sky, a mirror's gleam, Moments, swiftly pass.
Life's a rushing stream, We stand still, in silent thought, Seeds grow, futures
bloom.
Birth and death entwined, Happiness, a passing shade, Truth, a fleeting breath.
Sea and sky reflect, Constant change, yet ever the same, The now, the only
truth.
---
## How to Spot an Ineffective Manager or Leader
Source: https://msampathkumar.github.io/writing/personal/spot-fake-leaders/
# How to Spot an Ineffective Manager or Leader
Identifying poor leadership is a critical skill for career growth and mental well-being. In many corporate environments, a person's position or title can mask their true leadership capabilities. Ineffective leaders often exploit communication gaps and their perceived authority, creating a toxic environment for their team.
Here are three common warning signs.
## 1. They Stifle Autonomy and Micromanage
A classic sign of a bad leader is the tendency to **suffocate their team's freedom and autonomy**. They take broad, collaborative goals and twist them into high-pressure, individual tasks.
For example, a company-wide directive like "we need to improve application performance" becomes a direct, isolating order to a single developer: "Your application's performance is not satisfactory. Fix it." What should be a team effort becomes a solitary burden, setting the individual up for failure and burnout.
## 2. They Withhold Recognition
Ineffective leaders are often the **last to acknowledge your hard work** and the first to take credit for it. While your peers might celebrate your achievements, a bad manager will either ignore them or offer empty praise that feels disingenuous, often followed by piling on more responsibilities.
These managers are deeply concerned with their own reputation. They enjoy the benefits of your team's successes to bolster their own image, but **they don't genuinely care about or understand the work you do**. This behavior leads to a feeling of being overworked, underappreciated, and **overlooked for growth opportunities**.
## 3. They Lack Accountability and Offer Fake Support
Trust is the foundation of any healthy team. Bad leaders erode this trust with a pattern of dishonesty and avoidance. They are **quick to make promises they can't or won't keep**.
They might demand you work weekends to fix a critical issue but will not invest their own time to understand the technology or the root cause of the problem. **They are not problem-solvers; they are masters of evasion**. This lack of genuine support breaks your confidence in their leadership and leaves you feeling isolated.
# What Should You Do?
If these signs resonate with your experience, it's essential to take action to protect your career and well-being.
## 1. Prioritize Your Well-being: Consider Your Options
If you feel consistently undermined and unsupported, the **best long-term solution may be to find a new role**. Ineffective managers are often skilled at applying pressure and may even resort to bad-mouthing team members when things go wrong.
**Leaving a toxic environment is not a sign of failure.** While the thought of changing jobs can be daunting, your mental health and financial future are better served in a supportive workplace. Many people suffer severe burnout and trauma from a lack of support at work. Not everyone has the luxury to quit immediately, but it's crucial to start thinking about a way out.
## 2. Plan a Strategic Exit
Because these managers often lack deep technical expertise, they tend to focus on project-level timelines and deliverables, expecting you to handle all the details. They often lay out work in two- to three-month cycles. Use this time to your advantage. Plan your exit, update your resume, and start networking.
## 3. Document Everything
Keep a clear record of your accomplishments, tasks, and any relevant interactions. Use email to confirm conversations and decisions. This documentation is not just for performance reviews; it's a way to protect yourself and maintain a clear, factual account of your contributions.
Lastly, don't forget to remember that you're in control of your career path. Don't let the one bad environment dictate your future.
## 4. Stay Positive
Remember, this is not an end; it's a new beginning. You have the power to shape your own destiny and create a better work environment for yourself and others.
---
## The Two Lenses of Leadership
Source: https://msampathkumar.github.io/writing/personal/two-lenses-of-leadership/
# The Two Lenses of Leadership: Operational Fixes vs. Strategic Bets
We all want to be "data-driven." It’s the mantra of modern business. Yet, one of the most thrilling moments in my professional journey wasn't just about discovering data; it was the profound realization that the same exact metrics can narrate two entirely different stories, simply by changing the lens through which you view them.
### The Bakery Analogy: A Tale of Two Lenses
Consider a hypothetical scenario to illustrate this dichotomy.
Imagine you own a bustling downtown bakery. You analyze your sales data and find a clear, undeniable trend: 80% of your customers want your signature sourdough piping hot at exactly 8:00 AM.
This demand creates chaos. The kitchen is overwhelmed, delivery drivers are stressed, and if anything goes wrong at 7:55 AM, customer satisfaction plummets.
### Lens 1: The Operational Fix
If you wear an **Operational Efficiency lens**, you look at that data and see a bottleneck. The logical conclusion is to smooth out the demand curve. Your thought process might lead to: *"Let's offer a free cookie to anyone picking up their sourdough after 10:00 AM."* The aim is to alleviate operational stress by subtly shifting customer behavior—a smart, efficient, and cost-effective solution.
### Lens 2: The Strategic Bet
But if you wear a **Strategic Growth lens**, you look at that same data and see massive, untapped desire. You don't see a bottleneck; you see your biggest competitive advantage. Your conclusion isn't to shift demand; it's to meet it. Instead, your rallying cry might be: *"Forget the cookies! Let's invest in a second oven and more morning staff to double our 8:00 AM sourdough sales."*
Thus, one perspective seeks to save by optimizing the existing framework, while the other aims to generate by aggressively scaling what truly resonates with customers.
### The Real-World Realization
I share this story because I recently went through my own version of the "8:00 AM sourdough rush" on a project.
We had clear data showing that a specific service protocol was overwhelmingly driving our success, but it was operationally taxing to execute. My immediate instinct—my operational lens—was to find ways to incentivize customers toward an easier alternative to relieve the pressure on our team.
Fortunately, a senior leader challenged me with the strategic lens. They argued that if this difficult protocol was the key to delighting our users, we shouldn't try to minimize it—we should figure out how to scale it aggressively.
### The Takeaway
This marked a thrilling moment of perspective shift. While neither approach was inherently 'wrong,' it unveiled an invaluable lesson:
> Sometimes the path forward isn't merely to alleviate an operational pinch point by redirecting demand. Sometimes, the path forward is to lean into the difficulty, because it could be where the magic 🌟 happens.
---
## Speaking
## All Speaking Engagements
Source: https://msampathkumar.github.io/events/
# Events
## Professional Speaking Engagements and Technical Leadership
As a Sr. Developer Programs Engineer at Google Cloud, I have actively contributed to major AI and cloud computing events across Europe. These engagements demonstrate my expertise in AI agent development, memory management, and the Google Agent Development Kit (ADK).
## 2026
### 2026-03-11: Google I/O Connect Berlin
**Role**: Presenter
At Google I/O Connect Berlin I presented on Building Agents with Gemini, Google ADK and A2A (Agent-to-Agent) Communication.
In the first part of my demo, I have demonstrated how A2A's new multitenancy feature allows one to scale AI agent applications effortlessly while minimzing the infrastructure and operational code needed to do so.
In the second part of my demo, I have presented a demo on ARDS - Agentic Resource Discovery Service which allows developers to easily discover and utilize services to get their tasks done.
### 2026-03-11: GDG Cloud Fest PL
**Role**: Presenter
At the GDG Cloud Fest PL conference in Warsaw, Poland, I presented a talk on building intelligent agents using Google ADK. I also presented 5 key science-backed takeaways for Agent Architectures.
### 2026-02-17: Accelerate AI with Cloud Run Warsaw
**Role**: Event Support (Facilitator/TA)
I supported this event as part of the Facilitators/TA team to help attendees with the hands-on labs. Remigiusz Samborski was the event lead and delivered the introduction and presentations. I also participated in the "Know Before You Go" (KBYG) preparation session on February 5, 2026.
## 2025
### [2025-11-10 to 2025-11-14: Kaggle AI Days - 5-Day AI Agents Intensive Course](2025-11-10-kaggle-ai-days.md)
**Role**: Course Codelabs Lead for Day 3: Context Engineering & Memory
I served as the technical lead for Day 3 of Google's flagship AI Agents Intensive Course, which attracted over 1.5M participants globally. My responsibilities included:
- Review the course codelabs content on context engineering and memory management for AI agents
- Creating two comprehensive Colab notebooks demonstrating short-term and long-term memory implementations
### [2025-11-05: Google Cloud AI Day - Sweden](2025-11-05-ai-day-sweden.md)
**Location**: Münchenbryggeriet, Stockholm
**Role**: Technical Speaker - Developer Track
I delivered 2 technical sessions at Google Cloud AI Day Sweden, engaging with 200+ developers and IT leaders:
- **Session 1**: Building Intelligent Agents: Gemini, Google ADK, and Memory Management
- **Session 2**: Five Key Takeaways to Enhance Your Gemini Apps
- **Impact**: Successfully demonstrated practical implementations of AI agents using Google ADK
### [2025-10-28: Google Cloud AI Day - Denmark](2025-10-28-ai-day-denmark.md)
**Location**: Copenhagen
**Role**: Technical Speaker - Developer Track
I presented a technical session on "Building Intelligent Agents: Gemini, Google ADK, and Memory Management" as part of the developer track, contributing to Google Cloud's Nordic AI initiative.
### [2025-04-09: Google Cloud Next '25](2025-04-09-cloud-next.md)
**Location**: Las Vegas, U.S.
**Role(s)**: Go-To-Market DevRel Lead for GenAI SDKs(Python & Go), Presenter of Advanced Development Tools in Vertex AI Demo and one of the speaker for Agent Starter Pack (ASP) at Google Cloud Next 2025.
### 2025-03-04: Google /dev/cloud day Warsaw
**Role**: Workshop Co-Lead
I participated as a workshop co-lead, running the "Gemini Workshop: Multimodality and Long Context" alongside Laurent Picard. Remigiusz Samborski was heavily involved, delivering the Welcome, Keynote, and a presentation on Gemini 2.0 for developers.
## 2024
### 2024-11-06: Google Cloud Summit Poland 2024
**Role**: Speaker & Demo Booth Lead
I participated as a speaker presenting "Inside Google Cloud: How GenAI is Transforming our Docs & Code Samples". I also successfully ran the "Load Balancing Blitz" (LB Blitz) game demo booth for attendees. Remigiusz was a co-speaker with me for the presentation and collaborated on the LB Blitz booth.
## Older Events
* 2024-03-14: Duet AI for Developers Roadshow Warsaw - Event Support (Facilitator)
* 2023-10-26: Google Cloud Summit Poland 2023 - Google Cloud Experts Booths (Facilitator)
---
## Kaggle AI Days — 5-Day AI Agents Intensive Course (2025-11-10)
Source: https://msampathkumar.github.io/events/2025-11-10-kaggle-ai-days/
# Kaggle AI Days 2025: 5-Day AI Agents Intensive Course
**Event Dates**: November 10-14, 2025
**Format**: Online, Global
**Official Website**: https://rsvp.withgoogle.com/events/google-ai-agents-intensive_2025
**Kaggle Learn Guide**: https://www.kaggle.com/learn-guide/5-day-agents
## My Role and Contribution
### Technical Leadership
- **Position**: Course Lead for Day 3: Context Engineering & Memory
- **Name**: (Sampath Kumar](https://www.kaggle.com/maddula)
- **Title**: Developer Programs Engineer, Google Cloud
- **Responsibility**: Led the curriculum development and implementation for context management in AI agents
### Deliverables Created
1. **Colab Notebook 1**: Short-term Memory Implementation
- Demonstrated session management techniques
- Practical examples using Google ADK SessionManagers
- https://www.kaggle.com/code/kaggle5daysofai/day-5b-agent-deployment
2. **Colab Notebook 2**: Long-term Memory Implementation
- Showcased persistent memory patterns
- Integration with vector databases
- Production-ready memory architectures
- https://www.kaggle.com/code/kaggle5daysofai/day-5a-agent2agent-communication
## Course Overview
This flagship Google AI course attracted over [420,000 registrations](https://rsvp.withgoogle.com/events/google-ai-agents-intensive_2025) globally, following the success of the previous year's [Gen AI Intensive Course](https://blog.google/innovation-and-ai/technology/developers-tools/ai-agents-intensive-recap/). The course focused on building autonomous AI agents that go beyond simple chatbots.
### 5-Day Curriculum Structure
1. **Day 1**: Introduction to Agents & Agentic Architectures
2. **Day 2**: Agent Tools & Interoperability with MCP
3. **Day 3**: Context Engineering & Memory (My Leadership Area)
4. **Day 4**: Quality, Logging & Evaluation
5. **Day 5**: Prototype to Production
### Day 3 Focus: Context Engineering & Memory
As the Day 3 lead, I covered:
- **Short-term Memory**: Conversation context and session management
- **Long-term Memory**: Persistent knowledge and learning mechanisms
- **Memory Architecture Patterns**: Best practices for production systems
- **Google ADK Integration**: Practical implementation using ADK's memory components
## Impact and Reach
- **Community Engagement**: Active participation in Discord discussions
- **Capstone Projects**: Participants used Day 3 concepts in their final projects
## Technical Stack
- **Primary Framework**: Google Agent Development Kit (ADK)
- **Language**: Python
- **Tools**: Colab notebooks, Gemini API, Vector databases
- **Platforms**: Kaggle, YouTube (live sessions), Discord (community)
## Key Takeaways for Participants
Through my Day 3 curriculum, participants learned:
1. How to implement stateful AI agents using memory systems
2. Best practices for context management in production
3. Practical patterns for short-term and long-term memory
4. Integration techniques with Google ADK
This course represents Google's commitment to democratizing AI agent development, and I'm proud to have contributed to educating the next generation of AI developers.
---
## AI Day Sweden (2025-11-05)
Source: https://msampathkumar.github.io/events/2025-11-05-ai-day-sweden/
# Google Cloud AI Day Sweden 2025
**Event Date**: November 5, 2025
**Location**: Münchenbryggeriet, Stockholm
**Event Website**: https://cloudonair.withgoogle.com/events/google-cloud-ai-day-sweden-2025
## My Contribution
### Speaker Profile
- **Name**: Sampath Kumar
- **Title**: Developer Programs Engineer, Google Cloud
- **Track**: Developer Track (10:45 AM CET)
- **Sessions Delivered**: 2 technical presentations
### Session Details
**Session 1**: Building Intelligent Agents: Gemini, Google ADK, and Memory Management
**Session 2**: Five Key Takeaways to Enhance Your Gemini Apps
**Format**: Extended Q&A and interactive discussions with post-session networking
**Key Technical Topics Presented**:
- Memory Management fundamentals for AI Agents
- Google ADK SessionManagers for short-term memory management
- MemoryManagement implementations for long-term memory persistence
- Context engineering best practices for Gemini models
- Data privacy considerations in agent memory systems
**Audience Engagement**:
- Successfully engaged with 200+ developers and technical leaders
- Utilized the mnemonic "SAM → Session and Memory" to reinforce key concepts
- Extended Q&A sessions based on high audience interest.
## Technical Insights Shared
### Memory Architecture in Google ADK
- **Short-term Memory**: Demonstrated SessionManagers for maintaining conversational context
- **Long-term Memory**: Showcased persistent memory implementations for complex agent behaviors
- **Context Optimization**: Explained strategies for maximizing Gemini's context window efficiency
### Best Practices Emphasized
1. Proper context management for improved agent performance
2. Data privacy and security in memory systems
3. Leveraging ADK base classes for custom implementations
4. Production-ready patterns for agent deployment
## Event Context
Google Cloud AI Day Sweden featured:
- Dual tracks: Developer Track (08:00-19:30) and IT & Business Leader Track (12:30-19:30)
- 15 sessions with hands-on labs and live demonstrations
- Focus on the "agentic era" and practical AI implementations
- Part of Google Cloud's Nordic AI initiative
## Professional Impact
This speaking engagement resulted in:
- Deep technical discussions with Nordic developer community
- Valuable feedback incorporated into Google ADK documentation.
## Open Source Contribution
Emphasized Google ADK's open-source nature and encouraged community contributions, highlighting:
- Extensibility of ADK base classes
- Community-driven development opportunities
- Real-world implementation patterns
## Related Materials
- https://github.com/msampathkumar/google-adk-sam
---
## AI Day Denmark (2025-10-28)
Source: https://msampathkumar.github.io/events/2025-10-28-ai-day-denmark/
# Google Cloud AI Day Denmark 2025
**Event Date**: October 28, 2025
**Location**: Copenhagen, Denmark
**Event Website**: https://cloudonair.withgoogle.com/events/google-cloud-ai-day-denmark-2025
## My Contribution
### Speaker Profile
- **Name**: Sampath Kumar
- **Title**: Developer Programs Engineer, Google Cloud
- **Track**: Developer Track
- **Session Time**: 4:00 PM CET
### Session Details
**Title**: Building Intelligent Agents: Gemini, Google ADK, and Memory Management
**Abstract**: In this session, I provided developers with a comprehensive understanding of how to leverage Google Gemini models with the Agent Development Kit (ADK) to build intelligent agents. The session focused particularly on implementing and managing agent memory for more sophisticated and persistent interactions.
**Key Topics Covered**:
- Transforming stateless LLMs into stateful, intelligent agents
- Session and Memory (SAM) management in Google ADK
- Practical implementation patterns for agent memory
- Best practices for production-ready AI agents
**Audience Impact**:
- 150+ working professionals attendees the session.
- Engaged with developers through hands-on demonstrations and Q&A
## Event Context
Google Cloud AI Day Denmark 2025 was part of Google Cloud's Nordic AI initiative, featuring:
- 15+ sessions with demos and hands-on labs
- Parallel tracks for IT/Business Leaders and Developers
- Focus on the "agentic era" of AI and practical enterprise applications
The event emphasized how organizations can harness AI to revolutionize operations, with particular focus on autonomous AI agents that boost productivity and resilience.
## Professional Impact
This speaking engagement allowed me to:
- Share expertise in AI agent development with the Nordic developer community
- Demonstrate practical applications of Google's latest AI technologies
- Network with industry leaders and developers implementing AI solutions
## Related Events
This was the third event in Google Cloud's Nordic AI Days series:
- Helsinki (October 7)
- Oslo (October 14)
- **Copenhagen (October 28)** - My speaking engagement
- Stockholm (November 5) - Also featured as speaker
---
## Google Cloud Next '25 (2025-04-09)
Source: https://msampathkumar.github.io/events/2025-04-09-cloud-next/
# Google Cloud Next 2025 (April 9 to Apr 13)
## DevRel GTM TL: Gen AI SDK Launch (Python & Go)
DevRel Go To Market Lead for the [Google Gen AI SDK](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/sdks/overview) in Python. I was responsible for:
- Support the user onboarding for the SDK launch at Google Cloud Next 2025
- Providing [technical artifacts](https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/genai) that helped developers get started with the SDK.
## Cloud Next Demo Booth: Advanced Development Tools in Vertex AI Demo
I was a Technical Lead for the "Advanced Development Tools in Vertex AI Demo" at Google Cloud Next 2025.
- Presented the advanced development tools in Vertex AI to 250+ attendees.
- Developed a [demo app](https://advanced-development-tools-for-vertex-ai-gemini-387323590551.us-west1.run.app/knowledge_graphs) to shown advanced uses of Gemini Controlled Generations, Caching and other feature to build Knowledge Graphs on Books.
## Presenter:
I was one of the Presenter for [Google Agent Starter Pack](https://github.com/GoogleCloudPlatform/agent-starter-pack) (ASP).
-
---
## Optional
## Home
Source: https://msampathkumar.github.io/
# Sampath Kumar — AI & Cloud
Senior Developer Programs Engineer at Google Cloud. I write long-form guides and
cookbooks on AI agents, the Agent Development Kit (ADK), the Agent-to-Agent (A2A)
protocol, Gemini, and Google Cloud — for **agents first, and the humans who
build them**.
[Cookbook](google-cloud-gemini-cookbook/README.md){ .md-button }
[Writing](writing/technical/six-essential-protocols/index.md){ .md-button }
[About](about.md){ .md-button }
## Latest posts
---
---
## About
Source: https://msampathkumar.github.io/about/
# About
I'm **Sampath Kumar M**, a Senior Developer Programs Engineer at Google Cloud.
I work on AI agents — the
[Agent Development Kit (ADK)](https://google.github.io/adk-docs/) and the
[Agent-to-Agent (A2A) protocol](https://a2a-protocol.org/) — and write about
Gemini, Google Cloud, and the craft of building with AI.
This site is my digital garden: cookbooks with runnable code, long-form writing
on agent architectures and protocols, and a record of talks and events. It is
written **agents-first** — structured so that AI agents can read, learn from,
and act on the content — and useful to human readers too.
## What you'll find here
- **[Cookbook](google-cloud-gemini-cookbook/README.md)** — step-by-step,
runnable tutorials (the Gemini + Google Cloud series).
- **[Writing](writing/technical/six-essential-protocols/index.md)**
— essays and guides on agents, protocols, and developer practice.
- **Speaking** — talks, workshops, and events.
## For agents & LLMs
Machine-readable indexes of this site:
- [`/llms.txt`](llms.txt) — concise, link-first index.
- [`/llms-full.txt`](llms-full.txt) — full inlined content for deep ingestion.
## Elsewhere
- GitHub: [@msampathkumar](https://github.com/msampathkumar)
- LinkedIn: [msampathkumar](https://www.linkedin.com/in/msampathkumar/)
- Bluesky:
[@sampathm.bsky.social](https://bsky.app/profile/sampathm.bsky.social)
- PyPI: [sampath](https://pypi.org/user/sampath/)
---