Day 30/30: Building End-to-End Support Ticket Triage

I still remember the day our support-ticket triage agent went live, only to start forgetting the context of conversations after a few exchanges. Customers would report issues, and our agent would respond with generic solutions, completely unaware of the previous messages. It was as if the agent had no memory. We quickly realized that our implementation was missing a crucial piece: the ability to maintain state across multiple interactions.

To fix this, we turned to LangGraph's StateGraph and MCP's tools for building agentic AI systems. We designed a state machine that could transition between different stages of a support ticket, from initial report to resolution. Each stage would have its own set of possible actions and next steps, depending on the customer's input. We used LangGraph's add_node and add_conditional_edges methods to define these states and transitions.

Here's an example of how we defined the initial state and its transitions:

import langgraph as lg
from mcp import tools

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

# Define the initial state
initial_state = graph.add_node("initial_report")
initial_state.set_description("Customer reports an issue")

# Define possible next states based on customer input
next_states = {
    "bug_report": graph.add_node("bug_report"),
    "feature_request": graph.add_node("feature_request"),
    "general_inquiry": graph.add_node("general_inquiry")
}

# Add conditional edges between states
for intent, next_state in next_states.items():
    graph.add_conditional_edges(initial_state, next_state, condition=f"intent == '{intent}'")

# Define the MCP tools and resources needed for each state
tools.register_tool("bug_report", tools.BugReportTool())
tools.register_tool("feature_request", tools.FeatureRequestTool())
tools.register_resource("knowledge_base", tools.KnowledgeBaseResource())

# Use MCP's checkpointers to save the current state and context
checkpointer = tools.Checkpointer("support_ticket_triage")

With this implementation, our support-ticket triage agent could now maintain context across multiple interactions and respond accordingly. However, we soon encountered another issue: the agent would sometimes get stuck in an infinite loop, repeatedly asking the customer for more information without making progress towards resolving the issue.

We learned that this was due to the agent's lack of a clear goal or objective. To fix this, we had to define a set of success criteria for each state and ensure that the agent was working towards achieving those goals. This involved adding more conditional edges and next states to the StateGraph, as well as using MCP's tools and resources to provide the agent with more context and information.

One practical gotcha we encountered was the need to carefully balance the agent's use of memory and context. If the agent retained too much information, it would become slow and unresponsive. On the other hand, if it forgot too much, it would lose context and struggle to respond effectively. This balance is crucial in building effective agentic AI systems, and it's a lesson we'll carry forward as we continue to explore the possibilities of LangGraph and MCP.

As we look to the future, we're excited to see how these technologies will continue to evolve and improve, enabling us to build even more sophisticated and effective AI systems that can tackle complex challenges and make a real impact on people's lives. Tomorrow, we'll be exploring new frontiers in agentic AI, and we can't wait to see what the future holds.

Comments

[Mads Hansen]

State should be smaller and more explicit than the conversation transcript. I’d persist an append-only ticket event stream plus a materialized workflow state: authenticated customer/ticket IDs, current owner, classification with confidence, facts confirmed by tools, unresolved questions, attempted actions, policy decisions, and a state-version number. Every transition should use compare-and-swap so two workers cannot both advance the same ticket. Add a no-progress invariant—if the same missing fields, tool call, or transition repeats N times, move to needs_human with the evidence collected instead of adding another prompt turn. Before sending a reply or mutating the ticket, re-read the latest version and bind the action to that state digest. Then test duplicate messages, out-of-order replies, stale workers, checkpoint recovery, and a tool timeout whose side effect is indeterminate.