DEV Community: Kasi Yaswanth

Day 23/30: Expose Tools with MCP

Kasi Yaswanth — Sun, 02 Aug 2026 05:47:08 +0000

I still remember the frustration when our team's support bot, powered by LangGraph and MCP, couldn't retain context between user interactions. It was as if the bot had a case of conversational amnesia, forcing users to repeat themselves over and over. We later discovered that the issue stemmed from our lack of a centralized tooling server, making it impossible for the bot to access and leverage external tools in a scalable manner. This experience taught us the importance of building a robust MCP server to expose tools to our AI applications.

In this post, we'll walk through the process of setting up an MCP server, focusing on exposing a single tool to any MCP-compatible AI app. Let's consider a simple tool that performs sentiment analysis on text input. We want this tool to be accessible from our support bot, allowing it to gauge user sentiment and respond accordingly.

The first step in building an MCP server is to define the tool and its interface. MCP provides a set of APIs and protocols for tool definition, including the Tool class and the MCPTool interface. We'll use these to create our sentiment analysis tool. Here's a simplified example of how we might define this tool in Python:

from MCP import Tool, MCPTool

class SentimentAnalysisTool(Tool, MCPTool):
    def __init__(self):
        super().__init__()
        self.name = "SentimentAnalysis"
        self.description = "Analyzes the sentiment of the input text"

    def execute(self, input_text):
        # Simplified sentiment analysis logic for demonstration
        if "love" in input_text or "great" in input_text:
            return "Positive"
        elif "hate" in input_text or "bad" in input_text:
            return "Negative"
        else:
            return "Neutral"

# Create an instance of our tool
sentiment_tool = SentimentAnalysisTool()

Next, we need to set up an MCP server to host our tool. MCP servers can be configured to expose tools over various interfaces, including REST and gRPC. For simplicity, let's use a basic REST server. We'll use Flask, a lightweight Python web framework, to create our server. Here's how we might set it up:

from flask import Flask, request, jsonify
from MCP import ToolServer

app = Flask(__name__)

# Create an MCP tool server
tool_server = ToolServer()

# Register our sentiment analysis tool with the server
tool_server.register_tool(sentiment_tool)

# Define a route for tool execution
@app.route('/tools/<tool_name>/execute', methods=['POST'])
def execute_tool(tool_name):
    tool = tool_server.get_tool(tool_name)
    if tool:
        input_text = request.json['input_text']
        result = tool.execute(input_text)
        return jsonify({'result': result})
    else:
        return jsonify({'error': 'Tool not found'}), 404

if __name__ == '__main__':
    app.run(debug=True)

With our MCP server up and running, our support bot (or any other MCP-compatible AI app) can now access the sentiment analysis tool by sending a POST request to the /tools/SentimentAnalysis/execute endpoint with the text to be analyzed in the request body.

A practical gotcha to watch out for when building MCP servers is ensuring that tool registration and server configuration are properly synchronized. If tools are registered after the server has started, they might not be accessible until the server is restarted. To avoid this, consider implementing a dynamic tool registration mechanism that updates the server's tool list in real-time.

As we move forward in our agentic AI journey, tomorrow we'll explore more advanced topics in integrating LangGraph and MCP, further enhancing our AI applications' capabilities.

Day 22/30: Solving MxN Integration

Kasi Yaswanth — Sat, 01 Aug 2026 05:45:55 +0000

Imagine you're building a support bot that integrates with multiple third-party APIs to provide a seamless user experience. Your bot needs to fetch user data from one API, order history from another, and shipping information from a third. Each API has its own authentication mechanism, data formats, and rate limits. As you're integrating these APIs, you start to realize that the number of possible interactions between them is exploding. You have 3 APIs to integrate, each with 5 endpoints, and you need to handle errors, retries, and caching for each combination. This is the MxN integration problem, where the complexity of integrating multiple APIs grows exponentially with the number of APIs and endpoints.

To solve this problem, you can use the Model Context Protocol (MCP), which provides a standardized way of integrating multiple APIs and models. MCP allows you to define a graph of interactions between APIs, handle errors and retries, and manage caching and authentication. Let's take a concrete example of wrapping the GitHub API using MCP. We'll create a simple bot that fetches a user's repositories and handles authentication and rate limiting.

import langgraph
from langgraph import StateGraph
from mcp import Tool, Resource, Prompt

# Define the GitHub API tool
github_tool = Tool(
    name="github",
    url="https://api.github.com",
    auth=Resource("github_token", "token")
)

# Define the repositories endpoint
repos_endpoint = github_tool.endpoint(
    name="repos",
    url="/users/{username}/repos",
    method="GET",
    params={"username": "langgraph"},
    headers={"Accept": "application/json"}
)

# Define the state graph
graph = StateGraph()

# Add nodes for the API call and the response handling
graph.add_node("call_github", lambda: repos_endpoint.call())
graph.add_node("handle_response", lambda response: response.json())

# Add conditional edges to handle rate limiting and errors
graph.add_conditional_edges(
    "call_github",
    [
        ("rate_limited", lambda response: response.status_code == 429),
        ("error", lambda response: response.status_code >= 500)
    ]
)

# Define the checkpointers to handle caching and retries
graph.add_checkpoint("repos_cache", lambda response: response.json())

# Define the prompt to trigger the API call
prompt = Prompt(
    text="Get my GitHub repositories",
    intent="get_repos",
    entities={"username": "langgraph"}
)

# Run the graph
graph.run(prompt)

In this example, we've defined a simple state graph that integrates with the GitHub API to fetch a user's repositories. We've handled authentication, rate limiting, and caching using MCP's tools and resources. This is just a small taste of what MCP can do to solve the MxN integration problem.

One practical gotcha to watch out for when using MCP is to make sure you're handling errors and exceptions properly. MCP provides a robust error handling mechanism, but it's easy to overlook error handling when defining your state graph. Make sure to add conditional edges to handle errors and exceptions, and define checkpointers to handle caching and retries.

As we continue to build agentic AI systems with LangGraph and MCP, we'll explore more advanced topics, such as integrating multiple models and handling complex user interactions. Tomorrow, we'll dive deeper into the world of agentic AI and explore new ways to build intelligent systems that can interact with humans and other agents in a seamless and natural way.

Day 21/30: Avoiding Agent Loops

Kasi Yaswanth — Fri, 31 Jul 2026 05:56:32 +0000

I still remember the day our support bot, which was supposed to be a showcase of agentic AI in action, started acting like it was stuck in some kind of bizarre loop. Customers would ask a question, and instead of providing a helpful response, the bot would just repeat the same canned phrases over and over, never actually addressing the issue at hand. It was as if the bot had gotten stuck in a never-ending conversation with itself, unable to escape the cycle of meaningless chatter.

After digging into the logs, we discovered the root cause: our bot was designed as a multi-agent system, with different agents responsible for handling different aspects of the conversation. The problem arose when these agents started talking to each other in a way that created a kind of feedback loop. Agent A would ask Agent B a question, which would prompt Agent B to ask Agent C, which would then ask Agent A, and so on. Before long, the whole system was bogged down in a sea of circular conversations, with no clear way to break the cycle.

We realized that we needed to implement some kind of guardrail to prevent this kind of behavior. That's where LangGraph and the Model Context Protocol (MCP) came in. By using these tools, we could create a more structured and intentional conversation flow between our agents. Specifically, we used the StateGraph API from LangGraph to define the possible states of our conversation, and the add_conditional_edges method to specify the conditions under which an agent could transition from one state to another.

Here's a simplified example of how we might implement this using Python:

import langgraph as lg

# Define the possible states of our conversation
states = ['initial', 'question_asked', 'response_received', 'followup_asked']

# Create a StateGraph to manage the conversation flow
graph = lg.StateGraph(states)

# Define the conditions for transitioning between states
graph.add_conditional_edges([
    ('initial', 'question_asked', lambda context: context['user_input'] is not None),
    ('question_asked', 'response_received', lambda context: context['agent_response'] is not None),
    ('response_received', 'followup_asked', lambda context: context['user_followup'] is not None)
])

# Define the actions to take in each state
def ask_question(context):
    # Code to ask the user a question goes here
    pass

def provide_response(context):
    # Code to provide a response to the user goes here
    pass

def ask_followup(context):
    # Code to ask a followup question goes here
    pass

# Create a dictionary to store the actions for each state
actions = {
    'initial': ask_question,
    'question_asked': provide_response,
    'response_received': ask_followup
}

# Use the StateGraph to manage the conversation flow
def conversation_manager(context):
    current_state = graph.get_current_state(context)
    action = actions[current_state]
    action(context)

# Test the conversation manager
context = {'user_input': 'Hello'}
conversation_manager(context)

In this example, we define a StateGraph with four possible states: initial, question_asked, response_received, and followup_asked. We then use the add_conditional_edges method to specify the conditions under which the conversation can transition from one state to another. Finally, we define a dictionary of actions to take in each state, and use the StateGraph to manage the conversation flow.

One practical gotcha we learned from this experience is the importance of carefully defining the conditions for transitioning between states. If these conditions are too broad or too narrow, the conversation flow can become stuck or start to loop indefinitely. By taking the time to carefully consider the possible states and transitions of our conversation, we can avoid the kind of multi-agent groupchat spiral that plagued our support bot.

As we continue to build out our agentic AI system, we're excited to explore new ways to use LangGraph and MCP to create more sophisticated and intentional conversation flows. Tomorrow, we'll be diving into another key challenge in building agentic AI systems, one that requires us to think carefully about the relationships between our agents and the world around them.

Day 20/30: Agents in Disagreement

Kasi Yaswanth — Thu, 30 Jul 2026 05:31:20 +0000

I recently worked on a project where two independent agents, AgentA and AgentB, were tasked with generating and reviewing product descriptions. The goal was for AgentA to produce an initial description, and then AgentB would review and critique it, providing feedback that AgentA could use to improve its output. However, I quickly realized that the agents often disagreed on what constituted a "good" description, leading to an infinite loop of revisions with no clear resolution.

The issue arose because each agent had its own understanding of the product and its target audience, shaped by their respective training data and objectives. AgentA focused on highlighting the product's technical features, while AgentB emphasized its benefits and user experience. As a result, AgentB would consistently point out that AgentA's descriptions were too dry and technical, while AgentA would argue that AgentB's suggestions were too vague and marketing-oriented.

To break this cycle, I introduced a review/critique loop between the two agents, using LangGraph's StateGraph to model their interactions and MCP's tools module to facilitate their communication. Here's an example of how I implemented this loop in Python:

import langgraph as lg
from mcp import tools

# Define the agents and their objectives
agent_a = lg.Agent("AgentA", objective="generate_product_description")
agent_b = lg.Agent("AgentB", objective="review_product_description")

# Create a StateGraph to model the agents' interactions
graph = lg.StateGraph()

# Add nodes for the agents' states
graph.add_node("agent_a_initial", agent_a.initial_state)
graph.add_node("agent_b_review", agent_b.initial_state)

# Add conditional edges to model the review/critique loop
graph.add_conditional_edges(
    ("agent_a_initial", "agent_b_review", lambda x: x["review"] == "pending"),
    ("agent_b_review", "agent_a_initial", lambda x: x["revision"] == "requested")
)

# Define the critique function for AgentB
def critique(description):
    # Simulate AgentB's review process
    review = tools.generate_text("Review of product description", context=description)
    return review

# Define the revision function for AgentA
def revise(description, review):
    # Simulate AgentA's revision process
    revised_description = tools.generate_text("Revised product description", context=description, feedback=review)
    return revised_description

# Run the review/critique loop
while True:
    # Get the current state of the agents
    agent_a_state = graph.get_node("agent_a_initial")
    agent_b_state = graph.get_node("agent_b_review")

    # Generate an initial description with AgentA
    description = agent_a.generate_text("Product description")

    # Review the description with AgentB
    review = critique(description)

    # Check if the review is satisfactory
    if review["satisfactory"] == True:
        break

    # Revise the description with AgentA
    revised_description = revise(description, review)

    # Update the agents' states
    graph.update_node("agent_a_initial", agent_a_state, revised_description)
    graph.update_node("agent_b_review", agent_b_state, review)

    # Checkpoint the current state
    tools.checkpoint("review_critique_loop", graph.get_state())

This implementation allows the agents to engage in a iterative review and revision process, with AgentB providing feedback on AgentA's output and AgentA incorporating that feedback into its next iteration. The StateGraph models the agents' interactions, and the tools module facilitates their communication and provides utilities for generating text and managing the review/critique loop.

One practical gotcha I encountered while implementing this loop was the need to carefully manage the agents' states and ensure that they were properly synchronized. If the agents' states become desynchronized, the review/critique loop can become stuck or produce inconsistent results. To avoid this, I used LangGraph's checkpointers module to regularly save the current state of the agents and the StateGraph, allowing me to easily recover in case of errors or inconsistencies.

As we continue to explore the possibilities of agentic AI, we'll delve deeper into the challenges of coordinating multiple agents and ensuring that they work together effectively towards a common goal. Tomorrow, we'll examine how to scale up our agent-based systems to tackle more complex tasks and domains.

Day 19/30: 3-Agent Content Pipeline

Kasi Yaswanth — Wed, 29 Jul 2026 05:42:32 +0000

I still remember the day our content generation pipeline fell apart. We had built a system that relied on a single agent to research, write, and edit content. It was a mess - the agent would often get stuck in an infinite loop, trying to perfect a piece of content that was already good enough. Our support team was flooded with complaints about delayed deliveries, and our team was struggling to keep up with the demand. That's when we decided to break down the pipeline into three separate agents: researcher, writer, and editor. Each agent would have a specific role, and they would work in sequence to generate high-quality content.

The researcher agent would be responsible for gathering information on a given topic. It would use LangGraph's StateGraph to build a knowledge graph, which would then be passed to the writer agent. The writer agent would use this graph to generate a draft, which would be reviewed by the editor agent. The editor agent would then refine the draft, checking for grammar, coherence, and overall quality.

Here's an example of how we implemented this pipeline using LangGraph and MCP:

import langgraph
from langgraph import StateGraph
from mcp import ModelContextProtocol

# Define the researcher agent
def researcher_agent(topic):
    # Create a new StateGraph
    graph = StateGraph()

    # Add nodes for the topic and related concepts
    graph.add_node(topic)
    graph.add_node("concept1")
    graph.add_node("concept2")

    # Add conditional edges between the nodes
    graph.add_conditional_edges([
        (topic, "concept1", 0.8),
        (topic, "concept2", 0.4),
        ("concept1", "concept2", 0.6)
    ])

    # Return the StateGraph
    return graph

# Define the writer agent
def writer_agent(graph):
    # Use the StateGraph to generate a draft
    draft = ""
    for node in graph.nodes:
        draft += f"{node} is related to {graph.get_neighbors(node)}\n"

    # Return the draft
    return draft

# Define the editor agent
def editor_agent(draft):
    # Refine the draft
    refined_draft = ""
    for sentence in draft.split("\n"):
        # Check for grammar and coherence
        if sentence:
            refined_draft += sentence + "\n"

    # Return the refined draft
    return refined_draft

# Create an instance of the ModelContextProtocol
mcp = ModelContextProtocol()

# Define the pipeline
def content_pipeline(topic):
    # Researcher agent
    graph = researcher_agent(topic)

    # Writer agent
    draft = writer_agent(graph)

    # Editor agent
    refined_draft = editor_agent(draft)

    # Return the refined draft
    return refined_draft

# Test the pipeline
topic = "agentic AI"
print(content_pipeline(topic))

One practical gotcha we encountered while building this pipeline was ensuring that the agents were properly synchronized. We had to implement a checkpointing system to ensure that the output of one agent was correctly passed to the next agent. This involved using LangGraph's checkpointers module to save the state of each agent after it completed its task.

As we continue to develop our agentic AI systems, we're excited to explore new ways to improve the efficiency and effectiveness of our pipelines. Tomorrow, we'll dive into another critical aspect of building complex AI systems, and we'll see how LangGraph and MCP can help us overcome the challenges that come with it.

Day 18/30: Shared State in Agents

Kasi Yaswanth — Tue, 28 Jul 2026 05:37:53 +0000

I recently spent a frustrating afternoon debugging a conversation flow in our customer support bot, built using LangGraph and MCP. The issue was that two agents, designed to work together seamlessly, kept losing context and repeating the same questions to the user. It was as if they had no memory of their previous interactions. After digging through the code and the MCP protocol documentation, I realized the problem boiled down to a simple yet critical decision: how these agents were sharing information with each other.

The support bot is designed to hand off conversations between two agents: one for general inquiries and another for more complex, technical issues. The idea is that when the general inquiries agent reaches its limits, it seamlessly transfers the conversation to the technical agent, which can dive deeper into the user's problem. However, the technical agent kept asking for the user's issue description again, despite the general inquiries agent having already collected this information. This was not only inefficient but also frustrating for the users.

The root of the problem lay in how the agents were managing their state. Initially, I had each agent maintain its own isolated state, which seemed like the most straightforward approach to avoid unintended side effects between them. However, this isolation meant that when the conversation was handed off from one agent to the other, none of the previously gathered context was preserved. The technical agent had no knowledge of the information the general inquiries agent had already obtained.

To solve this issue, I needed to implement a shared scratchpad or state mechanism that would allow both agents to access and update the conversation context without compromising the integrity of their individual states. LangGraph provides a powerful tool for managing state transitions and interactions through its StateGraph API, and MCP offers the add_node and add_conditional_edges methods to define complex workflows and conditions under which state transitions occur.

Here's an example of how I used these tools to create a shared scratchpad for the agents:

import langgraph as lg
from mcp import StateGraph, add_node, add_conditional_edges

# Define the shared scratchpad as a node in the StateGraph
shared_scratchpad = StateGraph()
add_node(shared_scratchpad, 'context', {'user_issue': None})

# Define the agents and their initial states
general_inquiries_agent = lg.Agent('general_inquiries')
technical_agent = lg.Agent('technical')

# Add conditional edges to manage state transitions based on the conversation flow
add_conditional_edges(shared_scratchpad, [
    ('general_inquiries', 'technical', lambda context: context['user_issue'] is not None)
])

# Example of updating the shared scratchpad from within an agent
def update_context(agent, user_input):
    context = shared_scratchpad.get_node('context')
    context['user_issue'] = user_input
    shared_scratchpad.update_node('context', context)

# Usage within an agent's workflow
def general_inquiries_workflow(user_input):
    update_context(general_inquiries_agent, user_input)
    # Hand off to technical agent if necessary
    if shared_scratchpad.evaluate_transition('general_inquiries', 'technical'):
        return technical_agent.handle_conversation()

# Technical agent can access the shared context
def technical_agent_workflow():
    context = shared_scratchpad.get_node('context')
    user_issue = context['user_issue']
    # Proceed with the conversation using the shared context
    return handle_technical_issue(user_issue)

This approach allowed the agents to share the conversation context effectively, significantly improving the user experience by eliminating redundant questions and ensuring a smoother handoff between agents.

One practical gotcha to watch out for when implementing shared state mechanisms is ensuring that the state updates are properly synchronized and that race conditions are avoided, especially in distributed or concurrent environments. This might involve using locking mechanisms or transactional updates to the shared state, depending on the specific requirements and constraints of your application.

As we move forward in building more complex agentic AI systems, the ability to manage shared state and facilitate seamless interactions between agents will become increasingly crucial. Tomorrow, we'll delve into another critical aspect of agent development, exploring how to enhance the autonomy and decision-making capabilities of our agents.

Day 17/30: Orchestrator-Worker with LangGraph

Kasi Yaswanth — Mon, 27 Jul 2026 06:17:43 +0000

I recently spent a few late nights debugging an issue with our support bot, which was supposed to handle multiple conversations simultaneously. The problem was that it would often drop context or respond to the wrong user, even though we were using LangGraph's StateGraph to manage the conversation state. It turned out that the issue was due to the way we were running our agents - we were using a single agent to handle all conversations, which was leading to a lot of conflicts and inconsistencies.

To fix this, we decided to switch to an orchestrator-worker model, where a single orchestrator agent would manage the overall workflow and assign tasks to multiple worker agents. This way, each conversation would have its own dedicated worker agent, which would prevent the context switching issues we were seeing. But to make this work, we needed a way for the orchestrator to send tasks to the worker agents, and for the workers to send results back to the orchestrator.

That's where LangGraph's Send API comes in. The Send API allows you to send messages between agents, which is exactly what we needed to implement our orchestrator-worker model. Here's an example of how we used the Send API to send a task from the orchestrator to a worker:

import langgraph

# Create the orchestrator agent
orchestrator = langgraph.Agent("orchestrator")

# Create a worker agent
worker = langgraph.Agent("worker")

# Define a task for the worker to complete
task = langgraph.Task("respond_to_user", user_id=123, message="Hello!")

# Send the task to the worker using the Send API
orchestrator.send(worker, task)

# Define a callback function to handle the response from the worker
def handle_response(response):
    print(f"Received response from worker: {response}")

# Send a message to the worker and wait for a response
response = orchestrator.send_and_wait(worker, task, callback=handle_response)

In this example, the orchestrator agent sends a task to the worker agent using the send method, and then waits for a response using the send_and_wait method. The worker agent receives the task and completes it, and then sends a response back to the orchestrator using the send method.

To run multiple workers in parallel, we can use LangGraph's add_node method to create a new node for each worker, and then use the add_conditional_edges method to define the workflow between the orchestrator and the workers. Here's an example:

# Create a new node for each worker
workers = [langgraph.Agent(f"worker_{i}") for i in range(5)]

# Define the workflow between the orchestrator and the workers
orchestrator.add_node("dispatch_task", lambda task: task.user_id % len(workers))
for i, worker in enumerate(workers):
    orchestrator.add_conditional_edge("dispatch_task", worker, lambda task: task.user_id % len(workers) == i)

In this example, we create a new node for each worker, and then define a workflow that dispatches tasks to the workers based on the user ID.

One practical gotcha to watch out for when using the Send API is that it can be slow if you're sending a lot of messages between agents. To mitigate this, you can use LangGraph's checkpointers to cache the results of expensive computations and reduce the number of messages that need to be sent. For example:

# Create a checkpoint to cache the results of expensive computations
checkpoint = langgraph.Checkpoint("expensive_computation")

# Define a function to compute the result
def compute_result(task):
    # Simulate an expensive computation
    import time
    time.sleep(1)
    return task.user_id * 2

# Use the checkpoint to cache the result
@langgraph.checkpointed(compute_result, checkpoint)
def cached_compute_result(task):
    return compute_result(task)

By using the checkpointed decorator, we can cache the result of the expensive computation and avoid recomputing it every time the worker receives a task.

As we continue to build out our agentic AI system, we'll need to tackle even more complex challenges, such as integrating with external systems and handling failures and errors. Tomorrow, we'll explore some of the tools and techniques we can use to build more robust and resilient agents.

Day 16/30: Supervisor Pattern

Kasi Yaswanth — Sun, 26 Jul 2026 05:51:16 +0000

I recently spent hours debugging a support bot that was supposed to handle customer inquiries about orders, shipments, and returns. The bot was built using LangGraph and MCP, and it worked great in isolation, but when we deployed it to production, it started to fail in unexpected ways. Sometimes it would answer questions about orders when the customer was asking about returns, or vice versa. It was as if the bot had forgotten what context it was in, and was just making random guesses.

After digging through the code, I realized that the problem was that the bot was trying to do too much itself. It was a single agent that was responsible for understanding the customer's question, retrieving the relevant information from the database, and generating a response. This was causing the bot to get overwhelmed and lose track of what it was doing.

That's when I decided to try out the Supervisor pattern. The idea is to create a manager agent that delegates tasks to specialized worker agents. In this case, I created a supervisor agent that would receive the customer's question and then delegate it to one of three worker agents: an orders agent, a shipments agent, or a returns agent. Each worker agent was responsible for a specific task, such as retrieving information from the database or generating a response.

Here's an example of how I implemented the Supervisor pattern using LangGraph and MCP:

import langgraph as lg
from mcp import tools

# Define the supervisor agent
supervisor = lg.StateGraph()
supervisor.add_node("start", tools.prompt("What is your question?"))
supervisor.add_node("orders", tools.prompt("What is your order number?"))
supervisor.add_node("shipments", tools.prompt("What is your shipment tracking number?"))
supervisor.add_node("returns", tools.prompt("What is your return reason?"))

# Define the worker agents
orders_agent = lg.StateGraph()
orders_agent.add_node("start", tools.prompt("Order details:"))
orders_agent.add_node("response", tools.response("Your order will be shipped soon."))

shipments_agent = lg.StateGraph()
shipments_agent.add_node("start", tools.prompt("Shipment details:"))
shipments_agent.add_node("response", tools.response("Your shipment is on its way."))

returns_agent = lg.StateGraph()
returns_agent.add_node("start", tools.prompt("Return details:"))
returns_agent.add_node("response", tools.response("Your return has been processed."))

# Define the conditional edges between the supervisor and worker agents
supervisor.add_conditional_edges(
    "start",
    {
        "orders": lambda x: x.contains("order"),
        "shipments": lambda x: x.contains("shipment"),
        "returns": lambda x: x.contains("return")
    }
)

# Define the conditional edges between the worker agents and the supervisor
orders_agent.add_conditional_edges(
    "start",
    {
        "response": lambda x: True
    }
)

shipments_agent.add_conditional_edges(
    "start",
    {
        "response": lambda x: True
    }
)

returns_agent.add_conditional_edges(
    "start",
    {
        "response": lambda x: True
    }
)

# Run the supervisor agent
supervisor.run()

This code defines a supervisor agent that delegates tasks to three worker agents based on the customer's question. Each worker agent is responsible for a specific task, such as retrieving information from the database or generating a response.

One practical gotcha to watch out for when using the Supervisor pattern is that it can be easy to create a situation where the supervisor agent is delegating tasks to worker agents that are not equipped to handle them. For example, if the orders agent is not designed to handle questions about shipments, it may not be able to generate a correct response. To avoid this, it's essential to carefully define the conditional edges between the supervisor and worker agents, and to ensure that each worker agent is designed to handle the tasks that are delegated to it.

As we continue to build more complex agentic AI systems, we'll need to develop new patterns and techniques for managing the interactions between agents. Tomorrow, we'll explore another key concept that will help us build more robust and scalable AI systems.

Day 15/30: Specialist Agents Over Giant Prompts

Kasi Yaswanth — Sat, 25 Jul 2026 05:35:06 +0000

I was working on a support bot recently, and it was supposed to handle a wide range of user queries, from simple FAQs to more complex troubleshooting issues. The initial idea was to use a single giant prompt that would cover all possible scenarios, and the LangGraph model would magically figure out the context and respond accordingly. Sounds simple, right? Well, it didn't quite work out that way.

The bot would often get confused and provide irrelevant or even contradictory responses. For instance, if a user asked about the return policy and then followed up with a question about shipping, the bot would sometimes respond with a shipping answer that didn't take into account the previous conversation about returns. It was as if the bot had forgotten the context of the conversation. This was frustrating, not just for the users, but also for me, as I had to spend hours debugging and trying to figure out what was going wrong.

The problem, I realized, was that I was trying to cram too much functionality into a single agent. The giant prompt was trying to cover too many bases, and the model was getting overwhelmed. This is where the concept of specialist agents comes in. Instead of having one giant agent that tries to do everything, it's often better to have multiple specialist agents, each focused on a specific task or domain.

In the case of the support bot, I could have one agent that handles FAQs, another that handles returns and refunds, and another that handles shipping and logistics. Each agent would have its own prompt, tailored to its specific domain, and would be responsible for handling a specific set of user queries. This approach has several advantages. For one, it allows each agent to focus on a specific task, without getting overwhelmed by the complexity of the entire system. It also makes it easier to update and maintain the system, as changes can be made to individual agents without affecting the entire system.

Here's an example of how I might implement this using LangGraph and MCP:

import langgraph as lg
from mcp import ModelContextProtocol

# Define the specialist agents
faqs_agent = lg.StateGraph()
faqs_agent.add_node("start", "Welcome to our FAQs! What can I help you with?")
faqs_agent.add_node("returns", "Our return policy is...")

returns_agent = lg.StateGraph()
returns_agent.add_node("start", "Returns and refunds...")

shipping_agent = lg.StateGraph()
shipping_agent.add_node("start", "Shipping and logistics...")

# Define the MCP prompts for each agent
faqs_prompt = MCP.tools.prompt("What is your question about our product?")
returns_prompt = MCP.tools.prompt("What is your return or refund question?")
shipping_prompt = MCP.tools.prompt("What is your shipping or logistics question?")

# Use the MCP protocol to interact with the agents
mcp = ModelContextProtocol()
mcp.add_agent(faqs_agent, faqs_prompt)
mcp.add_agent(returns_agent, returns_prompt)
mcp.add_agent(shipping_agent, shipping_prompt)

# Test the system
user_input = "What is your return policy?"
response = mcp.interact(user_input)
print(response)

In this example, we define three specialist agents, each with its own prompt and state graph. We then use the MCP protocol to interact with the agents, routing the user's input to the relevant agent based on the prompt.

One practical gotcha to watch out for when using specialist agents is to make sure that the prompts are specific enough to route the user's input to the correct agent. If the prompts are too general, the system may get confused and route the input to the wrong agent. For instance, if the prompts for the returns and shipping agents are too similar, the system may mistakenly route a shipping question to the returns agent.

As we continue to build more complex agentic AI systems, we'll need to consider how to coordinate and manage multiple specialist agents, and how to ensure that they work together seamlessly to provide a cohesive user experience. Tomorrow, we'll explore some of the challenges and opportunities of building these kinds of systems, and how LangGraph and MCP can help us overcome them.

Day 14/30: Debugging LangGraph Loops

Kasi Yaswanth — Fri, 24 Jul 2026 05:41:00 +0000

You've just deployed a new support bot built with LangGraph, and it was working great for the first few hours. But then, out of nowhere, it started looping forever on the same conversation topic. You're getting error reports from frustrated customers, and your team is breathing down your neck to fix it ASAP. The problem is, you have no idea why it's happening. The agent's code looks fine, and you've tested it with dozens of different conversation scenarios.

So, where do you even start debugging this? The first step is to understand how LangGraph's StateGraph works. Essentially, it's a directed graph where each node represents a state, and edges represent transitions between those states. When an agent loops forever, it's usually because it's getting stuck in a cycle - a closed loop of states where it just keeps transitioning between the same few nodes.

To debug this, you'll want to visualize the StateGraph and see where the cycle is happening. One way to do this is by using the add_checkpoint method to log the agent's state at each transition. Here's an example of how you might modify your agent code to do this:

import langgraph as lg

# Create a new StateGraph
graph = lg.StateGraph()

# Add some nodes and edges...
graph.add_node("start")
graph.add_node("ask_name")
graph.add_node("ask_email")
graph.add_conditional_edges("start", "ask_name", lambda x: True)
graph.add_conditional_edges("ask_name", "ask_email", lambda x: True)
graph.add_conditional_edges("ask_email", "start", lambda x: True)  # this edge is causing the cycle

# Add a checkpoint to log the agent's state at each transition
def checkpoint(state):
    print(f"Transitioned to state: {state}")

graph.add_checkpoint(checkpoint)

# Run the agent...
agent = lg.Agent(graph)
agent.run()

In this example, the checkpoint function will print out the agent's state at each transition. By looking at the output, you should be able to see where the cycle is happening.

Once you've identified the cycle, you can start digging into why it's happening. Is the conditional logic in your edges correct? Are you inadvertently creating a self-looping edge? Are there any external factors (like a misconfigured MCP tool) that could be contributing to the issue?

One practical gotcha to watch out for is that LangGraph's add_conditional_edges method can sometimes create self-loops if you're not careful. For example, if you have an edge with a conditional that always evaluates to True, you may end up creating a self-loop without realizing it. To avoid this, make sure to carefully test your conditionals and edges before deploying your agent.

As we move forward in this series, we'll be exploring more advanced topics in agentic AI - including how to integrate LangGraph with other tools and frameworks to build even more powerful agents. Tomorrow, we'll start to dive into the world of Model Context Protocol (MCP) and how it can be used to add even more functionality to your LangGraph agents.

Day 13/30: Teaching Self-Correction

Kasi Yaswanth — Thu, 23 Jul 2026 05:44:55 +0000

I still remember the day our support bot, built on top of LangGraph, started producing bizarre responses. A user would ask for help with a simple issue, and the bot would veer off into a completely unrelated topic. The problem wasn't that the bot was giving incorrect answers, but rather that it seemed to be forgetting the context of the conversation altogether. We'd see the bot respond to a question about password reset with a lengthy explanation of our company's history. It was as if the bot had lost its train of thought mid-conversation.

After digging into the logs, we realized that the issue stemmed from the bot's inability to self-correct. It would make a mistake, but then it wouldn't recognize that mistake or take steps to rectify it. This is where the reflection pattern comes in, particularly with the use of a critic node. The idea is to have the agent periodically reflect on its own actions and decisions, evaluating whether they align with its goals and the current context.

In our case, we implemented a critic node that would assess the bot's responses and check if they were relevant to the conversation. If the critic node determined that a response was off-topic or incorrect, it would trigger a self-correction mechanism, allowing the bot to recover from its mistake. This involved adding a new node to our LangGraph that would serve as the critic, and then using the add_conditional_edges method to connect this node to the rest of the graph.

Here's a simplified example of how we implemented the critic node:

import langgraph as lg

# Define the graph
graph = lg.StateGraph()

# Add nodes for the conversation states
start_node = graph.add_node("start")
question_node = graph.add_node("question")
response_node = graph.add_node("response")

# Add the critic node
critic_node = graph.add_node("critic")

# Define the critic function
def critic_function(state, response):
    # Simplified example: check if the response contains a certain keyword
    if "password" in response and state == "question":
        return True
    return False

# Add conditional edges based on the critic function
graph.add_conditional_edges(
    response_node, 
    [critic_node], 
    lambda state, response: critic_function(state, response)
)

# Add a self-correction mechanism
def self_correct(state, response):
    # Simplified example: return a generic apology message
    return "Sorry, I made a mistake. Let me try again."

graph.add_conditional_edges(
    critic_node, 
    [question_node], 
    lambda state, response: True, 
    self_correct
)

This code snippet illustrates how we used the critic node to evaluate the bot's responses and trigger self-correction when necessary. Of course, in a real-world implementation, the critic function and self-correction mechanism would be more sophisticated.

One practical gotcha we encountered while implementing the reflection pattern was ensuring that the critic node didn't become too overly critical. If the critic node was too sensitive, it would trigger self-correction too frequently, leading to a bot that seemed indecisive or uncertain. We had to fine-tune the critic function to strike the right balance between correcting mistakes and allowing the bot to confidently provide responses.

As we continue to develop our agentic AI systems, we're realizing that teaching an agent to self-correct is just the beginning. Tomorrow, we'll explore how to take this concept further, enabling our agents to not only reflect on their actions but also adapt and learn from their experiences.

Day 12/30: Streaming Agent Reasoning

Kasi Yaswanth — Wed, 22 Jul 2026 05:40:00 +0000

I recently spent hours debugging a support bot built with LangGraph and MCP, only to realize that the issue wasn't with the agent's reasoning itself, but with how we were presenting that reasoning to the user. The bot would often appear to be stuck on a loading spinner, leaving the user wondering if it had frozen or was still actively working on their query. The problem was that our frontend was only updated once the agent had completed its entire thought process, which could take several seconds or even minutes for complex queries.

This experience led me to explore how we could stream an agent's reasoning to the frontend in real time, providing a more interactive and engaging experience for the user. By doing so, we could give users a better understanding of what the agent was doing and why, which is especially important for applications where transparency and trust are key.

To achieve this, we can leverage LangGraph's StateGraph and add_node functionality to build a graph that represents the agent's reasoning process. We can then use MCP's tools and resources to create a stream of updates that can be sent to the frontend as the agent works through its thought process.

Here's an example of how we might implement this using Python:

import langgraph as lg
from mcp import tools, resources

# Create a new StateGraph to represent the agent's reasoning process
graph = lg.StateGraph()

# Define a node that represents the agent's current thought process
def thought_process_node(graph, thought_process):
    node = graph.add_node(thought_process)
    # Add conditional edges to represent the possible next steps in the thought process
    graph.add_conditional_edges(node, [
        (thought_process + " -> considering option A", 0.7),
        (thought_process + " -> considering option B", 0.3)
    ])
    return node

# Create a stream of updates that can be sent to the frontend
def stream_reasoning(graph, initial_thought_process):
    current_node = thought_process_node(graph, initial_thought_process)
    while True:
        # Get the next node in the graph based on the current node and the agent's reasoning
        next_node = graph.get_next_node(current_node)
        # Send an update to the frontend with the current thought process and the next possible steps
        yield {
            "thought_process": next_node.value,
            "next_steps": [edge.value for edge in graph.get_outgoing_edges(next_node)]
        }
        # Update the current node
        current_node = next_node

# Create a checkpoint to save the agent's reasoning process
checkpoint = resources.Checkpoint("agent_reasoning")

# Start the agent's reasoning process and stream the updates to the frontend
initial_thought_process = "considering user query"
for update in stream_reasoning(graph, initial_thought_process):
    # Send the update to the frontend
    print(update)
    # Save the current state of the agent's reasoning process
    checkpoint.save(graph)

This code creates a StateGraph to represent the agent's reasoning process and defines a node that represents the current thought process. It then creates a stream of updates that can be sent to the frontend as the agent works through its thought process. The stream_reasoning function yields an update at each step, which includes the current thought process and the next possible steps.

One practical gotcha to watch out for when implementing this approach is that the agent's reasoning process can be highly branching, leading to an exponential number of possible next steps. To mitigate this, we can use techniques such as beam search or pruning to limit the number of possible next steps and prevent the graph from becoming too large.

As we continue to explore the possibilities of agentic AI, we'll be delving deeper into the complexities of agent reasoning and how we can use LangGraph and MCP to build more transparent and interactive systems. Tomorrow, we'll be looking at how to integrate multiple agents and models to create even more powerful and flexible AI applications.