The expensive question came before the production build
The client did not need another generic AI demonstration. It needed evidence that an agent could improve a specific operating workflow before the internal team committed months of engineering time.
The existing process produced incomplete IT tickets often enough that support staff had to go back for missing information. The proposed solution affected the client’s established Microsoft environment and would eventually need to fit the way its C# team built and maintained software. A polished chat response would not answer the real question. The validation had to exercise the workflow, the tool boundaries, and the handoff into the ticket process.
That changed the scope. I was not trying to build the largest possible first version. I was trying to produce enough working evidence for a responsible go-or-no-go decision.
I separated the validation stack from the permanent stack
I used Azure AI Foundry for the agent and n8n as the MCP layer. The MCP server exposed five bounded tools needed for the tested ticket workflow.
This was a validation architecture, not a demand that the client’s permanent system use my preferred tools. n8n fit the two-week phase because I could change workflow logic quickly, inspect executions, and adjust the integration without waiting for a longer application-development cycle.
That distinction matters. The fastest way to test an architecture is not always the right long-term implementation. Treating those as separate decisions let the client learn quickly without locking its engineering team into the prototype stack.
The demo reduced uncertainty without pretending to be production
Within two weeks, the demo was strong enough for the client to greenlight the production effort. It validated the core approach before the internal C# team committed to owning the permanent build.
The important result was not that a prototype existed. It was that the client could make the $30,000-plus production decision with working evidence instead of relying only on a proposal or vendor documentation.
I describe this as de-risking the build, not saving $30,000. The client still chose to move forward with production. The demo reduced the risk of funding the wrong approach; it did not eliminate the cost of building, operating, and supporting the permanent system.
The system around the agent carried the real decision
The model was only one component. The useful proof came from the surrounding system:
- a defined ticket workflow rather than an open-ended assistant
- five bounded tools instead of unrestricted access
- an integration layer that could be changed and inspected during validation
- a path that respected the client’s Microsoft environment and internal team
- a clear boundary between demo evidence and production ownership
This is the part of AI-agent work I focus on: tools, APIs, authentication, infrastructure, validation, observability, and handoff. A convincing interface is useful, but it is not enough to justify a production commitment.
What this case study proves—and what it does not
The project proves that a focused two-week demo can answer a meaningful architecture question before a much larger implementation begins. In this case, Azure AI Foundry, an n8n MCP layer, and five bounded tools gave an enterprise Microsoft team enough evidence to approve production work.
It does not prove the final system’s uptime, operating cost, long-term ticket quality, or production return on investment. Those belong to the permanent implementation and its operating data. I will not present demo results as production outcomes.
The reusable lesson is narrower and more useful: when the expensive uncertainty is whether the workflow and tool pattern will work, validate that uncertainty before committing the full build budget.
Frequently asked questions
Why use a demo before building the production system?
A focused demo tests the highest-risk assumptions before a team commits the full engineering budget. It should produce evidence for a decision, not act as a disguised production release.
Why was n8n used as the MCP layer?
n8n made the validation logic fast to change and its executions easy to inspect. That was useful for a two-week learning phase. The client’s permanent stack remained a separate engineering decision.
Does this approach only work in Azure?
No. The principle is platform-independent: define the workflow, expose bounded tools, test the difficult integration path, and separate prototype speed from the permanent operating model. Azure fit this case because the client was already a Microsoft organization.