Building enterprise AI customer support

In part 3 I built the Policy Agent — the one that answers from documents. This part is its opposite number: the Ticket Agent, the one that actually changes things. Search a route, make a booking, modify it, cancel it, work out a refund. Real database operations, driven by plain language.

The problem it solves

Booking is where support gets messy. A real request rarely maps to one clean database call. Someone wants to change a trip — that means finding their booking, checking what's available, cancelling one thing, creating another, and keeping it all straight across a few messages. They use informal names, like "the London train", that don't match a station code. And when a step fails halfway through, you can't leave the data in a broken state.

So the Ticket Agent isn't a chatbot with database access bolted on. It's an agent with a fixed set of tools — each one a specific, safe operation — and the judgement to pick the right one and recover when something fails.

How it works: tools, not free-form SQL

The agent doesn't write SQL. It calls tools I wrote and tested — named operations — and its only job is to choose which tool to call and with what arguments. That's the safe pattern: the model decides, the tools constrain what can actually happen to the data.

Customer request
→ Ticket Agent picks a tool:
• Booking search        — what's available
• Customer lookup       — their active bookings
• Book / modify / cancel — the transactional work
• Payment + refund calc  — logged every time
• Location mapping       — "London" → the right station
→ Response

Two of those are worth a note. Location mapping turns the informal place name a customer actually types into the station the database understands — I go into that in part 6. And state is kept across the conversation, so "actually, make it the later train" works without starting over.

The full implementation — every tool, the schema, the transaction handling — is in the open-source repo. I'd rather point you at code that runs than paste two hundred lines here.

Next in the series

Now I have both specialists — Policy and Ticket. Next I build the part that decides which one to use: the Master Agent, and the routing and context-handling that ties the whole thing together.

Building transactional AI that touches real systems — and doesn't break them — is what I do at twentytwotensors. Get in touch if you need it.