Everyone is talking about AI agents in 2026. To be honest, building a demo AI agent is easy. You call an LLM, get a clean response, and it looks impressive at first. When I first built a demo, I was confident going into a real project.
But when my project manager at Capital Numbers assigned me to test the agent for an ecommerce workflow, the real problems showed up. The agent worked… but not really.
The issue appeared whenever a customer wanted to return an item. Instead of continuing the return flow, the agent would go back to:
“Here are your service options…”
Again. And again. In a single day of testing, we saw several return-related interactions in which the agent failed to move the user forward. I had built the flow around clean inputs, not real user behavior.
So, in this blog, I have tried to explain what worked in my demo, what failed in the real use case, the mistakes I made, and why I started looking at MCP as a practical way to better structure AI agents in .NET.
Let’s first start with:
What are AI Agents?
AI agents are systems powered by artificial intelligence, not just to answer questions, but to take actions and complete goals on a user’s behalf. Unlike traditional chatbots, which primarily generate responses, AI agents can plan tasks, make decisions, retrieve information, and execute multi-step workflows with minimal human involvement.
The Real Problem Was Not the Model
At first, I thought the model was the issue. Maybe the prompt was weak, or the response format was wrong. Maybe I needed better examples.
So I kept adjusting the prompt. But the behavior did not really improve.
The agent couldn’t continue the return flow. It didn’t always ask for the missing order ID or check what should happen next. So, instead of moving toward resolution, it kept reverting to the main menu or service options.
The thing is, you can easily find the broken agent, but a failing agent is harder to find because it still responds, even though it’s not resolving the user's problem.
The Demo-to-Production Gap
This was a classic case of the "Happy Path" trap. When we build demos, we usually code for the ideal scenario. We expect the user to ask a clear question, and the agent gives a clear answer.
But you can't expect every user to say: "I want to return the order 12345678."
They may say:
"This item does not fit."
"I got the wrong product."
"Can you exchange this?"
"I already selected a return. Why are you showing me the same options again?"
As humans, we can easily identify these as return or exchange signals. The LLM may also understand the intent, but the agent still needs the right tool, missing-input handling, workflow state, and fallback path. That’s exactly why my first version was failing.
Mistakes I Made & You Should Try to Avoid
It wasn't just a minor bug. It was a mix of small architectural mistakes that you can't realize in a demo.
1. Don't Assume General Intelligence is Contextual Awareness
What feels obvious to us does not always translate into an application context for an agent. I assumed that because the LLM was smart, it would automatically understand the application context. Well, it didn’t.
An LLM may understand the sentence: "I want to return this item."
But that does not mean it knows:
Whether the user is logged in
Whether the user has an active order
Whether the order is eligible for return
Whether the return window is still open
Whether the product can be exchanged
Whether human support is required
If it doesn't have reliable access to systems, the agent is basically guessing. So when the agent was unsure, it fell back to what it knew: the home menu.
2. Don't Make the Return Tool Too Restrictive
This was one of the biggest causes of the loop. The return tool expected an order ID too early in the conversation. While this worked from a backend logic perspective, real users raise requests differently. That’s why the agent would get stuck repeatedly asking for the same information instead of guiding the conversation naturally.
I’m sharing a simple version of the mistake:
public class ReturnTools
{
[KernelFunction]
[Description("Handles product returns")]
public async Task<string> HandleReturn(string orderId)
{
var order = await _orderService.GetOrderAsync(orderId);
return $"Return initiated for order {orderId}.";
}
}At first glance, this looks reasonable. The tool handles returns, accepts an order ID, calls the order service, and returns a response.
But the tool needs orderId. So, depending on how the agent is configured, it may decide it can’t call the tool.
3. Give Return Intent Enough Priority
In demos, AI agents usually handle simple tasks. The user asks one clear thing, and the agent follows one clean path.
But a real user may suddenly switch topics during a conversation. For example:
“Where’s my order?”
“Actually, I want a refund.”
“Also, the item that arrived is damaged.”
Now the agent has to understand what matters most quickly. But sometimes the agent keeps following the old conversation path. For example, if it was showing delivery options or menu choices, it may continue talking about those instead of realizing the user now wants to start a return process. That’s why intent anchoring is so important.
It helps the system recognize important user requests and shift the conversation immediately. So if the user says, “I want to return this,” the AI should pause the current flow and proceed directly to the return process.
In my model, the agent would technically handle the return, but the system's instructions were too weak, which caused the loop.
4. Don't Try to Fix Everything with Prompts
Naturally, I tried to fix the issue with instructions.
For example:
If the user wants a return, ask for the order ID.
If the user wants an exchange, check whether the product is eligible.
Don’t keep showing the menu again.
These instructions helped a little, but it wasn’t enough. Here’s an example of what was going on:
User: “Can I exchange this shirt?”
AI Agent: “Please share your order ID.”
User: “Never mind, I just want to return it.”
AI Agent: “Please select from the menu options below.”
This usually happens because prompts can suggest behavior, but they can’t control conversation state or workflow transitions. So, when a user has multiple intents, the AI agent may take the wrong conversational path unless the system has stronger workflow control beneath it.
For my AI Agent, it needed MCP.
What Is MCP?
MCP, or Model Context Protocol, is a structured way for an AI agent to discover and use backend tools via a defined interface. It’s basically a safer and more organized way for an AI agent to use backend tools and systems. Instead of giving the AI full access to your application or database, you grant it only a limited set of approved actions.
In a .NET application, you can expose certain C# methods as MCP tools. Even though the AI agent decides what action is needed, the backend system still controls how that action is executed safely.
This worked for my agent. Since the agent did not need unlimited system access or hundreds of complicated instructions. It simply needed a clear, structured set of tools to perform specific tasks properly.
So, here’s an idea of how you should get started:
Step 1: Understand Your Needs Before Building an MCP
You don’t need a very complex setup to build an MCP server in .NET. But you should have the basics ready so you can focus on tool design instead of fighting the environment.
I have made this into a table to keep it easy to understand:
Join the conversation! Your thoughts help the community grow.