AI agents in real business: what building a production support agent actually taught me
There is a customer-support agent live on this site: it answers questions about orders, stock, and shop policies for the Röstwerk demo shop. Every statement it makes traces back to a tool call you can read in the trace view. That trace is the point. For AI agents in real businesses, the hard problem is not the model; it is verifiability, and verifiability comes from the architecture.
Grounding: every claim has an address#
The agent has four read-only tools covering orders, stock, and shop policies. It cannot send messages, mutate data, or answer from imagination: the system prompt forbids it, and the architecture enforces it, because facts enter the conversation only as tool results.
One structural choice earns its keep here. The agent loop is a pure TypeScript library with no framework dependency. Transport (an SSE route), the model (gpt-5-nano via the Responses API), and the tools only meet at the edges. That is why the same loop runs behind HTTP, in unit tests, and inside the scripted fallback without changes.
Zod schemas sit at every boundary. Tool arguments are validated before a tool executes, so a malformed call never reaches a tool. Tool results are validated before they go back to the model, so a broken payload cannot poison the context. The final reply is validated before delivery, so a schema violation becomes a loud error instead of a confident wrong answer.
The demo UI shows the trace: which tool ran, with which arguments, what came back. When the agent says order 1042 was paid, you can see the row it based that on. This is what separates a demo from something you can put in front of customers.
What a run costs#
gpt-5-nano is the cheapest GPT with reliable function calling: $0.05 per million input tokens and $0.40 per million output tokens (standard tier, September 2026). A typical run with one tool call lands around 1,300 input and 270 output tokens, which is about $0.0002 per answer. Latency runs 5 to 8 seconds end to end at reasoning effort "low".
At that price the budget conversation is short. The remaining cost control is structural: the agent loop stops after three tool rounds, which caps the worst-case run and rules out runaway loops.
Prices are list prices for the standard tier as of September 2026. They have moved before, so check them before you budget against this article.
The legal part is small when the architecture does it#
Germany, September 2026: the EU AI Act has been fully applicable since 2 August. A support agent like this one is minimal-risk under it: no biometrics, no decisions about people, and the chat is visibly labelled as AI. What matters is documenting that classification. The paragraph in the privacy policy is the difference between "some chatbot" and an auditable system.
GDPR stays short because there is almost nothing to protect. The endpoint is stateless: no cookies, no accounts, no conversation logs. Model calls run with store:false, so OpenAI retains nothing either. The tools serve demo data with no personal reference, so a personal-data scope never arises in the first place. Data minimisation under Art. 5 GDPR, done by architecture, beats any amount of policy text.
Guardrails you can unit-test#
Hard limits come first: input length and format are capped before anything reaches the model. The system prompt adds the rules: facts only from tools, answers in the visitor's language, no personal data, no storage. A conversation exists only for the one answer.
The eval cases live in unit tests, and that is where I would keep them:
- An unknown order number gets an honest "I don't have that order", never invented details.
- A prompt injection ("ignore your instructions") leaves the agent on topic.
- A reply that violates the reply schema fails the build, because a red test is cheaper than a customer reading a fabricated pickup time.
A model grading its own answers is not an eval. Assert against schemas and fixtures; the test suite has no incentive to be polite.
Degrade, don't error#
The demo works without an API key. A deterministic scripted provider takes over the exact same loop: same trace format, same schemas. The same switch fires when the daily token budget runs out. Visitors never see an error page, and the demo cannot run up a surprise bill. If I could carry one piece of this architecture into other agent projects, it would be this one.
The same four tools as an MCP server#
The tools also run as a public MCP server (spec 2026-07-28, Streamable HTTP, stateless, read-only) at https://dimitripisarev.com/api/mcp. Add it to Claude as a custom connector and ask about order 1042; the answer comes back as structured content. No OAuth, no session, nothing stored between requests.
Where to try it#
The agent runs on the landing page. The case study documents the architecture, the guardrails, and the measured numbers: /en/work/ai-support-agent. Both work right now, and the scripted fallback is the reason that sentence can be that confident.