DEV Community: HeetVekariya

What Is RAG and How to Implement It ?

HeetVekariya — Thu, 07 Aug 2025 16:54:46 +0000

I know it's a bit late to write about this, but knowledge never becomes irrelevant. I haven't explored the topic of Generative AI (GenAI) yet, so I'm starting today with a series of blogs covering various exciting and practical topics with hands-on implementations.

Before we dive in, try this: go to ChatGPT or any other large language model (LLM) and ask, "What is the name of my father?" You'll likely get a response like, "I don't know until you provide more details." This is an improved response from LLMs. In the past, when queries lacked context not present in the LLM's training data, they might have given a random name based on that data.

This highlights a key challenge that LLM providers faced, and the best solution they found is called Retrieval-Augmented Generation (RAG). Let's explore what it is and how it works.

What Is RAG ?

Retrieval-Augmented Generation (RAG) is a technique that provides an LLM with additional factual information beyond its training data, enabling it to answer user queries more effectively using this new information.

In the example above, when you asked the LLM for your father's name, it lacked the necessary information and responded by asking for more details. If we had included personal details in the query, the LLM could have answered accurately. Providing this additional context is, in essence, what RAG does.

"The term RAG was coined by Patrick Lewis in the 2020 paper, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks."

Why do we need RAG ?

Like any system driven by demand and supply, LLMs like ChatGPT initially had limitations in their knowledge, which restricted their ability to provide personalized answers. While improvements have been made over time, they still struggled to meet certain user expectations.

Here are the main problems LLMs faced before RAG:

Hallucination: Providing False information when the answer wasn't in the training data, Learn more about AI hallucinations.
Generic responses: Giving broad answers when users expected personalized ones.
Non-existent references: Citing resources or links that don't exist (e.g., leading to a 404 error).
Terminology confusion: Generating incorrect responses because different training sources used the same terms for different concepts.

You might have experienced an LLM providing a reference link that doesn't exist, resulting in a 404 error.

But is there only one type of RAG? No, there are several types, each with unique approaches to retrieving data and generating answers.

Types of RAG

RAG can be categorized based on how data is retrieved and answers are generated. Here are the three main types:

1) Naive / Native RAG

Description: Naive RAG is the simplest form of retrieval-augmented generation. It retrieves information and generates responses without optimizations or feedback loops.
Process:
- Convert the user query into a vector.
- Perform a similarity check to select the top N relevant results.
- Pass the query and retrieved context to the LLM for response generation.

2) Advanced RAG

Description: Advanced RAG uses sophisticated algorithms, including rerankers, fine-tuned LLMs, and feedback loops, to improve retrieval and generation.
Process:
- Convert the query into a vector.
- Retrieve documents using both vector search (semantic) and keyword-based search.
- Re-rank retrieved documents for relevance.
- Fuse documents (as they may be encoded differently).
- Generate a response.
- Use feedback loops (active learning, reinforcement learning, or retriever-generator co-training) to enhance performance over time.

3) Modular RAG

Description: Modular RAG is the most advanced variant, operating as an open, composable pipeline where retrieval and generation work seamlessly.
Process:
- Rephrase the query to remove ambiguity.
- Retrieve documents from a vector database or knowledge base using similarity search.
- Filter and re-rank documents to prioritize the most relevant ones.
- Feed the retrieved information to the LLM for response generation.
- Post-process the response to add citations for credibility.
- Create a feedback loop to refine retrieval for future interactions.

Steps in RAG

Here are the key steps involved in implementing RAG:

1. Data Collection

Gather all relevant data for your application, such as emails, sales data, company policies, websites, blogs, FAQs, databases, or user manuals.

2. Data Chunking

Break data into smaller, manageable parts (e.g., by page, topic, or paragraph). This ensures related information stays together, making it easier to locate based on user queries.

3. Document Embedding

Convert data into vector embeddings (numerical representations) where semantically related data is grouped closely together, and unrelated data is farther apart.

4. Handle user query

Transform the user query into a vector embedding using the same method as document embedding. Compare the query embedding with document embeddings to identify relevant chunks using techniques like cosine similarity or Euclidean distance.

5. Generate reponse

Feed the retrieved relevant data chunks and the user query to the LLM, which generates the final answer.

Use Cases of RAG

RAG has a wide range of applications, including:

Specialized chatbots and virtual assistants: Providing tailored responses based on specific data.
Internal data research: Quickly finding answers within organizational datasets.
Citations for credibility: Adding references to generated answers to improve trust.
Recommendation services: Suggesting relevant products, services, or content.

Implementing RAG

Now that we understand RAG, let's implement it to get hands-on experience. In this example, we'll use cat-related data to answer user queries about cats. You'll need a Gemini API Key for generating embeddings and accessing LLM functionality.

Here’s the implementation:

client = genai.Client(
    api_key=os.getenv("GOOGLE_API_KEY")    
)

data = []
with open("cat.txt", "r", encoding="utf-8") as f:
    data = f.readlines()

This code initializes the Gemini API client using an API key stored in an environment variable. It then reads data about cats from a file (cat.txt) into a list, where each line represents a chunk of information.

vector_database = []
def add_chunk_to_db(chunk):    
    embeddings = client.models.embed_content(
        model="gemini-embedding-001",
        contents=[chunk],
        config=types.EmbedContentConfig(task_type="SEMANTIC_SIMILARITY")
    ).embeddings[0].values
    vector_database.append(embeddings)
    print(f"Added chunk to database: {chunk.strip()}")

for chunk in data:
    add_chunk_to_db(chunk)

This code creates a vector database by converting each chunk of cat data into a vector embedding using the Gemini embedding-001 model. The embeddings are stored in vector_database, and a confirmation message is printed for each chunk added. The task_type="SEMANTIC_SIMILARITY" ensures the embeddings are optimized for document retrieval.

def retrieve(query, top_k=5):
    query_embedding = client.models.embed_content(
        model="gemini-embedding-001",
        contents=[query],
        config=types.EmbedContentConfig(task_type="SEMANTIC_SIMILARITY")
    ).embeddings[0].values

    similarities = cosine_similarity([query_embedding], vector_database)[0]
    top_indices = np.argsort(similarities)[-top_k:][::-1]
    return [(data[i], similarities[i]) for i in top_indices]

This function takes a user query and converts it into a vector embedding using the same Gemini model, with task_type="SEMANTIC_SIMILARITY" for query optimization. It calculates the cosine similarity between the query embedding and the vector database, selects the top k most similar chunks, and returns them along with their similarity scores.

query = [
    "What do cats eat?",
    "How long do cats sleep?",
    "What is the average lifespan of a cat?",
]

for q in query:
    results = retrieve(q)
    print(f"Query: {q}")
    print("Top results:")
    for text, similarity in results:
        print(f" - {text.strip()} (similarity: {similarity:.4f})")

    print("\n\n\n")
    # Without context
    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=f"Answer the question: {q}",
    )
    print(f"Response without context: {response.candidates[0].content.text.strip()}\n")

    # With context
    context = "\n".join([text.strip() for text, _ in results])
    response_with_context = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=f"Answer the question only using the provided context: {q}\n\nContext:\n{context}"
    )
    print(f"Response with context: {response_with_context.candidates[0].content.text.strip()}\n")
    print("="*50 + "\n")

This code processes a list of sample queries about cats. For each query:

It retrieves the top 5 relevant chunks from the vector database using the retrieve function.
It prints the query and the top results with their similarity scores.
It generates two responses using the Gemini gemini-1.5-flash model:
- One without context (just the query).
- One with the retrieved context included.
The responses are printed for comparison, showing how context improves accuracy. The contents parameter is formatted as a list of parts to match the Gemini API's expected input structure.

Conclusion

Retrieval-Augmented Generation (RAG) is a powerful technique that enhances LLMs by providing them with relevant external data, enabling more accurate and personalized responses. By addressing issues like hallucination, generic answers, and incorrect references, RAG makes LLMs more reliable and versatile. Its various types like Naive, Advanced, and Modular, offer flexibility for different use cases, from simple chatbots to complex research tools. The hands-on implementation above demonstrates how RAG works in practice, using cat data to answer queries with improved precision. As you explore RAG further, you can experiment with different datasets and fine-tune the process to suit your needs.

Credits

Cat Data: Xuan-Son Nguyen
Diagrams: IBM, Amazon
Resources: Google, Nvidia, Salesforce, Amazon, IBM, Datacamp
Code: Heet Vekariya

👉 If you found this helpful, don’t forget to share and follow for more agent-powered insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter | LinkedIn

What Is Vertex AI Agent Memory Bank ?

HeetVekariya — Wed, 30 Jul 2025 09:05:59 +0000

Since the emergence of the LLMs, we have travelled a lot in this journey. Initially, we addressed time-based data limitations through web search functionality, followed by improved reasoning with deep research capabilities.

Through these advancements, we discovered that context is critical for generating accurate responses. We first tackled this with prompt engineering, and more recently, context engineering, a new approach that emerged just days ago.

To address the same challenge, Google introduced the Vertex AI Agent Memory Bank, which manages memory recall, addition, and updates or deletion of past memories.

Let's understand what the Vertex AI Agent Memory Bank is and how it works.

What is Vertex AI Agent Memory Bank?

The Vertex AI Agent Memory Bank is a dynamic system for storing memories from conversations between a user and an AI agent. These memories serve as context for future interactions, allowing the agent to access past conversation data across different sessions to provide personalized responses.

You might wonder, why do we need a memory bank in the first place? The issue lies in how we provide context to LLMs.

Problems with Current Methods

Feeding entire conversations as context often leads to a context window overflow.
Large contexts increase inference costs and slow down performance.
As conversation data grows over time, it reduces LLM quality, causing issues like the lost in the middle and context rot problems.

Lost in the Middle Problem: LLMs struggle to process information present in the middle of long input sequences. They perform better when relevant details are at the start or end of the text, but accuracy drops for information in the middle.
Context Rot: LLM performance declines as the input context length increases.

How Does Vertex AI Agent Memory Bank Solve These Issues?

It stores personalized information from user-agent conversations.
It retrieves data from past conversations, regardless of the time elapsed.
It fetches only the necessary information from the memory bank, improving accuracy and updating data to maintain relevance, thus reducing incorrect responses.
It eliminates the need for users to repeatedly provide context in prompts.

How Does the Memory Bank Work?

The Memory Bank integrates with Vertex AI Agent Engine sessions to generate and manage memories. It relies on several key functionalities:

Session: Created using CreateSession, a session is a chronological sequence of messages between a user and an agent. Each session requires a user ID to map memories to specific users for personalized responses.
Events: These are interactions, such as user messages, agent responses, or tool actions, saved to the memory bank using AppendEvent. The agent retrieves these events with ListEvents to generate responses.
Memory Generation: Memories can be generated in two ways:
- GenerateMemories: Automatically extracts facts from conversations at specific intervals (e.g., end of a session or turn) for use in current or future sessions.
- CreateMemory: Used as a "memory-as-a-tool" approach, giving the agent more control over when to write memories. Memories can be retrieved using RetrieveMemories, either as a complete set (simple retrieval) or the most relevant ones (similarity search retrieval), depending on the need.

How to Implement Vertex AI Agent Memory Bank?

Currently, you can use the Memory Bank through two methods:

Memory Bank in Action

The image below illustrates how the AI Agent Memory Bank operates in real time.

Initially, a user mentions having oily skin and seeking a moisturizer. The memory bank stores this as "User has oily skin."
Days later, when the user asks for a cleanser recommendation, the agent retrieves the stored information about the user’s oily skin and suggests a suitable product.
Later, the user follows a routine that dries their skin, prompting the agent to update the memory bank.
When the user asks for recommendations again, the agent uses the updated "dry skin" information to provide a tailored suggestion.

This demonstrates how the memory bank efficiently supplies LLMs with relevant context, delivering personalized responses without requiring users to repeat context in every query or system prompt.

Conclusion

The Vertex AI Agent Memory Bank enhances user experience by enabling LLMs to access and utilize conversation history effectively. By addressing context-related challenges, it ensures faster, more accurate, and personalized responses, making interactions with AI agents more seamless and efficient.

Can You Contribute in YC backed Start Ups Through Open Source ?

HeetVekariya — Sun, 13 Jul 2025 15:31:54 +0000

I have been following YC-backed startups for the last couple of months. I try to find unique ways to reach out to founders and CEOs to understand how startups work at the ground level. In doing so, it often feels natural to contribute to the same ecosystem.

Nowadays, for every beginner in the tech field, it feels like a dream come true to work at a startup. We see X startup raised Y million dollars in Series Z round.

But what if I say you can contribute to these startups without associating with them directly? Yes, it’s true.

Recently, I came across some YC-backed startups that are open-sourced.

Open Source for Startups

Open-source software is the backbone of many modern tech innovations, and YC-backed startups are no exception. These companies share their code publicly, allowing anyone from beginners to seasoned developers to contribute ideas, fix bugs, or add new features. By participating, you’re not just coding; you’re helping shape the future of technologies like AI, automation, developer tools, and more.

Contributing to open-source YC startups offers unique benefits:

Learn from the Best: Work on projects backed by YC’s rigorous selection process, exposing you to high-quality code and real-world challenges.
Join a Community: Engage with developer communities on platforms like Slack, Discord, or GitHub, connecting with like-minded tech people and founders.
Make an Impact: Your code could power tools used by thousands, from AI assistants to database platforms.

Whether you’re fixing a small bug, improving documentation, or building a new feature, every contribution counts. Many of these startups actively welcome newcomers, providing clear guidelines and supportive communities to help you get started. It’s a chance to gain hands-on experience, learn cutting-edge technologies, and be part of the startup ecosystem.

List Of Open Source Start Ups

Note : I’ve mainly included the Summer 2025 batch, with two special mentions, one for mcp-use, and one from Spring 2025, Plexe. I will keep adding more details.

1) mcp-use (Summer 2025)*

MCP-use develops a platform to build and deploy Model Context Protocol (MCP) agents, enabling standardized function calling for AI tools to create context-aware applications.

Their product simplifies integrating AI models with external services, supporting automation across platforms like Slack, GitHub, and more. The open-source MCP framework allows developers to create interoperable AI agents with minimal setup.

2) Luminal (Summer 2025)

Luminal offers a simple machine learning framework and cloud platform for generating optimized GPU code, streamlining the development and deployment of high-performance ML models.

Their tools reduce the complexity of GPU programming, enabling faster model training and inference for AI applications. The platform supports developers in creating efficient, scalable ML pipelines.

3) Interfere (Summer 2025)

Interfere builds a self-healing layer for the internet, using AI to autonomously detect and resolve network issues like latency or downtime.

Their platform monitors network performance in real time, applying predictive algorithms to ensure reliability for businesses and users. It aims to create a more resilient internet infrastructure.

4) Stagewise (Summer 2025)

Stagewise develops a frontend coding agent that runs inside your browser on localhost, enabling real-time code generation and editing for web development.

The agent uses AI to suggest code, debug issues, and streamline workflows directly in the browser, making development faster and more intuitive. It supports frameworks like React and Vue.

5) Summon (Summer 2025)

Summon provides an open-source Postman-like tool for MCP servers, simplifying API testing and interaction for AI-driven applications.

Their platform enables developers to test MCP-based APIs with a user-friendly interface, supporting rapid debugging and integration. It’s designed for seamless workflows with AI agents.

6) Channel3 (Summer 2025)

Channel3 creates a comprehensive database of every product on the internet, enabling AI agents to access and utilize product data for e-commerce, analytics, and recommendation systems.

Their platform aggregates data from diverse sources, providing structured access for AI-driven applications. It supports real-time product updates and queries.

7) Embedder (Summer 2025)

Embedder develops a “Cursor for Embedded” platform, providing open-source tools for AI-driven embedded systems development.

Their product simplifies coding for hardware-specific applications, enabling developers to integrate AI models into microcontrollers and IoT devices. It supports low-latency, resource-constrained environments.

8) Magnitude (Summer 2025)

Magnitude develops an open-source, vision-first browser agent that automates web interactions using visual AI.

Their platform enables developers to create intuitive browser-based applications by leveraging computer vision to navigate and interact with web pages. It supports tasks like form filling and content scraping.

9) Cyberdesk (Summer 2025)

Cyberdesk offers a self-hostable fleet of virtual desktops for building computer use agents, enabling secure and scalable AI-driven desktop applications.

Their platform supports developers in creating agents that interact with desktop environments, automating tasks like file management and software testing. It integrates with existing workflows.

10) Herdora (Summer 2025)

Herdora provides open-source tools to supercharge GPU performance, optimizing AI and machine learning workloads for developers.

Their platform enhances computational efficiency by streamlining GPU resource allocation and task scheduling. It supports high-performance computing for AI model training and inference.

11) AgentMail (Summer 2025)

AgentMail provides email infrastructure for AI agents, enabling seamless communication and automation for AI-driven workflows.

Their platform supports scalable email integrations, allowing AI agents to send, receive, and process emails autonomously. It’s designed for applications like customer support and task automation.

12) Halluminate (Summer 2025)

Halluminate provides data and environments to train computer use AI, enabling developers to create robust AI agents for various applications.

Their platform offers curated datasets and simulated environments for training AI models to interact with software and devices. It supports use cases like automation and testing.

13) Cactus (Summer 2025)

Cactus enables developers to deploy AI models locally on smartphones, optimizing performance for mobile AI applications.

Their platform supports on-device model inference, reducing latency and enhancing privacy for AI-driven mobile apps. It’s designed for use cases like real-time image recognition and voice processing.

14) Plexe (Spring 2025)*

Plexe builds open-source agents that create predictive machine-learning models from natural language prompts, making ML development accessible to non-experts.

Their platform translates user prompts into executable ML models, supporting applications like predictive analytics and recommendation systems. It simplifies the ML pipeline with an intuitive interface.

Conclusion

These startups represent the cutting edge of YC’s open-source ecosystem in 2025, with a strong focus on AI-driven innovation. By contributing to their repositories, you can gain hands-on experience, connect with founders and developers, and help shape the future of tech. Visit their GitHub pages to find “good first issues,” join their Slack or Discord channels, and start coding. Your contributions, big or small, can make a real difference in these groundbreaking projects!

👉 If you found this helpful, don’t forget to share and follow for more agent-powered insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter.

Automate Tweets From YouTube Videos

HeetVekariya — Mon, 07 Jul 2025 19:48:40 +0000

Hello readers! Last Sunday, I was watching a YouTube video from the awesome BreakDown channel. It featured Nandan Nilekani’s talk, TheGreatUnlock, delivered on March, 2025. I highly recommend you watch this video !

The video was full of cool ideas that got me thinking! I was also looking for something to write about for my weekly blog, and I had a lightbulb moment: Why not turn the video’s insights into tweets? So, I created a Python script to do just that !

In this blog, I’ll walk you through the code in a simple way, keeping the tone same as my other blogs.

The Big Idea

The plan is straightforward: take a YouTube video, grab its spoken words (the transcript), create a short and insightful tweet, and share it on X. The script uses a few tools to make this happen: one to get the video’s transcript, another to post the tweet, and some smart “agents” to manage the process.

How the Code Works

Here’s the process in simple terms:

Get the Video’s Words: The script grabs the spoken text from the YouTube video using its web address (URL).
Make a Insightful Tweet: It picks out the best parts of the transcript and turns them into a short tweet (under 280 characters) that’s fun and shareable.
Share on X: The tweet gets sent to X using a special tool, so it goes live for everyone to see.

Let’s break down the code step by step.

Step 1: Setting Up the Tools

The script uses two main tools:

Video Text Tool: This retrives transcribe from a YouTube video.
Tweet Posting Agent: This posts the tweet to X.

youtube_summary_tool = FunctionTool(
    name="youtube_summary_tool",
    description="Gets the spoken words from a YouTube video using its URL.",
    params_json_schema=YouTubeSummaryArgs.model_json_schema(),
    on_invoke_tool=summarize_youtube_video
)

This tool uses a library called YouTubeTranscriptApi to fetch the video’s transcript. The code finds the video’s unique ID from the URL (like u5-UMgNZs6k from the BreakDown video) and pulls the text.

Step 2: Creating the Tweet

The script has a “Marketing Agent” that acts like a creative writer. It takes the video’s transcript, finds the most interesting facts, and crafts a tweet that’s short, engaging, and under 280 characters. The agent is told to make the tweet exciting so it has a chance to go viral.

def create_prompt(video_url):
    return f"""
You are a creative writer who makes exciting tweets from YouTube videos.

Steps to follow:
1. Get the video’s spoken words using the video text tool.
2. Write a short, catchy tweet (under 280 characters) based on the video’s content.
3. Pass the tweet to the Tweet Posting Agent to share it on X.

Target video: {video_url}
"""

Step 3: Posting the Tweet

Once the tweet is ready, the Marketing Agent hands it off to a “Tweet Posting Agent.” This agent uses a library called tweepy to connect to X and post the tweet.

twitter_client = tweepy.Client(
    bearer_token=os.getenv("TWITTER_BEARER_TOKEN"),
    consumer_key=os.getenv("TWITTER_CONSUMER_KEY"),
    consumer_secret=os.getenv("TWITTER_CONSUMER_SECRET"),
    access_token=os.getenv("TWITTER_ACCESS_TOKEN"),
    access_token_secret=os.getenv("TWITTER_ACCESS_TOKEN_SECRET"),
    wait_on_rate_limit=True
)
response = twitter_client.create_tweet(text=tweet)

The script uses secret keys (stored safely in a .env file, you can develop one for yourself using .env.example) to connect to X securely. Once the tweet is posted, the script checks if it worked and prints a success message.

Step 4: Tying It All Together

The main part of the script runs everything.

async def main(video_url=None):
    if video_url is None:
        video_url = "https://www.youtube.com/watch?v=u5-UMgNZs6k"

    print(f"Processing video: {video_url}")

    host_agent = create_host_agent(video_url)

    result = await Runner.run(
        host_agent,
        f"""Process this YouTube video: {video_url}
Steps:
1. Use the video text tool to get the transcript.
2. Create a catchy tweet based on the content.
3. Pass it to the Tweet Posting Agent to share on X.
"""
    )

    print("All done!")
    return result

This code starts with the BreakDown video URL (you can swap it for any YouTube video), runs the agents, and makes sure the tweet gets posted.

Why This Is Worth Giving a Try ?

This script is like a marketing machine for the YouTube content-creators. It saves time by automatically pulling video insights and turning them into tweets. You could use it for any YouTube video with a transcript—think tech talks, tutorials, or even funny vlogs. It’s a fun way to share ideas with your followers on X.

GitHub: YouTube-Tweet

Conclusion

This project was a fun way to turn interesting YouTube talks into short, shareable tweets. By combining a few Python tools, I was able to pull out insights from Nandan Nilekani’s talk and automatically post them to X. If you're someone who enjoys tech, content, or automation, give it a try with your favorite video. Thanks for reading!

👉 If you found this helpful, don’t forget to share and follow for more agent-powered insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter.

YCombinator : Who fuelled Start up culture

HeetVekariya — Sun, 29 Jun 2025 16:05:57 +0000

This blog is different from Tech, but worth exploring. Few months back I came to know about Y Combinator, who funds early stage startups.

Started exploring more about it, and it created more interest as more I go deep in it. Since then developing connection with YC applicants and it's alumnis.

With this blog, I will try to create same level of interest for you as well.

Okay let's start ....

Y Combinator

Y Combinator (YC) is widely known as the gold standard of start up accelerators, which formulised start up landscape since its inception in 2005. This blog includes YC’s history, scaling journey, investment domains, operational model, and the highly selective process for choosing startups. It has a track record of launching over 5,000 companies valued collectively at over $800 billion, including giants like Airbnb, Stripe, and Dropbox, YC’s influence is undeniable.

Fun Fact: Why YC termed as YC ?
Y Combinator's name is derived from the Y combinator, a concept in computer science that allows for recursive function calls. The founders chose the name to reflect their goal of combining ideas and funding to help startups grow and succeed.

The origin of Y Combinator

Y Combinator was founded in March 2005 by Paul Graham, Jessica Livingston, Robert Tappan Morris, and Trevor Blackwell. The idea emerged from Paul Graham’s vision to create a new model for startup funding that prioritized early-stage companies with bold ideas. Initially, YC operated two programs simultaneously in Cambridge, Massachusetts, and Mountain View, California. The first batch in 2005 included just eight startups, one of which was Reddit, with a total investment of $160,000.

Jessica Livingston, often underrecognized, played a main role in shaping YC’s culture and selection process, emphasizing founder potential and team dynamics. By 2009, operational complexities led to the consolidation of programs in Silicon Valley after a $2 million investment from Sequoia Capital, enabling YC to fund around 60 companies annually. In 2010, Sequoia provided an additional $8.25 million, further boosting YC’s capacity to support startups.

YC’s early model was experimental, described by Paul Graham as “something we thought people wanted.” The success of early alumni like Reddit validated the model, setting the stage for YC’s growth into a global phenomenon.

Journey of Y Combinator

YC’s scaling journey is marked by evolution in funding, program structure, and global reach. Here’s how YC grew:

Funding Evolution

Early Days (2005–2010): YC initially offered $20,000 for a 6–7% equity stake, a modest sum to help founders build prototypes and gain traction.
Standard Deal (Current): As of 2023, YC’s standard deal is $500,000 for 7% equity, split into $125,000 for a fixed 7% equity via a post-money SAFE and $375,000 via an uncapped SAFE with a Most Favored Nation (MFN) clause. This structure provides flexibility for startups to secure future funding at competitive valuations without immediate equity dilution for the additional $375,000.
Continuity Fund: Introduced in 2015 and discontinued in 2023, the YC Continuity Fund supported alumni in later-stage rounds (Series A and beyond), helping companies like Howdy scale operations.
Increased Batch Sizes: YC now runs four batches annually (winter, spring, summer, and fall), funding hundreds of startups per year, compared to the initial 8–15 per batch. Over 10,000 companies apply per cycle, with an acceptance rate of 1–3%.

Program Expansion

Additional Programs: YC introduced programs like the YC Fellowship (2015–2017) for pre-seed startups, Startup School (2017–2019), Series A Program, and YC Growth Program to support scaling startups. These initiatives cater to companies at different stages, ensuring lifelong support.
Global Reach: Initially U.S.-centric, YC now accepts startups globally, with international founders making up a growing portion of batches. Non-U.S. startups must incorporate in the U.S., Cayman, Singapore, or Canada, with YC providing legal support for “flipping” foreign entities.
Pandemic Adaptation: During COVID-19, YC transitioned to a fully online format, which proved effective and allowed greater participation from international founders. As of 2022, YC operates a hybrid model with in-person kickoff retreats and remote-friendly programming.

Alumni Network

YC’s alumni network, now over 9,000 founders, is a cornerstone of its ecosystem. Through Bookface, a private platform combining elements of LinkedIn and Quora, founders connect for advice, partnerships, and hiring. This network, including alumni from companies like Airbnb and Stripe, provides ongoing support, making YC a lifelong community.

Impact

As of 2025, YC has funded over 5,000 companies with a combined valuation of $800 billion. Approximately 45% of YC startups secure Series A funding (vs. 33% industry average), 4–5% become unicorns (vs. 2.5% average), and over 50% survive after 10 years (vs. 30% average). Notable successes include Airbnb ($100B valuation), Stripe ($70B), and DoorDash.

Investment Domains: Where YC Bets Big

YC’s investment strategy is broad but strategic, focusing on high-potential sectors with room for disruption. While YC funds startups across industries, key domains include:

Technology and Software: The majority of YC’s portfolio is tech-driven, with a focus on software-as-a-service (SaaS), fintech, and B2B solutions. Over 75% of recent batches are B2B companies, reflecting a shift from consumer-focused startups like Airbnb and DoorDash to enterprise solutions like Scale AI and Gusto.
Artificial Intelligence (AI): AI has become a dominant focus. Companies like Scale AI highlight YC’s emphasis on AI-driven innovation.
Fintech: Stripe, valued at $70 billion, exemplifies YC’s success in fintech. Other notable fintech alumni include Coinbase and Brex.
Consumer Tech: While less dominant today, consumer tech remains significant, with successes like Reddit, Instacart, and DoorDash. YC’s early investments capitalized on mobile and sharing-economy trends.
Healthcare and Biotech: YC funds innovative healthcare startups like Watsi (non-profit) and Benchling, focusing on scalable solutions.
Non-Profits: Since 2013, YC has funded non-profits like Watsi, 80,000 Hours, and Our World in Data, expanding its impact beyond for-profit ventures.
Emerging Markets: YC increasingly supports startups in Africa, Latin America (e.g., Howdy), and other regions, fostering diversity and global innovation.

YC’s structured approach allows it to fund “far-fetched” ideas with massive potential, provided they target large or emerging markets.

How Y Combinator Functions

YC operates as a three-month intensive program designed to help startups achieve product-market fit, refine business models, and secure follow-on funding. Here’s a breakdown:

Program Structure

Batches: YC runs four cohorts annually, each lasting three months, with startups sorted into groups of 6–10 for intimate mentorship. Each group is led by YC partners, who provide group and one-on-one office hours.
Mentorship: Founders receive guidance from YC partners (many of whom are successful alumni) and access to industry experts, lawyers, and mentors. Office hours focus on refining products, managing growth, and navigating fundraising.
Demo Day: The program culminates in Demo Day, where startups pitch to top-tier venture capitalists and angel investors. This event often leads to significant funding rounds, with YC facilitating negotiations for favorable terms.
Resources: YC provides over $500,000 in free credits and discounts from partners (e.g., AWS, banking services), access to the YC Investor Database (50,000+ investors), and tools like Bookface for networking.

Operational Philosophy

Founder-Centric: YC emphasizes founder potential over polished business plans, avoiding rigid requirements like MBAs or decks.
Intensity: Described as a “bootcamp,” YC creates an immersive environment where founders focus solely on their startups, fostering rapid progress.
Continuous Support: Post-program, YC offers lifelong support through alumni events, hiring platforms (Work at a Startup), and follow-on funding opportunities.

Funding Mechanics

YC’s $500,000 investment is split into two SAFEs:

$125,000 Post-Money SAFE: Converts to 7% equity in the next priced round.
$375,000 Uncapped MFN SAFE: Converts based on the lowest cap terms in the next round, offering flexibility.

YC’s model avoids fees, complex terms, or milestone contingencies, making it founder-friendly compared to other accelerators like Techstars.

Who Y Combinator Accepts and Why

YC’s acceptance criteria prioritize potential, execution, and market impact over polished presentations. Key factors include:

Strong Founding Teams: YC seeks resilient, coachable founders with complementary skills (e.g., technical and business expertise). While solo founders are accepted (e.g., Drew Houston of Dropbox), teams of 2–3 are preferred for shared workload and decision-making.
Innovative Ideas: YC favors startups with bold, scalable ideas that disrupt large markets or create new ones. Early traction or prototypes are preferred but not mandatory; even idea-stage startups can be accepted if the vision is compelling.
Market Potential: Startups targeting large or growing markets (e.g., AI, fintech) are prioritized. Niche markets are less likely to be accepted unless they show significant scalability.
Traction and Execution: Evidence of progress (e.g., user growth, revenue, or prototypes) strengthens applications. YC values “relentlessly resourceful” founders who can navigate obstacles creatively.
Passion and Vision: Founders must demonstrate commitment and a clear vision. YC looks for “naughty” founders who hack systems and solve problems unconventionally.
Diversity and Global Reach: YC encourages applications from underrepresented founders and international startups, with a commitment to diversity and inclusion.

YC’s 1–3% acceptance rate reflects its rigorous standards, with over 10,000 applications per batch. Only 7% of applicants reach the interview stage, and 42% of those are accepted.

The Selection Process

YC’s selection process is streamlined yet highly competitive, designed to identify high-potential startups efficiently:

Online Application: Startups apply via YC’s online form, detailing founder backgrounds, the idea, traction, and market potential. Clarity and conciseness are critical; vague or jargon-heavy applications are often rejected. Applicants are encouraged to describe their idea as a variant of something familiar (e.g., “It’s like Airbnb for X”).
Application Review: YC partners manually review applications, prioritizing those with clear, fact-based narratives. Over 20,000 applications are submitted per batch, making brevity and specificity essential.
Interviews: About 7% of applicants are invited to 30-minute interviews, held in person or virtually. Interviews are intense, testing founders’ clarity, resilience, and ability to execute. YC funds multiple startups in similar spaces, so overlapping ideas are not a barrier.
Acceptance: Accepted startups receive $500,000 and join the three-month program. YC commits to the investment immediately upon acceptance, with no milestones required.
Reapplication Encouraged: Many successful YC startups (e.g., WebApp) were accepted after multiple attempts, as YC values progress and persistence.

Why YC’s Model Works

YC’s success stems from its founder-centric approach, vast network, and data-driven mentorship. The program’s intensity accelerates startup growth, while the alumni network and Demo Day provide unparalleled access to capital and talent. YC’s brand adds instant credibility, boosting valuations and attracting top investors.

However, YC isn’t for everyone. Its structured, high-pressure environment may not suit founders who prefer independence or whose startups don’t align with VC-scale growth. Alternatives like bootstrapping or other accelerators (e.g., Techstars) may be better for some.

Conclusion

Y Combinator has redefined startup acceleration by combining substantial funding, intensive mentorship, and a powerful network. From its humble beginnings in 2005 to its global today, YC’s evolution reflects its adaptability and commitment to innovation. For founders with bold ideas and relentless drive, YC offers a transformative opportunity one that demands clarity, resilience, and a vision for massive impact.

For more information, visit Y Combinator’s official website or explore their application guide.

👉 If you found this helpful, don’t forget to share and follow for more such insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter.

What Is n8n ? Nodemation = n8n

HeetVekariya — Sun, 22 Jun 2025 07:53:38 +0000

Automating redundant tasks without human intervention is getting the requirement of business firms and individuals nowadays. The word n8n grab the attention from tech community to automate the tasks very easily with drag and drop like interface.

N8N makes automation accessible to everyone, from small businesses to technical teams, enabling seamless integration of apps and data. This blog introduces n8n, a powerful open-source workflow automation platform.

We’ll cover its origins, technical and business benefits, setup process, a practical example, and how its community-driven templates are helping users gain recognition.

What is n8n?

Nodemation which is the concatenated word of Node + Automation, and further being reduced to n8n (pronounced “n-eight-n”). It is an open-source workflow automation tool designed to connect applications and services through visual workflows.

It uses a node-based system where each “node” represents an action or trigger, such as fetching data from an API or sending a notification. With over 400 integrations, n8n supports tools like Google Workspace, Slack, CRMs, and custom APIs. Its visual editor allows non-coders to build workflows, while developers can add custom JavaScript or Python for advanced logic.

n8n offers both self-hosted and cloud options. Self-hosting provides full data control, ideal for businesses with strict compliance needs, while n8n Cloud simplifies setup for quick deployment. Its fair-code license ensures transparency, with source code available on GitHub. n8n’s flexibility and AI integration capabilities make it a go-to for automating repetitive tasks and building AI-driven workflows.

Benefits of n8n Compared to Manual Work

Email Manager workflow by Max Mitcham

Manual processes are time-intensive, error-prone, and hard to scale. n8n automates these, offering significant advantages for businesses, individuals and technical teams:

Time Efficiency: Automating tasks like data entry or report generation saves hours. For example, a sales team can use n8n to pull leads from a website form into a CRM, eliminating manual copying.

Error Reduction: Manual data entry risks mistakes. n8n ensures accurate data transfer, such as syncing e-commerce orders to inventory systems without typos.

Scalability: n8n handles growing workloads. A marketing team can automate social media posts across platforms, scaling from one post to thousands without extra effort.

Cost Savings: By reducing manual work, n8n lowers labor costs. A Hostinger tutorial notes businesses save significantly by automating tasks like invoice processing.

Easy AI Integration: n8n provides AI Agent nodes out of the box to integrate AI capabilities in the workflows without any complex coding. This is best advantage n8n has as compared to it's competitors in the market.

Customization: n8n’s code nodes allow tailored solutions. For instance, i automated firing a request to World's first publicly deployed A2A Agent which gets down every 15 minutes of inactivity due to free tier of Render. Now it doesn't because of N8N.

Business Example: A small e-commerce store manually tracks inventory updates. With n8n, a workflow can monitor Shopify orders, update stock levels in Google Sheets, and notify the warehouse via Slack, saving hours daily and reducing stock discrepancies.

Technical Example: Developers can use n8n’s HTTP Request node to connect to proprietary APIs, transforming data with JavaScript. For instance, a workflow could fetch weather data, process it, and trigger alerts for specific conditions, all without writing a full script.

How n8n Came to Be ?

n8n was founded in 2019 by Jan Oberhauser in Berlin to address the need for a flexible, open-source alternative to tools like Zapier. Oberhauser, seeking a concise name for “nodemation” (node + automation), chose n8n for its brevity, as he explained on GitHub. Launched with a node-based approach, n8n quickly gained popularity for its ease of use and extensibility. In 2020, it received Sequoia’s first seed investment in Germany, followed by a €55 million Series B in 2023, led by Highland Capital, reflecting its growing traction.

By 2021, n8n introduced its cloud service, making it accessible to non-technical users. Today, with over 100 million Docker pulls and a community of 200,000, n8n is a leader in automation. Its AI-native capabilities, built on frameworks like LangChain, allow users to embed AI into workflows, such as summarizing emails or generating content. The platform’s growth is fueled by its active community, contributing over 2600+ templates to the n8n template library.

n8n Templates and Community Fame

n8n’s community-driven template library is a cornerstone of its success, offering over 2600+ pre-built workflows for tasks like social media automation, lead generation, and AI-driven content creation. These templates, shared via n8n.io, allow users to quickly adopt solutions for industries like marketing, sales, and finance. Templates range from simple (e.g., syncing Google Sheets to Slack) to complex (e.g., AI-powered invoice processing with OCR).

Business Impact: Templates accelerate adoption by providing ready-to-use solutions. For example, a marketing agency can use a template to automate TikTok clip creation from podcasts, as noted in n8n’s community workflows. A finance team might use a template to process invoices via Gmail and Google Sheets, reducing errors and saving time.

Technical Details: Templates leverage n8n’s node types:

Trigger Nodes: Start workflows (e.g., “On a Schedule” or “Webhook”).
Action Nodes: Perform tasks (e.g., post to LinkedIn, fetch API data).
Code Nodes: Allow JavaScript or Python for custom logic.
AI Nodes: Integrate with models like OpenAI or Google Gemini for tasks like summarization or image generation.

For advanced users, templates can be customized with conditional logic (If nodes), error handling (Error Trigger nodes), and retries for reliability. n8n’s documentation recommends quad-core CPUs, 8GB+ RAM, and PostgreSQL/MySQL for self-hosted instances to handle large workflows efficiently.

Community Recognition: Sharing templates has made some creators well-known. For instance, posts on X and LinkedIn highlight users like Nate Herkelman, Alex, Nozz, who shared many templates for industries like Sales, Marketing, Real estate and Content creation, reportedly earning high $$$ in consulting fees. These creators gain fame by contributing to n8n’s template library, where featured templates boost visibility and affiliate earnings. Communities like Reddit’s r/n8n and n8n’s forum amplify their reach, with users sharing use cases and troubleshooting tips.

Setting Up n8n

n8n can be self-hosted for full control or used via n8n Cloud. Here’s how to set up a self-hosted instance using Docker:

Install Docker: Download from Docker’s website and ensure it’s running.
Run n8n: In a terminal, execute:

docker volume create n8n_data

docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

This maps port 5678 and persists data in a volume.

Access n8n: Navigate to http://localhost:5678 in your browser.
Configure Account: Set up an admin account in the n8n UI.
Add Integrations: Connect apps like Slack or Google by adding credentials in the UI.
Optimize Performance: For production, use a quad-core CPU, 8GB RAM, and a PostgreSQL database, as recommended by Hostinger.

For n8n Cloud, sign up at n8n.io for €20/month (Starter plan). Self-hosting is free but requires technical setup though it is very easy. n8n is SOC2-compliant, with encrypted data transfers and secure credential storage, ideal for businesses. See n8n’s docs for detailed guides.

Simple Example Implementation

Here’s a workflow to create an AI-powered daily Gmail summary and send it to Slack using n8n:

Create Workflow: In n8n, click “Add Workflow.”
Add Schedule Trigger: Use the “Schedule” node to run the workflow daily at 9:00 AM.
Add Gmail Node:
- Add a “Gmail” node.
- Authenticate with your Google account.
- Set it to fetch emails received in the last 24 hours.
- Filter by label or unread status if needed.
Add AI Agent (OpenAI or Google PaLM Node):
- Add an “OpenAI” (or “Google PaLM”) node.
- Pass the email subjects and snippets to the AI.
- Prompt example: "Summarize the following emails into a brief daily summary for the team: {{ emailList }}"
Add Slack Node:
- Add a “Slack” node.
- Authenticate with Slack.
- Post the AI-generated summary to a specific Slack channel.
Test and Activate: Run the workflow to verify the summary is generated and sent correctly, then activate it to run daily.

This workflow saves hours of manual lead tracking. Explore similar templates at n8n’s community library.

Conclusion

n8n is a versatile tool that simplifies automation for businesses and technical users. Since its 2019 launch, it has grown into a robust platform with over 400 integrations and a vibrant community contributing 2600+ templates.

Its benefits time savings, error reduction, scalability, and customization, make it ideal for tasks like lead management or AI-driven content creation. Community creators are gaining recognition by sharing high-impact workflows, some generating significant revenue. With easy setup and powerful features, n8n empowers anyone to automate smarter. Start with a free self-hosted instance or explore templates at n8n.io to transform your workflows.

👉 If you found this helpful, don’t forget to share and follow for more agent-powered insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter.

Comparing Multi-Agent Framework SDKs

HeetVekariya — Wed, 18 Jun 2025 15:51:54 +0000

We explored about A2A and MCP in the previous blogs and how can we use them to work together. Now let's shift focus from protocols to building actual multi-agent systems.

There are several SDKs and frameworks available that the community uses today like CrewAI, LangChain, OpenAI Agent SDK, and Google Agent Development Kit (ADK).

While exploring options, I couldn’t find a clear comparison of these frameworks so I made one.

Each SDK brings something different to the table, from simplicity and flexibility to enterprise-grade scalability. In this blog, I’ll compare these four based on real parameters, using a simple and consistent example to highlight their strengths and trade-offs.

How We'll Compare These Agent Development Kits

The goal here is to help developers (like you and me) pick the right multi-agent framework.

We'll look at:

Ease of use
Model support
Agent collaboration
Scalability

To make it fair, we’ll use the same example across all frameworks: a system with three teaching agents (Math, Science, History) and one Principal agent, all powered by Gemini 2.0 Flash.

This way, we can actually see how each framework performs when solving the same problem.

Exploring the Four Agent Development Kits (ADKs)

1. LangChain

LangChain is one of the most widely adopted frameworks for LLM apps, with over 110k GitHub stars. It’s known for its flexibility, community support, and massive ecosystem.

It uses a chain and agent architecture, you can combine tools, agents, and prompts to build complex logic.
Multi-agent support is possible but requires manual coordination.
It supports a wide range of models, vector stores, and retrieval strategies, great for both RAG pipelines and agent workflows.

If you want full control over your agent logic, LangChain is solid.

Installation Guide

2. CrewAI

CrewAI is purpose-built for multi-agent systems.

Agents are defined with roles and tasks, and they operate as a coordinated “crew.”
It simplifies collaboration and delegation between agents.
Used by companies like Oracle and Deloitte for enterprise AI tasks.

If your use case requires multiple agents working as a team, CrewAI feels very natural and productive.

Installation Guide

3. OpenAI Agent SDK

OpenAI’s Agent SDK is still evolving and it does supports other models outside OpenAI's.

Tightly integrated with OpenAI APIs and tool calling.
Agents can automatically access tools or pass off tasks to other agents.
Good for early experimentation and small-scale agent setups, though it may be limited outside the OpenAI ecosystem.

If you're building with OpenAI tools and want fast prototyping, this SDK can be a quick start.

Installation Guide

4. Google Agent Development Kit (ADK)

Google ADK, launched in April 2025, is a newcomer but powerful if you're in the Google ecosystem.

Built specifically for multi-agent setups.
Has a built-in handoff system, agents can pass tasks naturally to each other.
Native integration with Gemini models, Vertex AI, while supporting other models as well.
Lacks the community size of LangChain or CrewAI, but it’s growing, including myself.

If you want a clean developer experience with tight Gemini model integration, Google ADK is worth exploring.

Installation Guide

Now that we’ve got a sense of each framework, let’s implement the same example with each and compare how they differ in practice.

Example: Teaching Agents System

To make this comparison hands-on, we’ll build a small system using each framework. The system has:

Three Teaching Agents
- Math Teacher – answers math queries (e.g., “Solve 2x + 3 = 7”)
- Science Teacher – explains science concepts (e.g., “What is photosynthesis?”)
- History Teacher – responds to history questions (e.g., “What is the capital of France?”)
One Principal Agent
- Routes student questions to the appropriate teacher agent
Model
- All agents use Gemini 2.0 Flash—a fast, multimodal model

This example stays consistent across frameworks, helping us focus purely on the developer experience and capability differences.

LangChain Implementation

from langchain_google_genai import ChatGoogleGenerativeAI
from langchain.agents import initialize_agent, Tool, AgentType

# Initialize Gemini 2.0 Flash LLM
llm = ChatGoogleGenerativeAI(
    model="gemini-2.0-flash", 
    convert_system_message_to_human=True,
    temperature=0.7
)

# Define Teaching Agent Tools
def ask_math_agent(query: str) -> str:
    prompt = f"You are a math teacher. Answer this math question: {query}"
    return llm.invoke(prompt).content

def ask_science_agent(query: str) -> str:
    prompt = f"You are a science teacher. Answer this science question: {query}"
    return llm.invoke(prompt).content

def ask_history_agent(query: str) -> str:
    prompt = f"You are a history teacher. Answer this history question: {query}"
    return llm.invoke(prompt).content

# Define Tools for Principal Agent
tools = [
    Tool(name="AskMath", func=ask_math_agent, description="Use for math questions."),
    Tool(name="AskScience", func=ask_science_agent, description="Use for science questions."),
    Tool(name="AskHistory", func=ask_history_agent, description="Use for history questions."),
]

# Initialize Principal Agent (Router)
principal_agent = initialize_agent(
    tools=tools,
    llm=llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True,
    handle_parsing_errors=True
)

# Run the System
student_query = "What is the capital of France?"
response = principal_agent.run(student_query)
print(response)

student_query = "What is the square root of 144? also explain the process."
response = principal_agent.run(student_query)
print(response)

student_query = "Who was the second president of the United States?"
response = principal_agent.run(student_query)
print(response)

LLM Initialization: We initialize Gemini 2.0 Flash from Google using LangChain’s ChatGoogleGenerativeAI. It serves as the core reasoning engine for all agents.
Teaching Agents (Tools): Instead of building separate agents, we wrap each teaching function (Math, Science, History) inside a tool, a callable function paired with a description. Each tool receives a query, adds a role-specific prompt (e.g., "You are a math teacher..."), and gets a response from the LLM.
Principal Agent (Router): LangChain’s initialize_agent() is used to create a zero-shot reactive agent. This agent sees the student’s question, chooses the appropriate tool based on the descriptions, and delegates the question to that tool. For example, if the question is about “photosynthesis,” it will select AskScience.

> Entering new AgentExecutor chain...

I need to find out who the second president of the United States was.
Action: AskHistory
Action Input: Who was the second president of the United States?
Observation: Ah, a classic! The second president of the United States was **John Adams**. He served from 1797 to 1801. A fascinating and often overlooked figure in American history, Adams was a key player in the American Revolution and a staunch advocate for independence. However, his presidency was marked by controversy and challenges, particularly surrounding the Alien and Sedition Acts. Definitely a period worth further exploration!
Thought: I have the answer.
Final Answer: John Adams

> Finished chain.
John Adams

CrewAI Implementation

CrewAI follows a specific directory structure for it's implementation, so we will do the same as defined in the docs.

Agents.yaml

math_teacher:
  role: "Math Teacher"
  goal: "Answer students' math questions clearly."
  backstory: >
    A passionate math educator skilled in algebra, calculus, and problem-solving.

science_teacher:
  role: "Science Teacher"
  goal: "Answer students' science questions clearly."
  backstory: >
    A curious scientist passionate about physics, chemistry, and biology.

history_teacher:
  role: "History Teacher"
  goal: "Answer students' history questions clearly."
  backstory: >
    A knowledgeable historian focused on events from ancient to modern times.

principal:
  role: "School Principal to route query to the right teacher"
  goal: "Route student queries to the appropriate teacher."
  backstory: >
    A wise principal who knows where each question belongs.

Agent Configuration (agents.yaml): Each teaching agent (Math, Science, History) and the Principal is defined with a clear role, goal, and backstory. This information guides the behavior of each agent during execution.

For instance, the math_teacher is framed as an algebra expert with a passion for problem-solving.

Tasks.yaml

route_task:
  description: "Receive student query, i.e. {topic}, and delegate to correct teacher agent."
  expected_output: "The final answer from the most relevant teacher."
  agent: principal

math_task:
  description: "Answer the math question of {topic}."
  expected_output: "A detailed math answer."
  agent: math_teacher

science_task:
  description: "Answer the science question of {topic}."
  expected_output: "A clear science answer."
  agent: science_teacher

history_task:
  description: "Answer the history question of {topic}."
  expected_output: "A descriptive history answer."
  agent: history_teacher

Task Configuration (tasks.yaml): Each agent is assigned a task tailored to their subject expertise. The route_task is given to the Principal, who acts as the system's router. It receives the student query and determines which teaching agent should handle it.

Crew.py


from dotenv import load_dotenv
from crewai import Agent, Crew, Process, Task, LLM
from crewai.project import CrewBase, agent, crew, task

llm = LLM(
    model="gemini/gemini-2.0-flash",
    temperature=0.7,  # Adjust temperature for response variability
)

# Load environment variables from .env file
load_dotenv()

@CrewBase
class SchoolCrew:
    """Crew to route student queries to subject teachers"""

    @agent
    def principal(self) -> Agent:
        return Agent(
            config=self.agents_config['principal'],
            verbose=True,
            llm=llm,
        )

    @agent
    def math_teacher(self) -> Agent:
        return Agent(config=self.agents_config['math_teacher'], verbose=True, llm=llm)

    @agent
    def science_teacher(self) -> Agent:
        return Agent(config=self.agents_config['science_teacher'], verbose=True, llm=llm)

    @agent
    def history_teacher(self) -> Agent:
        return Agent(config=self.agents_config['history_teacher'], verbose=True, llm=llm)

    @task
    def route_task(self) -> Task:
        return Task(config=self.tasks_config['route_task'])

    @task
    def math_task(self) -> Task:
        return Task(config=self.tasks_config['math_task'])

    @task
    def science_task(self) -> Task:
        return Task(config=self.tasks_config['science_task'])

    @task
    def history_task(self) -> Task:
        return Task(config=self.tasks_config['history_task'])

    @crew
    def crew(self) -> Crew:
        return Crew(
            agents=[self.math_teacher(), self.science_teacher(), self.history_teacher(), self.social_studies_teacher()],
            manager_agent=self.principal(),
            tasks=[self.route_task(), self.math_task(), self.science_task(), self.history_task(), self.social_studies_task()],
            process=Process.hierarchical,  # Dynamic routing
            verbose=True
        )

System Setup (crew.py): Using the CrewBase class, agents and tasks are instantiated and grouped into a Crew. The principal acts as the manager agent, responsible for delegating tasks. The Process.hierarchical mode enables dynamic task routing based on the query context, mimicking decision-making in an actual school environment.

Main.py

import os
from crew import SchoolCrew

os.makedirs('output', exist_ok=True)

def run():
    inputs = {"topic": "What is the capital of France?"}
    result = SchoolCrew().crew().kickoff(inputs=inputs)
    print("\n=== FINAL RESPONSE ===\n", result.raw)

    inputs = {"topic": "What is the square root of 144? also explain the process."}
    result = SchoolCrew().crew().kickoff(inputs=inputs)
    print("\n=== FINAL RESPONSE ===\n", result.raw)

    inputs = {"topic": "Who was the first president of the United States?"}
    result = SchoolCrew().crew().kickoff(inputs=inputs)
    print("\n=== FINAL RESPONSE ===\n", result.raw)

if __name__ == "__main__":
    run()

Execution (main.py): The system is run with various student queries passed as topic inputs. The crew evaluates the query, the principal agent routes it to the relevant teacher, and the appropriate teacher provides the answer using Gemini 2.0 Flash.

Note : CrewAI's output is long due to logging of each thinking process, so I'm not able to show you here. You can always run it and check the output.

OpenAI ADK Implementation

import asyncio
from agents import Agent
from agents import Runner

math_agent = Agent(
    name="MathAgent",
    model="litellm/gemini/gemini-2.0-flash",
    instructions="You are a math expert. Provide clear and concise answers to math-related questions.",
)
science_agent = Agent(
    name="ScienceAgent",
    model="litellm/gemini/gemini-2.0-flash",
    instructions="You are a science expert. Provide clear and concise answers to science-related questions.",
)
history_agent = Agent(
    name="HistoryAgent",
    model="litellm/gemini/gemini-2.0-flash",
    instructions="You are a history expert. Provide clear and concise answers to history-related questions.",
)

principal_agent = Agent(
    name="TriggerAgent",
    model="litellm/gemini/gemini-2.0-flash",
    instructions="You are a trigger agent. You will delegate questions to the appropriate subject expert based on the topic.",
    handoffs=[math_agent, science_agent, history_agent]
)

async def main():
    result = await Runner.run(principal_agent, "What is the capital of France?")
    print(result.final_output)

    result = await Runner.run(principal_agent, "What is the square root of 144? also explain the process.")
    print(result.final_output)

    result = await Runner.run(principal_agent, "Who was the first president of the United States?")
    print(result.final_output)

asyncio.run(main())

Agent Creation with Specialization: Using OpenAI's ADK, we define multiple subject-specific agents (Math, Science, History). Each agent is initialized using the Agent class and powered by Gemini 2.0 Flash (via litellm). Every agent is assigned domain-specific instructions, guiding it to act as an expert in its respective field.
Central Delegator Agent: The TriggerAgent plays the role of a principal or router agent. It uses the same LLM but with a distinct instruction: identify the topic of the incoming question and handoff the task to the appropriate subject expert agent. This delegation logic is defined using the handoffs parameter in the agent configuration.
Execution with Runner: The Runner.run() function is used to pass user queries to the TriggerAgent. Based on the query context, the agent determines which expert to forward the question to. The responses are collected and printed, simulating an asynchronous interaction loop.
OpenAI ADK’s Edge: The ADK provides a clean and modular agent composition interface. It abstracts the routing and execution mechanics, allowing developers to define multi-agent collaboration using just simple Python classes and async runners, without deeply managing LLM context or chaining logic manually.

Query: Who was the first president of the India?

Dr. Rajendra Prasad was the first president of India.

Google ADK Implementation

import asyncio
from google.adk.agents import Agent
from google.adk.sessions import InMemorySessionService
from google.adk.runners import Runner
from google.genai import types # For creating message Content/Parts

# Initialize Agents with Gemini 2.0 Flash
math_agent = Agent(
    name="MathTeacher", 
    model="gemini-2.0-flash",
    description="A math teacher who answers math-related questions.",
    instruction="You are a helpful math teacher. You only answer math-related questions."
)
science_agent = Agent(
    name="ScienceTeacher", 
    model="gemini-2.0-flash",
    description="A science teacher who answers science-related questions.",
    instruction="You are a helpful science teacher. You only answer science-related questions."
)
history_agent = Agent(
    name="HistoryTeacher", 
    model="gemini-2.0-flash",
    description="A history teacher who answers history-related questions.",
    instruction="You are a helpful history teacher. You only answer history-related questions."
)

principal_agent = Agent(
    name="Principal", 
    model="gemini-2.0-flash",
    description="A principal who manages the school system and delegates queries to appropriate teachers.",
    instruction="You are the principal of the school. You delegate questions to the appropriate teacher based on the subject.",
    sub_agents=[math_agent, science_agent, history_agent]
)

# Set Up Session Service
session_service = InMemorySessionService()
app_name = "SchoolSystem"
user_id = "Student_042"
session_id = "Session_001"

async def call_agent_async(query: str, runner, user_id, session_id):
  """Sends a query to the agent and prints the final response."""
  print(f"\n>>> User Query: {query}")

  content = types.Content(role='user', parts=[types.Part(text=query)])

  final_response_text = "Agent did not produce a final response." # Default

  async for event in runner.run_async(user_id=user_id, session_id=session_id, new_message=content):
      print(f"  [Event] Author: {event.author}, Type: {type(event).__name__}, Final: {event.is_final_response()}, Content: {event.content}")

      if event.is_final_response():
          if event.content and event.content.parts:
             final_response_text = event.content.parts[0].text
          elif event.actions and event.actions.escalate: # Handle potential errors/escalations
             final_response_text = f"Agent escalated: {event.error_message or 'No specific message.'}"
          break

  print(f"<<< Agent Response: {final_response_text}")

async def get_agent_response():
    session = await session_service.create_session(app_name=app_name, user_id=user_id, session_id=session_id)
    runner_agent_team = Runner(
        agent=principal_agent,
        app_name=app_name,
        session_service=session_service
    )

    print("Runner Agent Team initialized.")

    await call_agent_async(
        "What is the Pythagorean theorem?",
        runner_agent_team, 
        user_id, 
        session_id
    )

    await call_agent_async(
        "What is the chemical formula for water?",
        runner_agent_team, 
        user_id, 
        session_id
    )

    await call_agent_async(
        "Who was the first president of the United States?",
        runner_agent_team, 
        user_id, 
        session_id
    )

    await call_agent_async(
        "Which agents are available in the system?",
        runner_agent_team,
        user_id,
        session_id
    )

asyncio.run(get_agent_response())

Subject Agents Setup: In this setup, we define three specialized agents: MathTeacher, ScienceTeacher, and HistoryTeacher using Google’s ADK. Each agent is initialized with Gemini 2.0 Flash and has clear role-based instructions. These agents are only allowed to answer questions from their subject domain, which helps maintain accuracy and specialization.
Principal Agent (Coordinator): The Principal agent acts like a school head. It doesn't answer questions itself—instead, it routes student queries to the right subject expert using the sub_agents configuration. This delegation is automatic and based on the query content.
Session Handling: Google ADK introduces a session-based memory system. Using the InMemorySessionService, the conversation state is preserved across multiple queries from the same user. This makes the interaction feel more continuous and context-aware.
Runner Execution: The Runner object manages the overall flow. It takes care of delivering the user’s question, collecting streaming responses (via events), and printing the final reply. The interaction loop is asynchronous, and the ADK supports rich content handling and escalation when agents face uncertainty.
Google ADK’s Strength: Google’s ADK provides a structured and event-driven way to build agent teams. It focuses on modular design, session memory, and hierarchical agent coordination—making it great for scalable multi-agent applications that mimic real-world roles.

>>> User Query: What is the Pythagorean theorem?
<<< Agent Response: The Pythagorean theorem states that in a right triangle, the square of the length of the hypotenuse (the side opposite the right angle) is equal to the sum of the squares of the lengths of the other two sides. This can be written as:

a² + b² = c²

where:
*   a and b are the lengths of the two shorter sides (legs) of the right triangle
*   c is the length of the hypotenuse

Comparison Table

Parameter	LangChain	CrewAI	OpenAI Agent SDK	Google ADK
Ease of Use	High‑level APIs and many templates simplify development, but multi-agent setups still require manual orchestration	Very easy to bootstrap multi-agent workflows with minimal boilerplate	Lightweight primitives (Agents, Handoffs, Guardrails); straightforward to set up and debug	Clear sub‑agent structure makes delegation intuitive; event‑driven runner adds minimal complexity
Documentation Quality	Extensive guides, API refs, tutorials, and examples	Friendly and clear, though lacks depth in advanced scenarios	Concise, example‑rich, focused on agent patterns and production use	Fresh, detailed, and beginner‑friendly, especially around agent lifecycle and orchestration
Community Support	Massive, including 110k+ GitHub stars, Discord, Slack, third-party content	Growing user base backed by Oracle/Deloitte; active but smaller	Quickly growing; broad help across Reddit, GitHub, and blog posts	Emerging community with strong Google Cloud backing, but not as mature as others
Model Support	Native first-class support for OpenAI, Gemini, Anthropic, HuggingFace, etc.	Supports major LLMs including Gemini and OpenAI; model flexibility good	Designed for OpenAI models via Chat API; can be extended to custom providers using Litellm	Built for Gemini series, with seamless Vertex AI integration but extendes to providers using Litellm
Multi‑Agent Capabilities	Tool-based multi-agent support via chains and routers; DIY orchestration	Crew metaphor simplifies role‑based agent collaboration	Native support for handoffs makes delegation clean and traceable	Sub‑agents and handoffs offer robust, built-in multi-agent coordination
Tool Integration	50+ official integrations (APIs, DB, scraping, computation, etc.)	Integrated via LangChain backend; strong but slightly less extensive	Easy to add via Python functions; tool wrappers and guardrails supported	Full integration with Vertex AI tools, function calling, cloud APIs
Performance	Generally responsive; performance depends on chain optimization	Optimized for multi-agent workflows; performance smooth in practice	Fast execution with built-in tracing; overhead minimal for basic use	Native Gemini + cloud infra = low latency and high throughput
Scalability	Scales with LangSmith, distributed chains, but needs customization	Enterprise-ready orchestration; designed for scaling agent workflows	Built-in tracing, scalable with OpenAI infra; easy deployment	Cloud-native via Vertex AI; handles scale out-of-the-box
Cost	Open-source; pay only for model/API usage and hosting	Free core; API and enterprise feature usage incur costs	Free SDK; pay for OpenAI model usage and any custom deployments	Free-to-use SDK; pay for Gemini API (Free tier available) and Vertex AI compute

Codes for all implementation is available here: GitHub

Conclusion

So, who’s the winner?
It depends on what you’re working upon.

LangChain is your all-purpose tool, perfect for coders who want flexibility and a huge community to back them up,great for startups or solo projects.

CrewAI is the multi-agent master, making it easy to build collaborative AI teams, especially for enterprise gigs.

OpenAI Agent SDK is sleek and fast for OpenAI fans, but using Gemini 2.0 Flash requires some DIY, which might slow you down.

Google ADK is the new, ideal for Google Cloud users who want seamless Gemini integration and cloud scalability, though its community is still growing.

If you found this helpful, don’t forget to share and follow for more agent-powered insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter or LinkedIn.

What Is an AI Agent ?

HeetVekariya — Sun, 08 Jun 2025 06:17:51 +0000

The AI community is getting a shift in 2025 towards AI agents, which are designed to automate tasks just by taking a command as input. We're steadily moving towards an agentic framework, where multiple individual agents work together by communicating with each other. We have been following A2A and MCP in our recent blogs present here.

So, what exactly is an agent to begin with?

An agent is a software entity that can understand its environment, think about what it perceives, and then take actions to achieve a specific goal.

Let's use a simple example to understand this better. Imagine you're making pasta:

To buy required ingredients is the primary task.
Listing down the required ingredients means using your memory or context – in this case, the goal is to make pasta.
Defining the quantity of each ingredient is planning.
How to make the pasta with all the available ingredients involves reasoning.
Utilizing pans, gas, and other equipment are the tools you use.
Finally making pasta and serving it to the user is the task completion.

What Exactly Is an AI Agent Today?

In simple terms, an AI agent today is usually an LLM-powered system that can:

Understand what's going on: It captures its surroundings and the job it needs to do.
Make decisions: It figures out the best way to move towards its goal.
Do things using tools or other agents: This is where it gets interesting – it doesn't just think, it acts.

Imagine a tool like Cursor's agent mode, where you can describe a task and it autonomously explores your codebase, runs commands, finds context, and even applies fixes. These capabilities are pushing the limits of what an agent can do.

So, a straightforward way to think about it is:

"An AI agent is a system that can understand, plan, and act on its own to achieve goals, often by using a large language model (LLM) and other integrated tools."

The Main Parts of a Modern AI Agent

To build these self-operating systems, you need a few key ingredients. If you're playing around with frameworks like LangChain, CrewAI, or working with tools like n8n, you'll recognize these building blocks:

LLM (The Brain): This is the core intelligence. The large language model gives the agent its ability to understand, reason, and create human-like text, which is vital for planning and deciding what to do.
Tools / Access to other systems: These are the agent's "hands." Whether it's a web browser, a way to look up database information, a code runner, or a connection to other online services via n8n workflows, these tools let the agent interact with the real world and get things done.
Context: It helps the agent remember past actions, results and learned information so it can adjust its behavior over time.
Goal / Task Planner: This part breaks down big goals into smaller, manageable steps and figures out the best order to do them in.
Reason: Through different inputs (like documents, system prompts or past conversation), the agent understands its environment to make good decisions.

How AI Agents Work Today: Step by Step

Let's simplify how an AI agent operates:

Understand: It starts by reading your instructions along with its current situation (like an email, a code file, or a document).
Plan: Using its thinking abilities (often with methods like ReAct or Tree of Thoughts enabled by frameworks like LangChain), it creates a plan. This might involve breaking down the problem, choosing which tools to use, and outlining the steps.
Act: It then carries out its plan by using its tools. This could mean searching the web for information, using an online service, running a piece of code, or interacting with a database using MCP.
Learn (Optional but Powerful): Based on what happened after its actions, the agent can update its memory, improve its understanding, or even change its future plans. This constant feedback loop is what makes agents truly independent and maintain cross conversation context like chatGPT.

An example in action: Imagine a research agent built with LangChain. You give it a topic. It understands what you want, plans its research (like "find articles," "summarize key points"), acts by browsing the web and processing information, and then creates a complete report with references.

The Rise of Teams of AI Agents

This is where things get even more exciting. We're not just talking about one powerful agent anymore. The current trend is strongly moving towards Multi-Agent Systems (MAS), where several specialized agents work together to tackle incredibly complex tasks.

Think a team of human experts, but all powered by AI and communicating seamlessly. That's the idea. Agents can now talk to each other and coordinate, where Google is even taking it to the next level with their A2A (Agent-to-Agent) protocol. Frameworks like CrewAI are excellent examples of this, allowing you to define roles and goals for a team of agents.

A great example: Building a whole software application. You could have:

A Research Agent gathering requirements and understanding the problem.
A Coder Agent using tools like Cursor's agent mode to write the actual code.
A Tester Agent thoroughly checking the code for errors.
A Deployment Agent handling how the software gets released, possibly orchestrated via n8n workflows.

Platforms like CrewAI, LangGraph (part of LangChain), and n8n are leading the way in making these collaborative AI systems possible. It's truly changing how we'll build and use AI.

New Ways Agents Communicate: Protocols and Standards

For these teams of agents to work well, they need a common language and standard ways to interact. Two important protocols are making a difference:

A2A (Agent-to-Agent): This open system, promoted by Google, defines how AI agents find each other, agree on tasks, exchange messages, and work together across different systems. Think of it as the ultimate communication channel for your AI team.
MCP (Model Context Protocol): This focuses on how an agent connects with external resources, giving them access to everything they need to think and act.

These protocols are essential for making sure agents can work together smoothly, share goals, and expand their capabilities. They're setting the stage for a truly connected AI future.

Conclusion

AI agents are quickly moving from experimental tools to real-world collaborators. With the ability to understand tasks, plan intelligently, and take action using tools or other agents, they’re becoming a core part of how we build and automate in 2025. From single agents handling research or coding to multi-agent systems working together using standards like A2A and MCP, the shift toward agentic frameworks is already underway.

👉 If you found this helpful, don’t forget to share and follow for more agent-powered insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter.

DevTo AI Agent with A2A and MCP

HeetVekariya — Sat, 31 May 2025 10:08:43 +0000

As part of our ongoing series exploring A2A (Agent-to-Agent) and MCP (Model Context Protocol), most of our earlier work focused on understanding the fundamentals and recreating concepts already explored by the community.

We began with What is MCP? and followed it up with Integrating MCP Servers. Our attention then shifted to A2A with posts like What is A2A Protocol?, A2A Protocol Implementation, and A2A and MCP Combined Implementation.

Until now, these experiments mostly revolved around replicating existing ideas.

In this post, we’re changing things up.

HeetVekariya / devto-agent

Build and deploy an autonomous Devto Agent capable of interacting with the Dev.to platform, powered by A2A (Agent-to-Agent) and MCP (Model Context Protocol)

DevTo Agent

A comprehensive multi-agent system for interacting with Dev.to (DevTo) platform, built using Google ADK (Agent Development Kit) and Model Context Protocol (MCP). This project enables automated content creation, article management, and user profile interactions with DevTo through both Agent-to-Agent (A2A) communication and MCP server implementations.

You can find follow along blog here

Project Overview

This project implements a sophisticated agent architecture that can:

Fetch and manage DevTo articles by tags or authors
Generate and post markdown content to DevTo
Retrieve user profiles and reading lists
Manage article comments and followers
Provide both SSE (Server-Sent Events) and STDIO interfaces for different integration needs

Architecture Overview

The project follows a modular architecture with three main communication patterns:

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Client App    │───▶│  A2A Server     │───▶│   DevTo API     │
│   (main.py)     │    │ (devto_agent)   │

…

View on GitHub

This time, we’re implementing something original, a real-world agent that interacts with the Dev.to platform, where I publish my blogs :).

I have developed an A2A Registry for the AI community, do check it out and share in your network.

What Are We Building?

We are building a system where we will have a single agent, Devto Agent, supported by a Devto MCP Server. This setup will allow our agent to access Dev.to data such as:

Blogs
Articles
Comments
User information
And even publish new blogs

You might ask, How A2A will be implemented with single agent ?
Good question.

Even though it seems like a single agent is involved, there are actually two:

Host Agent – Handles incoming user requests and delegates tasks
Devto Agent – Specifically addresses Dev.to-related queries using the capabilities provided by the Devto MCP Server

In the architecture diagram above, we can clearly see the flow:

A CLI (the A2A client) accepts the user query and sends it to the Host Agent (A2A server)
The Host Agent then delegates the task to the Devto Agent
The Devto Agent, powered by the Devto MCP Server, processes the request and interacts with the Dev.to platform

With a good understanding of the architecture, let's move on to building it.

Implementation

We will be building this project from scratch. The first and most essential component is the MCP server, which enables third-party service integration and actionable capabilities for our agent.

Note: We will test the code at various stages throughout development. To test the code, you’ll need a Dev.to API key. The configuration steps for setting this up are provided in the Prerequisite section later in the blog. If you want to follow along and test as you go, head over to that section first and set up your Dev.to API key. Alternatively, you can wait until the end and test the main.py after installation.

MCP Server

The MCP server connects third-party services to our agent and enables interaction with external data sources. In our case, the third-party service is Dev.to, and we’ll be using it to:

Access blogs
Retrieve user data
Publish new content

Define Devto Service Class

Rather than hard-coding the logic directly into the MCP tool wrapper, we’ll create a separate DevtoService class. This class will encapsulate all the logic related to Dev.to operations, while the MCP tool will simply wrap and expose these service methods.

Let’s begin by defining the DevToService class, which will act as the core integration layer between our agent and the Dev.to API. This service class encapsulates the logic needed to communicate with the platform.

class DevToService:
    def __init__(self):
        self.api_key = os.getenv('DEVTO_API_KEY')
        self.base_url = os.getenv('DEVTO_BASE_URL')
        self.headers = {
            "api-key": self.api_key,
            "Content-Type": "application/json"
        }

    def send_request(self, method: str, endpoint: str, params=None, data=None):
        url = f"{self.base_url}/{endpoint}"
        headers = self.headers

        if method.lower() == 'get':
            response = requests.get(url, headers=headers, params=params)
        elif method.lower() == 'post':
            response = requests.post(url, headers=headers, json=data)
        else:
            raise ValueError("Unsupported HTTP method")

        if response.status_code == 200:
            return response.json()
        else:
            response.raise_for_status()


    # Article-related methods
    def get_articles(self, page: int = 1, per_page: int = 30):
        endpoint = "articles"
        params = {
            'page': page,
            'per_page': per_page
        }

        return self.send_request('get', endpoint, params=params)

    def get_articles_by_tag(self, tag: str):
        endpoint = "articles"
        params = {'tag': tag}

        return self.send_request('get', endpoint, params=params)

...

The constructor initializes the API key and base URL from environment variables and sets the required headers for authentication. A general-purpose method send_request is defined to handle both GET and POST requests.

Then, we define specific methods like get_articles and get_articles_by_tag which internally call send_request with appropriate parameters. This design keeps the logic clean and modular, making it easy to expand in the future.

Registering the Service with MCP

Next, we integrate our DevToService with the MCP framework. We instantiate a FastMCP server and register tools using the @mcp.tool() decorator.

These tools are simple wrappers around our service methods and expose the capability to external agents. For example:


mcp = FastMCP("DevTo MCP Server")

devto_service = DevToService()

@mcp.tool()
def get_articles(page: int = 1, per_page: int = 30) -> list:
    """
    Fetch articles from DevTo.

    Args:
        page (int): The page number to fetch.
        per_page (int): The number of articles per page.

    Returns:
        list: A list of articles from DevTo.
    """

    return devto_service.get_articles(page=page, per_page=per_page)

@mcp.tool()
def get_articles_by_tag(tag: str) -> list:
    """
    Fetch articles by a specific tag from DevTo.

    Args:
        tag (str): The tag to filter articles by.

    Returns:
        list: A list of articles with the specified tag.
    """

    return devto_service.get_articles_by_tag(tag=tag)

get_articles allows querying paginated articles from Dev.to
get_articles_by_tag filters articles based on specific tags

Using SSE-Based Communication

To support a networked agent environment and handle multiple clients effectively, we implement Server-Sent Events (SSE) using the Starlette web framework.

A new function sets up a Starlette application with the following:

def create_starlette_app(
    mcp_server: Server = mcp,
    *,
    debug: bool = False,
) -> Starlette:
    """
    Create a Starlette application with the MCP server.

    Args:
        mcp (Server): The MCP server instance.
        debug (bool): Whether to run the application in debug mode.

    Returns:
        Starlette: The Starlette application instance.
    """

    sse = SseServerTransport('/messages/')

    async def handle_sse(request: Request):
        async with sse.connect_sse(
            request.scope,
            request.receive,
            request._send # noqa: SLF001
        ) as (read_stream, write_stream):
            await mcp_server.run(
                read_stream,
                write_stream,
                mcp_server.create_initialization_options()
            )
        return Response(status_code=204)

    return Starlette(
        debug=debug,
        routes=[
            Route("/sse", endpoint=handle_sse),
            Mount("/messages/", app=sse.handle_post_message)
        ]
    )

An SSE route (/sse) that manages incoming stream connections from clients
A message-handling mount point (/messages/) to handle incoming data

This architecture allows asynchronous, scalable, real-time communication between the A2A host agent and the Devto MCP server.

Testing the MCP Server

With the MCP server implemented, we now test it using the MCP Inspector tool provided by the MCP framework.

To do this:

Run the Devto MCP server using mcp dev mcp_servers/sse/devto_server.py
Open the MCP Inspector interface.
Connect to the server.
Navigate to the Tools tab and list available tools.
Select any tool (e.g., get_articles) and execute it.

If the tool runs and returns a response successfully, our MCP server is functioning correctly and ready for integration with an A2A host agent.

Example output from a successful test is shown below:

Connector

To allow our agent to access the tools provided by the Devto MCP server, we first define a connector function. This function is responsible for:

Establishing a connection with the running MCP server
Retrieving the exposed tools
Returning those tools in a format the agent can use

async def get_devto_tools() -> tuple:
    """
    Retrieves the DevTo tools for agent.

    Returns:
        tuple: A tuple containing the DevTo toolset and exit stack.
    """

    print(colored("Attempting to connect with DevTo MCP server for blogs info...", "yellow"))

    server_parameters = SseServerParams(
        url="http://localhost:8000/sse/",
    )

    tools, exit_stack = await MCPToolset.from_server(connection_params=server_parameters)
    print(colored("MCP Toolset created successfully.", "green"))
    return tools, exit_stack

The function uses an SSE (Server-Sent Events) connection, assuming the MCP server is running at http://localhost:8000/sse/. On successful connection, it prints confirmation messages and returns both the toolset and a resource cleanup stack (exit_stack) for proper session handling.

Verifying the Connector with a Test Agent

Before jumping into building the full Devto agent, it's a good idea to validate our connector functionality with a simple test agent. For that purpose, we define a test script located at: test/test_devto_connection.py


async def get_tools() -> list:
    """
    Retrieves tools from Devto MCP server.

    Returns:
        list: A list of tools retrieved from the Devto MCP server.
    """
    tools, exit_stack = await get_devto_tools()
    return tools, exit_stack


async def get_agent():
    """
    Create an agent with Devto tools.
    """

    tools, exit_stack = await get_tools()
    print(f"Retrieved {len(tools)} tools from Devto MCP server.")

    agent = LlmAgent(
        model='gemini-2.0-flash', # Replace with your desired model
        name='DevtoAgent',
        description='An agent to interact with Devto articles and blogs.',
        instruction="You are an agent that can fetch articles, user information, and perform actions related to Devto blogs. Use the tools provided to answer user queries.",
        tools=tools,
    )

    return agent, exit_stack


async def main():
    session_service = InMemorySessionService()
    artifacts_service = InMemoryArtifactService()

    print("Creating session...")
    session = session_service.create_session(
        state={},
        app_name='Devto_Agent_App',
        user_id='devto_user',
        session_id='devto_session',
    )

    query = "Fetch the latest articles from Devto."
    print(f"\nQuery: {query}")
    content = types.Content(role='user', parts=[types.Part(text=query)])
    agent, exit_stack = await get_agent()

    print(colored("Agent created successfully.", "green"))
    runner = Runner(
        app_name='Devto_Agent_App',
        session_service=session_service,
        artifact_service=artifacts_service,
        agent=agent,
    )

    event_async = runner.run_async(session_id=session.id, user_id=session.user_id, new_message=content)

    print("********************* Agent Response *********************")
    async for event in event_async:
        if event.is_final_response():
            print(event.content.parts[0].text)

    await exit_stack.aclose()


if __name__ == "__main__":
    dotenv.load_dotenv()
    asyncio.run(main())

This script does the following:

Calls the connector function to get the Devto toolset.
Creates an LlmAgent instance and assigns it the retrieved tools.
Sets up a simple query: "Fetch the latest articles from Devto."
Uses an in-memory session and artifact service to simulate the run.
Prints the agent’s final response to the console.

This test acts as a minimal end-to-end validation of our Devto MCP server integration. It helps us ensure that:

The MCP server is correctly exposing tools
The tools are correctly loaded by the agent
The agent can generate meaningful responses using those tools

To perform the test:

In one terminal, start the Devto MCP server: uv run mcp_servers/sse/devto_server.py
In a second terminal, run the test agent script: uv run test/test_devto_connection.py

If everything is set up correctly, you should see log messages confirming tool retrieval and agent creation, followed by the actual response from the agent, based on the query.

This confirms that your Devto agent is correctly wired to the MCP server and ready to respond to real user queries.

Creating session...

Query: Fetch the latest articles from Devto.
Attempting to connect with DevTo MCP server for blogs info...
MCP Toolset created successfully.
Retrieved 11 tools from Devto MCP server.
Agent created successfully.
********************* Agent Response *********************
Warning: there are non-text parts in the response: ['function_call'], returning concatenated text result from text parts. Check the full candidates.content.parts accessor to get the full model response.

Here are the latest articles from Devto.
...

MCP Server logs...

INFO:     Started server process [5888]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://localhost:8000 (Press CTRL+C to quit)
INFO:     ::1:53003 - "GET /sse/ HTTP/1.1" 307 Temporary Redirect
INFO:     ::1:53003 - "GET /sse HTTP/1.1" 200 OK
INFO:     ::1:53004 - "POST /messages/?session_id=29d33a5d6a6041f2afb8475cca54b136 HTTP/1.1" 202 Accepted    
INFO:     ::1:53004 - "POST /messages/?session_id=29d33a5d6a6041f2afb8475cca54b136 HTTP/1.1" 202 Accepted    
INFO:     ::1:53004 - "POST /messages/?session_id=29d33a5d6a6041f2afb8475cca54b136 HTTP/1.1" 202 Accepted    
 INFO     Processing request of type ListToolsRequest                        server.py:551
INFO:     ::1:53004 - "POST /messages/?session_id=29d33a5d6a6041f2afb8475cca54b136 HTTP/1.1" 202 Accepted    
 INFO     Processing request of type CallToolRequest

Agents

Now that we have our Devto MCP server running and successfully connected to the agent through the connector, it's time to build the Devto agent using the A2A (Agent-to-Agent) protocol.

Directory Structure Overview

Here's a quick look at the structure inside the a2a_servers directory:

a2a_servers/              # Agent-to-Agent server implementations
│   ├── agent_server/         # Individual agent definitions
│   │   ├── devto_agent.py   # Main DevTo agent server
│   │   ├── host_agent.py    # Host agent coordinator
│   │   └── utils.py         # Agent utilities
│   ├── agents/              # Agent base classes and implementations
│   │   ├── adk_agent.py     # Google ADK agent wrapper
│   │   └── utils/           # Agent utilities
│   └── common/              # Shared components
│       ├── client/          # A2A client implementations
│       ├── server/          # A2A server implementations
│       └── types.py         # Common type definitions

Note: The agents and common directories are derived directly from the official Google A2A reference repository. These provide the standard A2A protocol implementation, and we will not modify them. Instead, all custom logic for the Devto agent lives within the agent_server directory.

Core A2A Concepts

Before diving into the implementation, it's important to understand a few foundational components of the A2A protocol:

Agent Card: A metadata document located at /.well-known/agent.json. It describes the agent's identity, capabilities, supported tools, and how to communicate with it. Other agents use this card to understand how to initiate interaction.
A2A Server: An HTTP server that hosts the agent. It accepts incoming task requests, maintains conversations, and returns results via standard A2A protocols.
A2A Client: Any application or external agent that communicates with the A2A server. Clients initiate tasks or conversations using defined endpoints (tasks/send, tasks/sendSubscribe, etc.).
Task: The fundamental unit of execution. Each task has a lifecycle (submitted, working, input-required, completed, failed, etc.) and manages all context for an interaction.
Message: Each communication in the task thread consists of a message from either the "user" or "agent", built from one or more parts.
Part: The smallest unit of content within a message. Types include:
- TextPart: Simple text
- FilePart: Files (inline or via URL)
- DataPart: Structured JSON
Artifact: Any output generated by the agent could be text, structured data, or files. These are also made up of parts.
Streaming: A2A supports real-time task updates using tasks/sendSubscribe, allowing clients to receive server-sent events (SSE) as the task progresses.
Push Notifications: Optionally, agents can send task updates to a client-defined webhook. This enables proactive status updates without polling.

In our code we use,
1) AgentCard class: To prepare agent.json information

class AgentCard(BaseModel):
    name: str
    description: str | None = None
    url: str
    provider: AgentProvider | None = None
    version: str
    documentationUrl: str | None = None
    capabilities: AgentCapabilities
    authentication: AgentAuthentication | None = None
    defaultInputModes: List[str] = ["text"]
    defaultOutputModes: List[str] = ["text"]
    skills: List[AgentSkill]

2) ADKAgent class: A blue print class to define agent with different configuration.

class ADKAgent:
    """
    An agent that can delegate tasks to remote agents using the ADK framework.
    This agent can list remote agents, send tasks to them, and handle task updates.
    It is designed to orchestrate the decomposition of user requests into tasks that can be performed by child agents.
    """

    SUPPORTED_CONTENT_TYPES = ["text", "text/plain"]

    def __init__(
        self,
        model: str,
        name: str,
        description: str,
        instructions: str,
        tools: List[Any],
        is_host_agent: bool = False,
        remote_agent_addresses: List[str] = None,
        task_callback: TaskUpdateCallback | None = None
    ):
        """
        Initializes the ADKAgent with the given parameters.
        """

3) A2AServer class: To deploy an agent on a port, which makes it discoverable to other agents.

class A2AServer:
    def __init__(
        self,
        host="localhost",
        port=5000,
        endpoint="/",
        agent_card: AgentCard = None,
        task_manager: TaskManager = None,
    ):
        self.host = host
        self.port = port
        self.endpoint = endpoint
        self.task_manager = task_manager
        self.agent_card = agent_card
        self.app = Starlette()
        self.app.add_route(self.endpoint, self._process_request, methods=["POST"])
        self.app.add_route(
            "/.well-known/agent.json", self._get_agent_card, methods=["GET"]
        )

4) A2AClient class: To handle user queries and sends it to A2AServer i.e. host agent.

class A2AClient:
    def __init__(self, agent_card: AgentCard = None, url: str = None):
        if agent_card:
            self.url = agent_card.url
        elif url:
            self.url = url
        else:
            raise ValueError("Must provide either agent_card or url")

Now that we understand the A2A components, let's look at how our Devto Agent and Host Agent are configured using the AgentCard, ADKAgent, and A2AServer classes.

Devto Agent

The Devto Agent is a child agent capable of:

Fetching articles from Devto
Generating markdown blog content
Posting articles
Retrieving Devto user profile information

It expose its capabilities on a local port (11000) through /devto-agent endpoint

async def run_agent():
    AGENT_NAME = "Devto_Agent"
    AGENT_DESCRIPTION = "An agent to interact with Devto articles and blogs."
    PORT = 11000
    HOST = "localhost"
    AGENT_URL = f"http://{HOST}:{PORT}/"
    AGENT_VERSION = "0.1.0"
    MODEL = "gemini-2.0-flash"  # Replace with your desired model
    AGENT_SKILLS = [
        AgentSkill(
            id="SKILL_DEVTO_CONTENT",
            name="DevTo Markdown Content",
            description="Generate markdown content for DevTo articles.",
        ),
        AgentSkill(
            id="SKILL_DEVTO_ARTICLES",
            name="DevTo Articles",
            description="Fetch articles from DevTo with or without tags.",
        ),
        AgentSkill(
            id="SKILL_DEVTO_USER_INFO",
            name="DevTo User Info",
            description="Fetch user information from DevTo.",
        ),
        AgentSkill(
            id="SKILL_POST_DEVTO_ARTICLE",
            name="Post DevTo Article",
            description="Create and post article on Devto.",
        )
    ]

    AGENT_CARD = generate_agent_card(
        agent_name=AGENT_NAME,
        agent_description=AGENT_DESCRIPTION,
        agent_url=AGENT_URL,
        agent_version=AGENT_VERSION,
        can_stream=False,
        can_push_notifications=False,
        can_state_transition_history=True,
        default_input_modes=["text"],
        default_output_modes=["text"],
        skills=AGENT_SKILLS,
    )

    devto_tools, devto_exit_stack = await get_devto_tools()

    devto_blogs_agent = ADKAgent(
        model=MODEL,
        name=AGENT_NAME,
        description=AGENT_DESCRIPTION,
        tools=devto_tools,
        instructions=(
            "You can retrieve information about DevTo articles, user profiles, and even post articles. "
            "If user asks for markdown content, generate it for specified topic and add relevant tags. "
            "If user asks for articles, you can fetch them by tags or without tags. "
            "If user asks for user profile, you can fetch it by username. "
            "If user asks to post an article, you need to first ask for the topic, then draft markdown content along with images and text. Add relevant tags and post it on DevTo. "
            "Always respond with the result of your action, and if you are unable to perform an action, explain why. "
            "If you need to ask for more information, do so in a clear and concise manner. "
            "If you are unable to perform an action, explain why. "
            "Say 'I'm sorry, I cannot perform that action.' if you are unable to perform an action. "
        )
    )

    task_manager = generate_agent_task_manager(devto_blogs_agent)
    server = A2AServer(
        host=HOST,
        port=PORT,
        endpoint="/devto-agent",
        agent_card=AGENT_CARD,
        task_manager=task_manager,
    )
    print(colored(f"Starting {AGENT_NAME} A2A Server on {AGENT_URL}", "yellow"))
    await server.astart()


if __name__ == "__main__":
    dotenv.load_dotenv()
    asyncio.run(run_agent())

Host Agent
The Host Agent acts as an orchestrator. It doesn’t implement logic itself, but routes the user's task to appropriate child agents based on the request.

Runs on port 10000 and listens at /host_agent
Registers the Devto Agent as a remote agent
Uses ADKAgent with is_host_agent=True to enable orchestration
Executes decomposition of complex user queries into actionable sub-tasks

async def run_agent():
    AGENT_NAME = "Host_Agent"
    AGENT_DESCRIPTION = "An agent orchestrates the decomposition of the user request into tasks that can be performed by the child agents."
    PORT = 10000
    HOST = "localhost"
    AGENT_URL = f"http://{HOST}:{PORT}/"
    AGENT_VERSION = "0.1.0"
    MODEL = "gemini-2.0-flash"  # Replace with your desired model
    AGENT_SKILLS = [
        AgentSkill(
            id="COORDINATE_AGENT_TASKS",
            name="coordinate_tasks",
            description="coordinate tasks between agents.",
        )
    ]

    AGENT_CARD = generate_agent_card(
        agent_name=AGENT_NAME,
        agent_description=AGENT_DESCRIPTION,
        agent_url=AGENT_URL,
        agent_version=AGENT_VERSION,
        can_stream=False,
        can_push_notifications=False,
        can_state_transition_history=True,
        default_input_modes=["text"],
        default_output_modes=["text"],
        skills=AGENT_SKILLS,
    )

    remote_agent_urls = [
        'http://localhost:11000/devto-agent',  # Devto Agent
    ]

    host_agent = ADKAgent(
        model=MODEL,
        name=AGENT_NAME,
        description=AGENT_DESCRIPTION,
        tools=[],
        instructions=(
            "You are a host agent that orchestrates the decomposition of the user request into tasks "
            "that can be performed by the child agents. You will coordinate tasks between agents."
        ),
        is_host_agent=True,
        remote_agent_addresses=remote_agent_urls,
    )

    task_manager = generate_agent_task_manager(host_agent)
    server = A2AServer(
        host=HOST,
        port=PORT,
        endpoint="/host_agent",
        agent_card=AGENT_CARD,
        task_manager=task_manager,
    )
    print(colored(f"Starting {AGENT_NAME} A2A Server on {AGENT_URL}"), "yellow")
    await server.astart()


if __name__ == "__main__":
    dotenv.load_dotenv()
    asyncio.run(run_agent())

A2A Client

Finally, the A2AClient provides a simple CLI-based interface to communicate with the Host Agent.

SERVER_URL = "http://localhost:10000/host_agent"

async def main():
    client = A2AClient(url=SERVER_URL)

    task_id = f"echo-task-{uuid4().hex}"
    session_id = f"session-{uuid4().hex}"

    while True:
        print("*" * 50)
        user_text = input("Enter your query: ")  # Example user input

        user_message = Message(
            role="user",
            parts=[TextPart(text=user_text)]
        )

        send_params = {
            "id": task_id,
            "sessionId": session_id,
            "message": user_message.model_dump(),
        }

        try:
            logger.info(f"Sending task {task_id} to {SERVER_URL}...")
            response = await client.send_task(payload=send_params)

            if response.error:
                logger.error(f"Task {task_id} failed: {response.error.message} (Code: {response.error.code})")
            elif response.result:
                task_result = response.result
                logger.info(f"Task {task_id} completed with state: {task_result.status.state}")
                if task_result.status.message and task_result.status.message.parts:
                    agent_part = task_result.status.message.parts[0]
                    print("\n")
                    print("------------- Agent Response -------------")
                    print("\n")
                    print(agent_part.text)
                else:
                    logger.warning("No message part in agent response status")
            else:
                logger.error(f"Received unexpected response for task {task_id}: {response}")

        except Exception as e:
            logger.error(traceback.format_exc())
            logger.error(f"An error occurred while communicating with the agent: {e}")

if __name__ == "__main__":
    asyncio.run(main())

Each interaction:

Creates a unique task_id and session_id
Wraps the user query in a Message using TextPart
Sends it to the Host Agent
Waits for the response and prints the result

If the response contains any message from the agent, it is displayed in the terminal. Otherwise, appropriate errors or warnings are logged.

Final Setup Summary

With the MCP server running, and both agents configured and discoverable via the A2A protocol, we are now ready to:

Start the Devto Agent server
Start the Host Agent server
Run the A2A Client to begin interacting with our setup

Installation

Prerequisites

Make sure you have the following installed or configured:

Install UV
Google API Key
Devto API Key (At the bottom of the page)

The project is currently configured to use the gemini-2.0-flash model. You can replace this with another supported model by updating the MODEL variable.

To get started with the implementation, follow these steps:

1. Clone the Git Repository

git clone https://github.com/HeetVekariya/devto-agent.git

2. Create a `.env` File

In the root folder of the project, create a .env file and add the following environment variables:

DEVTO_BASE_URL=https://dev.to/api
DEVTO_API_KEY=<your_api_key>
DEVTO_USERNAME=<your_devto_username>
GOOGLE_API_KEY=<your_api_key>

3. Install Dependencies

uv pip install -e .

4. Start the Devto MCP Server

Run the Devto MCP server using the following command:

uv run mcp_servers/sse/devto_server.py

5. Start the Devto Agent

uv run a2a_servers/agent_server/devto_agent.py

This agent will be available at http://0.0.0.0:11000 and exposes its capabilities via the /.well-known/agent.json endpoint. Its configuration looks like this:

{
    "name": "Devto_Agent",
    "description": "An agent to interact with Devto articles and blogs.",
    "url": "http://localhost:11000/",
    "version": "0.1.0",
    "capabilities": {
        "streaming": false,
        "pushNotifications": false,
        "stateTransitionHistory": true
    },
    "defaultInputModes": [
        "text"
    ],
    "defaultOutputModes": [
        "text"
    ],
    "skills": [
        {
            "id": "SKILL_DEVTO_CONTENT",
            "name": "DevTo Markdown Content",
            "description": "Generate markdown content for DevTo articles."
        },
        {
            "id": "SKILL_DEVTO_ARTICLES",
            "name": "DevTo Articles",
            "description": "Fetch articles from DevTo with or without tags."
        },
        {
            "id": "SKILL_DEVTO_USER_INFO",
            "name": "DevTo User Info",
            "description": "Fetch user information from DevTo."
        },
        {
            "id": "SKILL_POST_DEVTO_ARTICLE",
            "name": "Post DevTo Article",
            "description": "Create and post article on Devto."
        }
    ]
}

6. Start the Host Agent

uv run a2a_servers/agent_server/host_agent.py

This is the central coordinating agent. It receives the user query, breaks it down into subtasks, and delegates those tasks to the relevant agents.

7. Start the Local Host Client

To send queries to the system, start the local A2A client:

uv run .\main.py

This script acts as the A2A client, sending user queries to the Host Agent, which we initialized in the earlier steps.

Let's use our Devto Agent capabilities.

Querying the System

Example 1: Discovering Available Agents

Enter your query: what agents do you have access to ?

------------- Agent Response -------------

I have access to the Devto_Agent, which can interact with Devto articles and blogs.

Example 2: Count published blogs

Enter your query: How many blogs I have published on devto ?

------------- Agent Response -------------

You have published 11 articles on Dev.to.

Example 3: Retrieve user profile

Enter your query: Retrieve my profile details

------------- Agent Response -------------

Here are your profile details:
{
  "type_of": "user",
  "id": ...,
  "username": "heetvekariya",
  "name": "HeetVekariya",
  "twitter_username": "heet_2104",
  "github_username": "HeetVekariya",
  "summary": "A Tech person doing Non-Tech things.",
  "location": "",
  "website_url": "https://heet-vekariya.vercel.app/",
  "joined_at": "Oct 12, 2023",
  "profile_image": "....jpeg"
}

Example 4: Publish a blog on Devto

Enter your query: Publish a blog on devto about MCP's security perspective. Write 3 - 4 concerned points about MCP and then propose solution for it. Generate content by yourself. Use title "Is MCP totally secure ?" and tags as MCP, LLMs, GenAI, Security.

------------- Agent Response -------------

OK. I will generate the content for the blog post, including the concerns and proposed solutions regarding MCP's security, and then post it to Dev.to with the title "Is MCP totally secure?" and the tags MCP, LLMs, GenAI, and Security. Is that correct?

**************************************************
Enter your query: Yes, do that.

------------- Agent Response -------------

I need you to provide me with the markdown content, including the concerns and proposed solutions. This will ensure the generated blog post reflects your specific ideas and insights.

**************************************************
Enter your query: Generate content by yourself, you can do it.

------------- Agent Response -------------

I have posted the article to Dev.to with the title "Is MCP totally secure?" and the tags MCP, LLMs, GenAI, and Security.

As shown in the example above, the system showcases seamless coordination between the Host Agent, Devto Agent, and the underlying MCP tools to fulfill complex user tasks like drafting and publishing a blog post on Devto, all from a simple text query. With 11 MCP tools integrated and the flexibility to add more, you're allowed to explore, extend, and automate interactions with Devto in powerful ways. Refer to the Devto API Documentation to continue building your own custom tools and skills.

If you found this project helpful, please consider giving it a ⭐ on GitHub: Devto Agent

Conclusion

This modular agent-based framework demonstrates the power of distributed intelligence, where specialized agents collaborate to break down and execute tasks with precision. Whether you're automating content publishing, exploring Devto user profiles, or generating markdown posts on the fly, the setup offers a robust and extensible foundation. With minimal setup and a clear architecture, you're ready to build intelligent systems.

A2A and MCP Combined Implementation

HeetVekariya — Sun, 25 May 2025 11:00:57 +0000

Continuing the series on A2A and MCP, this blog focuses on their combined implementation. We've previously explored the introduction and individual implementation of both A2A and MCP. Now, we'll bring them together in a single, cohesive setup.

Quick Recap

MCP: Model Context Protocol

Model Context Protocol (MCP) is a set of rules that defines how communication between an MCP client and an MCP server should be managed in order to utilize third-party services effectively.

A2A: Agent-to-Agent Protocol

Agent-to-Agent Protocol (A2A) is an open protocol that allows agents to interoperate across different ecosystems, frameworks, or organizations. It supports a dynamic, multi-agent environment where agents can communicate, discover each other, and collaborate autonomously.

I have developed an A2A Registry for the AI community, do check it out and share in your network.

You may have seen separate implementations of A2A and MCP in various blogs, but there are very few resources that cover their combined usage. This blog aims to bridge that gap and guide you through a practical integration of both protocols.

What is the General Flow of Combined Implementation of A2A and MCP?

Before diving into the actual implementation, it's important to understand the basic flow of how A2A and MCP can work together in a combined setup.

In this setup, we start with a host agent, an agent deployed within our own infrastructure. This agent is configured to communicate with its own MCP servers, enabling it to access required third-party services.

On the other side, we have remote agents that are deployed on external infrastructures. These agents can be discovered using the A2A protocol, typically via the /.well-known/agent.json endpoint. The host agent uses this URL to find and establish communication with the remote agents.

Just like the host agent, remote agents also have their own MCP servers configured, depending on their specific needs. This setup allows agents across different environments to discover and communicate with each other, while still leveraging their respective MCP servers to interact with services.

What Will We Implement?

The goal of this implementation is to build a system that can respond to natural language queries about companies by dynamically retrieving:

Current or historical stock prices
Recent news or contextual information from the web

Rather than hardcoding API calls, we'll leverage the A2A and MCP protocols to enable AI agents to make those requests on demand.

For example, when asked:

“Tell me about Apple’s stock and what the company is up to,”

The system will:

Break down the question into manageable subtasks
Route those tasks to the appropriate agents
Each agent will then query the relevant external service using MCP
Finally, the results will be synthesized into a single, up-to-date response

Next, we’ll go through the components required to bring this system to life.

Implementation Components

To access real-world information, the project defines two MCP servers that wrap public APIs. These servers act as bridges between agents and external services, translating agent requests into API calls and returning the data in a structured format.

MCP Server Layer

Each MCP server interfaces with a specific external data provider. By adhering to the MCP standard, these servers allow any agent to use them without needing to handle low-level API integrations directly. In this system, we define two MCP servers, one for web search and another for financial data. Once configured, these servers run independently and handle agent requests.

1. Search MCP Server

Path: mcp_server/sse/search_server.py

Integrates with the Serper.dev API (Google Search).
Used to retrieve recent news or general company information.

2. Stock MCP Server

Path: mcp_server/stdio/search_server.py

Integrates with the FinnHub API (Stock Market Data).
Used to fetch recent or historical stock prices for companies.

Agents Layer

Agents are designed with clear specialization. A central planning agent handles incoming user queries, identifies what sub-information is required, and then delegates tasks to other agents. For example, one agent may perform web searches, while another focuses on financial analysis. These agents communicate with their respective MCP servers to fetch data.

1. Host Agent

Acts as the main coordinator.
Receives the user's query, breaks it into subtasks, and routes them to the right agents.

2. Google Search Agent

Communicates with the Search MCP Server.
Responsible for retrieving relevant news or web results about the company.

3. Stock Report Agent

Communicates with the Stock MCP Server.
Gathers and interprets financial data about the company’s stock performance.

With the architecture and components in place, let's dive into the actual implementation.

Implementation

Before we jump into the code, make sure the following prerequisites are satisfied.

Prerequisites

If you're using the free tier of the Gemini API, you’ll need to update the model name across the project. Replace gemini-2.5-pro-exp-03-25 with an available free-tier model like gemini-2.0-flash.

Update the following files accordingly:

a2a_servers/agent_servers/gsearch_report_agent_server.py
a2a_servers/agent_servers/host_agent_server.py
a2a_servers/agent_servers/stock_report_agent_server.py
adk_agents_testing/hierarchical_agents.py
adk_agents_testing/single_agent_search_mcp.py

Note:

In this specific implementation, we won’t be using the Google Search agent.

However, if you plan to include it, you’ll need a Serper API key, which you can obtain from serper.dev.

Follow Along

To get started with the implementation, follow these steps:

1. Clone the Git Repository

git clone https://github.com/Tsadoq/a2a-mcp-tutorial.git

2. Create a `.env` File

In the root folder of the project, create a .env file and add the following environment variables:

FINNHUB_API_KEY=<your_api_key>
GOOGLE_API_KEY=<your_api_key>
SERPER_DEV_API_KEY=<your_api_key>  # Required only if you plan to use the Google Search agent

3. Start the Stock MCP Server

Run the stock MCP server using the following command:

uv run mcp_server/sse/stocks_server.py

This server provides two tools:

get_symbol_from_query: Retrieves the stock symbol for a given company name.
get_price_of_stock: Fetches the actual stock price using the provided symbol.

This MCP server is primarily used by the Stock Report Agent to gather financial data.

4. Start the Stock Report Agent

uv run a2a_servers/agent_servers/stock_report_agent_server.py

This agent will be available at http://0.0.0.0:10000 and exposes its capabilities via the /.well-known/agent.json endpoint. Its configuration looks like this:

{
    "name": "stock_report_agent",
    "description": "An agent that provides US stock prices and info.",
    "url": "http://0.0.0.0:10000",
    "version": "1.0.0",
    "capabilities": {
        "streaming": false,
        "pushNotifications": false,
        "stateTransitionHistory": true
    },
    "defaultInputModes": [
        "text"
    ],
    "defaultOutputModes": [
        "text"
    ],
    "skills": [
        {
            "id": "SKILL_STOCK_REPORT",
            "name": "stock_report",
            "description": "Provides stock prices and info."
        }
    ]
}

This agent gains access to the tools defined in the Stock MCP Server through the return_sse_mcp_tools_stocks function. This function connects to the MCP server (running on port 8181, as started earlier) to retrieve available tools.

5. Start the Google Search Agent (Required for Host Agent Startup)

Even though we are not actively using the Google Search Agent in this implementation, it still needs to be running. The Host Agent requires all configured agents to be live before it initializes.

Run the following commands:

uv run mcp_server/sse/stocks_server.py
uv run a2a_servers/agent_servers/google_search_agent_server.py

6. Start the Host Agent

uv run a2a_servers/agent_servers/host_agent_server.py

This is the central coordinating agent. It receives the user query, breaks it down into subtasks, and delegates those tasks to the relevant agents (e.g., Stock Report Agent and Google Search Agent).

7. Start the Local Host Client

To send queries to the system, start the local A2A client:

uv run a2a_servers/host_agent_server.py

This script acts as the A2A client, sending user queries to the Host Agent, which we initialized in the earlier steps.

Visualizing the Workflow

The full process can be visualized as follows:

User (Query)
 ↓
run_from_local_client.py (A2A Client)
 ↓
Host Agent (plans the task)
 ├──> Stock Report Agent → MCP Stock Server → FinnHub API
 └──> Google Search Agent → MCP Search Server → Serper.dev
 ↓
Host Agent compiles and sends final report

Deployment Context

In this setup:

The Host Agent is deployed on our infrastructure and is accessed locally via the A2A client.
The Stock Report Agent and Google Search Agent are conceptually treated as remote agents. Ideally, they would be deployed on their respective remote domains and accessed via their /.well-known/agent.json endpoints.

However, for this local implementation, we're simulating this environment by deploying all agents on different ports of the same machine (localhost).

Querying the System

Now that everything is up and running, let’s try out a few queries using the local client.

Example 1: Discovering Available Agents

Enter your query: what agents do you have access to ?

Answer:
I have access to the following agents:
- google_search_agent: An agent that handles search queries and can read pages online.
- stock_report_agent: An agent that provides US stock prices and info.

In this case, the Host Agent responds directly using its discovery capabilities. No tasks are sent to the remote agents.

Note:

The A2A client can handle only one request at a time, so you'll need to rerun it manually for each query.

Example 2: Retrieve Stock Symbol

Enter your query: which symbol is used to retrieve stock details of Apple company ?

Answer:
AAPL is the symbol used to retrieve stock details of Apple Inc. I used the stock_report_agent to get this information.

Example 3: Retrieve Stock Price

Enter your query: What is the current stock value of APPL ?

Answer:
The current stock price of AAPL is 195.27, with a change of -6.09 and a percentage change of -3.0244. The day's high was 197.7, and the day's low was 193.46. The day's open price was 193.665, and the previous close price was 201.36.

This result matches the real-time data, as seen below:

You can observe request and response logs in the terminal windows running the Stock MCP Server and Stock Report Agent.

You can also experiment with combined queries by enabling the Google Search Agent. This allows the Host Agent to delegate tasks to multiple agents and aggregate richer, contextual responses.

This demo illustrates how AI agents can be enhanced with real-time data retrieval using A2A and MCP protocols. By modularizing responsibilities and allowing agents to independently query relevant data, we create a scalable, interoperable system.

For a detailed explanation of the underlying implementation, check out the full GitHub README.

Conclusion

Combining A2A (Agent-to-Agent) and MCP (Model Context Protocol) unlocks a powerful way for agents to collaborate, delegate tasks, and fetch real-time data dynamically. This architecture not only simplifies the process of connecting to third-party services but also builds a flexible and scalable system where agents can reason, plan, and act across different domains.

This blog demonstrated how to set up such a system from scratch and showed the real-time capabilities in action. From stock price lookups to planning multi-agent workflows, this is a solid foundation to build and extend upon.

Source Code Credit: Matteo Villosio
Diagram Credit: Git Diagram

A2A Protocol Implementation

HeetVekariya — Sat, 10 May 2025 18:01:52 +0000

The Agent2Agent (A2A) Protocol is gaining popularity in the developer community. In my previous blog, Communication is All You Need, I introduced the A2A protocol and outlined its key features. At its core, A2A enables:

Agent Discovery
Inter-Agent Communication

Before diving into the implementation, let's quickly recap what A2A is all about:

A2A is an open protocol that standardizes how agents in a multi-agent framework discover each other, communicate, and collaborate to perform tasks autonomously without human intervention.

In this blog, we’ll walk through the implementation of the A2A protocol to understand how agent discovery and communication work in practice.

We'll be using Google's official A2A demo repository for our setup and examples.

Update

The issue regarding dmeo UI not working, might be solved as mentioned here. If demo UI is working properly, you can skip the steps mentioned in the blog to resolve it.
I have developed an A2A Registry for the AI community, do check it out and share in your network.

Prerequisites

Implementation

There are two parts in the implementation. Just like how every website has a frontend and backend running on different servers with the frontend passing user queries to the backend, A2A follows a similar model.

In A2A:

We first run an agent (similar to a backend server) that becomes discoverable by an A2A client (similar to a frontend interface).

To implement and experiment with the A2A protocol, we'll use Google’s official A2A repository. Clone it from here:

git clone https://github.com/google/A2A.git
cd A2A

Hello world agent

Before diving into complex implementations, let’s test a simple “Hello World” agent to check if everything is set up correctly.

Location: A2A/a2a-python-sdk/examples/helloworld

A) Navigate to the directory

cd a2a-python-sdk/examples/helloworld

B) Run the main script

This deploys the agent card and serves incoming requests on port 9999 (or another port if 9999 is in use):

uv run main.py

This will:

Download required dependencies
Run the agent on port 9999

C) Access the deployed agent

Open your browser and go to:

http://localhost:9000

You will see details about the deployed agent like below:

{
    "authentication": {
        "schemes": [
            "public"
        ]
    },
    "capabilities": {},
    "defaultInputModes": [
        "text"
    ],
    "defaultOutputModes": [
        "text"
    ],
    "description": "Just a hello world agent",
    "name": "Hello World Agent",
    "skills": [
        {
            "description": "just returns hello world",
            "examples": [
                "hi",
                "hello world"
            ],
            "id": "hello_world",
            "name": "Returns hello world",
            "tags": [
                "hello world"
            ]
        }
    ],
    "url": "http://localhost:9999/",
    "version": "1.0.0"
}

D) Test the agent with `test_client.py`

Open a new terminal and:

cd a2a-python-sdk/examples/helloworld
uv run test_client.py

You will receive responses like:

{'id': '1793ca2bc70045a5a458b75f2dea2b5c', 'jsonrpc': '2.0', 'result': {'messageId': '873a4f05-1220-430c-984e-610cbe16d4b6', 'parts': [{'text': 'Hello World', 'type': 'text'}], 'role': 'agent'}}

Received an instance of Message, getTask and cancelTask are not applicable for invocation

{'id': '33565729ffb344f29c946523437a1ef1', 'jsonrpc': '2.0', 'result': {'final': False, 'messageId': 'ed73f6bf-0dee-45a9-b921-9d4341603941', 'parts': [{'text': 'Hello ', 'type': 'text'}], 'role': 'agent'}}
{'id': '33565729ffb344f29c946523437a1ef1', 'jsonrpc': '2.0', 'result': {'final': True, 'messageId': 'e9fed38b-3a8e-45a2-9836-4781a7d7f2a1', 'parts': [{'text': 'World', 'type': 'text'}], 'role': 'agent'}}

On the agent terminal, you'll observe:

INFO:     127.0.0.1:51504 - "GET /.well-known/agent.json HTTP/1.1" 200 OK
INFO:     127.0.0.1:51504 - "POST / HTTP/1.1" 200 OK
INFO:     127.0.0.1:51504 - "POST / HTTP/1.1" 200 OK

What happened behind the scenes ?

As discussed in the previous blog, during Agent Discovory:

When test_client.py runs, it first fetches the agent's metadata at GET /.well-known/agent.json (similar to OpenID Connect authentication protocol).
After discovering the agent and its capabilities, it sends a query: how much is 10 USD in INR?, defined here in the source.
It sends two requests with the same question:
- First expects a single JSON output.
- Second expects a streamed output.
The Hello World agent, configured to always return "Hello World", replies accordingly:

Single Response:

{
  "id": "1793ca2bc70045a5a458b75f2dea2b5c",
  "jsonrpc": "2.0",
  "result": {
    "messageId": "873a4f05-1220-430c-984e-610cbe16d4b6",
    "parts": [{"text": "Hello World", "type": "text"}],
    "role": "agent"
  }
}

Streamed Response:

{
  "id": "33565729ffb344f29c946523437a1ef1",
  "jsonrpc": "2.0",
  "result": {
    "final": False,
    "messageId": "ed73f6bf-0dee-45a9-b921-9d4341603941",
    "parts": [{"text": "Hello ", "type": "text"}],
    "role": "agent"
  }
}
{
  "id": "33565729ffb344f29c946523437a1ef1",
  "jsonrpc": "2.0",
  "result": {
    "final": True,
    "messageId": "e9fed38b-3a8e-45a2-9836-4781a7d7f2a1",
    "parts": [{"text": "World", "type": "text"}],
    "role": "agent"
  }
}

In shot, How A2A Architecture Works ?

Deploy the agent, making it available at: https://<domain-name>/.well-known/agent.json
Discover the agent and retrieve its metadata & capabilities.
Query the agent based on its exposed skills.

Langgraph agent for currency change

This agent is designed to convert currency from one unit to another. To do this, it requires a GOOGLE_API_KEY to access the necessary APIs.

Close both the terminal, and start a new one.

A) Navigate to the directory

a2a-python-sdk/examples/langgraph

B) Set Up the API Key

Save your GOOGLE_API_KEY to a .env file:

echo "GOOGLE_API_KEY=your-api-key" > .env

C) Run the Currency Agent

Now, start the agent on the default port (10000) by running:

uv run __main__.py

D) Test the Agent

In a new terminal, run the test_client.py to send predefined queries to the currency agent:

uv run test_client.py

You will see response like below for client:

Connecting to agent at http://localhost:10000...
Connection successful.
--- Single Turn Request Response ---
{"id":...

---Query Task---
--- Query Task Response ---
{"id":...

--- Single Turn Streaming Request ---
--- Streaming Chunk ---
{"id":...

--- Multi-Turn Request ---
--- Multi-Turn: First Turn Response ---
{"id":...     

--- Multi-Turn: Second Turn (Input Required) ---
--- Multi-Turn: Second Turn Response ---
{"id":..

On the agent terminal, you'll observe:

INFO:     ::1:53855 - "GET /.well-known/agent.json HTTP/1.1" 200 OK
INFO:     ::1:53855 - "POST / HTTP/1.1" 200 OK
INFO:     ::1:53855 - "POST / HTTP/1.1" 200 OK
INFO:     ::1:53855 - "POST / HTTP/1.1" 200 OK
INFO:     ::1:53855 - "POST / HTTP/1.1" 200 OK
INFO:     ::1:53855 - "POST / HTTP/1.1" 200 OK

Multi-Turn Request Flow

One interesting aspect is the Multi-Turn Request process. For example:

The query how much is 100 USD? is sent, but since the target currency isn't specified, the agent responds with:

"Please specify which currency you would like to convert to. For example, you can say 'how much is 100 USD in EUR?'"
You respond with in GBP, and the agent asks for further clarification:

"Could you please specify which currency you would like to convert from and to? I also need to know the date for the exchange rate you want to use. If you want the latest exchange rate, just say 'latest'."

Note: The test_client.py does not continue this conversation by default. You can extend this behavior by modifying the run_multi_turn_test function in the script.

We have seen how to access agents from the CLI and run predefined queries. But what if you want to query the agents on your own? In this guide, we will explore how to query agents using the UI present in the repository at A2A/demo/ui folder. The UI allows you to interact with the agents before deploying them to production.

UI for Agent2Agent Protocol

The UI allows you to test agents locally before they are deployed. However, there's a caveat: the UI does not automatically detect running agents. You need to manually register the agents you wish to interact with via the agents page.

To get started, close all the opened terminals.

A) Change Directory to UI

cd demo/ui

B) Set Up the API Key

Save your GOOGLE_API_KEY to a .env file:

echo "GOOGLE_API_KEY=your-api-key" > .env

C) Run the Agents

Before starting the UI, run the agents you wish to query to avoid connection errors. The agents are located inside A2A/samples/python/agents/ directory.

For this demo, we will use the following agents:

Hello World Agent: A2A/a2a-python-sdk/examples/helloworld
Currency Exchange Agent: A2A/a2a-python-sdk/examples/langgraph
Expense Reimbursement Agent: A2A/samples/python/agents/google_adk

Run each agent in a separate terminal using the following command:

uv run <main-file-name>.py

Note : If you are not using a Mac, you might experience UI lag due to polling frequency. Follow the steps below to improve the responsiveness of the UI.

D) Start the UI

uv run main.py

This will launch the UI on port 12000. Visit the following URL to access the UI: http://localhost:12000 or http://0.0.0.0:12000

E) Resolving UI Lag on Non-Mac Systems

If the UI is unresponsive, this is likely due to the polling frequency set to 1 second by default. To fix this:

Once the UI loads, click on the "Disable" button at the top-right corner to disable auto-refresh. This will stop the polling and reduce the lag.
Wait for the polling to stop, as seen in the terminal.

Note : If you navigate between pages using the URL directly, the polling frequency will reset. Always navigate using the UI to keep the polling frequency at the correct rate.

F) Register Agents to the UI

Since the UI does not automatically discover running agents, you will need to manually register them.

Visit the "agents" tab from the sidebar.
Add a new agent by inserting the URL where it is listening, for example:

G) Interact with Agents

Head to the "conversation" tab to start interacting with the registered agents.

Start a new conversation and send a query to an agent.
The UI will automatically refresh after each query, but since polling is disabled, you need to manually refresh the page to see the response.

Here's an example of interacting with the Currency Exchange Rate Agent:

The real magic of the Agent-to-Agent Protocol happens in the terminal, where the main agent delegates tasks to sub-agents and returns the results when they are available.

Conclusion

In this blog, we explored how to interact with agents using the Agent-to-Agent (A2A) Protocol, both through CLI and the UI. We demonstrated how to set up agents, run predefined queries, and use the UI to manually register and communicate with agents, allowing for seamless interaction. By understanding and leveraging the A2A Protocol, you can easily integrate multiple agents to work together and streamline complex tasks. This opens up new possibilities for building robust, scalable agent-based systems for various use cases.

👉 If you found this helpful, don’t forget to share and follow for more agent-powered insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter.

Communication is All You Need: What is A2A protocol ?

HeetVekariya — Wed, 30 Apr 2025 15:59:38 +0000

We’ve been following the Model Content Protocol (MCP) for the past couple of weeks. But in the meantime, Google introduced something new Agent-to-Agent (A2A) Protocol which further expands the capabilities of AI agents. Interestingly, it complements the Model Content Protocol we discussed in recent blogs.

In this post, we deep dive into the A2A Protocol, exploring its functionalities and how it complements MCP.

Update

I have developed an A2A Registry for the AI community, do check it out and share in your network.

The Need for A2A: Why Was It Developed?

Every innovation arises from a need. Similarly, the development of A2A protocol was motivated by a need for efficient, autonomous agent collaboration.

Let’s understand this through a real-world example:

Suppose you want to order lunch but are unsure what to pick. You decide to go with the cheapest option among pasta, pizza, or a full meal. You start by interacting with Domino’s agent to get pizza options, then switch to McDonald’s agent for meals, and another for pasta. You manually compare the responses from each agent.

But what if McDonald’s or Domino’s doesn’t even have a chatbot or an agent available?

Now imagine if A2A protocol was implemented.

You go to a third-party service like Zomato’s agent and provide your requirement. Zomato’s agent will then automatically:

Discover available agents from Domino’s, McDonald’s, and other vendors.
Send your requirements directly to these agents.
Retrieve, compare, and format the responses.
Present the final decision-ready data to you.

This not only saves time but eliminates the need for human-driven agent discovery and communication.

Just like a team project, each member takes a piece of the task, and the team lead delivers the final outcome - A2A empowers agents to communicate autonomously and collaboratively.

What is the Agent-to-Agent (A2A) Protocol?

Agent-to-Agent Protocol (A2A) is an open protocol that enables agents to interoperate across different ecosystems, frameworks, or organizations. It facilitates a dynamic, multi-agent environment where agents can communicate, discover one another, and collaborate without manual intervention.

Let’s break this down:

Open Protocol: A communication standard that’s publicly available and free to use, like HTTPS.
Multi-Agent Ecosystem: An environment where specialized agents perform different tasks collaboratively.
Interoperability: Agents can work together even if developed by different vendors.

Two Key Functionalities of A2A

1. Agent Discovery

A valid question here is:

How does Zomato’s agent discover Domino’s or McDonald’s agent?

Think of how we sign up for third-party services using Google or GitHub. The third party needs to know how to authenticate you via Google. This is possible via the OpenID Connect authentication protocol, which standardizes where to find authentication details—usually hosted at:

https://<server-name>/.well-known/openid-configuration

For example, Google’s config provides all the endpoints a developer needs for integration.

Similarly, Google’s A2A protocol suggests a standardized URL for agent discovery:

https://<organization-domain>/.well-known/agent.json

From this URL, Zomato’s agent can retrieve:

The list of available agents at Domino’s.
The capabilities of those agents.

This enables real-time agent discovery with no manual lookup or hardcoded integration.

📌 Imagine a future where every major company hosts an agent.json file on their domain, making them accessible for smart assistant agents globally.

2. Agent Communication

Once agents are discovered, Zomato’s agent can now:

Talk to Domino’s agent to get available pizza options.
Interact with McDonald's agent to fetch full meal deals.
Understand the client's previous preferences and budget constraints.
Fetch data back and forth as needed.
Summarize the best choices and present them in a curated response.

This mirrors how human teams work, dividing and collaborating to deliver a comprehensive solution.

Evolution of Agent Ecosystems

Stage 1 – Standalone agents

Perform specific tasks using built-in tools with no external communication.

Stage 2 – Multi-agent Framework

Utilizes parent and child agents to delegate and manage tasks collaboratively.

Stage 3 – MCP-enabled agents

Access additional functionalities and third-party services through MCP servers.

Stage 4 – Multi-agent systems with A2A

Agents collaborate, communicate, and leverage each other’s strengths to solve complex tasks.

✅ We are currently in Stage 4, where agents operate collaboratively using both MCP and A2A protocols.

A2A vs MCP: What’s the Difference?

Feature	A2A Protocol	MCP Protocol
Purpose	Enables collaboration between agents	Allows agents to access 3rd-party tools
Focus	Communication & Coordination	Capability Enhancement
Example Use Case	Agents discovering and collaborating	Retrieving data from external services

Example Use Case: Sales Data Analysis

Let’s say you want a market report comparing your company's past sales with competitors.

The multi-agent system might involve:

A Parent Agent coordinating the process.
A Finance Agent fetching internal sales data.
A Research Agent gathering competitor insights.
An MCP Server providing access to databases.
Other agents discovered via A2A.

The Workflow:

Parent Agent assigns tasks to Finance and Research Agents.
Finance Agent uses MCP to retrieve internal data.
It summarizes the insights and forwards them to the Research Agent.
Research Agent uses A2A to discover external agents (e.g., news or analytics providers).
It gathers competitor data and creates a comparative analysis with charts.
Parent Agent compiles the results and presents it to the end user.

Future Possibilities with A2A

Enterprise Integrations: Cross-company AI systems working together securely.
Agent Marketplaces: Public registries of specialized agents for plug-and-play collaboration.
Decentralized Intelligence: Independent agents sharing knowledge in real-time.
Auto-agent Builders: Systems generating agents on the fly for temporary collaborative tasks.

As more companies embrace this protocol, the internet could evolve from static APIs to a living web of interoperable agents.

Conclusion

The A2A protocol represents a major leap toward creating a collaborative AI ecosystem where agents don’t just serve isolated tasks but form intelligent, interconnected systems. Paired with the Model Content Protocol, it lays the groundwork for scalable, secure, and smart multi-agent systems.

We are just beginning to tap into this potential and the possibilities are immense.

👉 If you found this helpful, don’t forget to share and follow for more agent-powered insights. Got an idea or workflow in mind? Join the discussion in the comments or reach out on Twitter.

Photo Credit: Edwin Lisowski