Skip to content

How a production AI agent reconciles six systems with no shared customer key.

A national wireless carrier reconciled its customer records by hand every month, across six systems that shared no key. The agent we built now does that reconciliation unattended every day.

010203040506one subscriber
Fig. C1 · six systems · one reconciled subscriber record
Results

Before and after.

Before
After
Six systems, no shared customer key
One reconciled record per subscriber
No path from first contact to billing
700–800 leads a month matched end to end, from first contact to billing
Reconciled by hand every month
Runs unattended daily; 24,411 customer journeys reconciled in total
The work

How the work went.

The problem

Customer data lived in six separate systems. None of them shared a customer key, so nobody could follow a subscriber from first contact to billing, and the records were reconciled by hand every month.

What we built

We built it in three layers. The identity layer came first. It matches records on hard identifiers instead of fuzzy name matching, so every match can be explained. Then came connectors into the six systems, on one shared base. Last came the agent. It pulls from each source with a bounded set of tools, checks what comes back, retries within a fixed budget, and sends anything it cannot reconcile to a person.

How we made it trustworthy

Before the agent ran unattended, we built an evaluation framework from real production cases, a regression suite that runs before any change ships, and tracing on every request. Sorting failures by type showed that most were not prompt problems. They were tool-definition problems: two tools describing overlapping jobs, or a schema that allowed a parameter the API would reject. We rewrote the tool contracts and put them under version control.

How it stays under control

Writes to the system of record go through approval gates, and uncertain cases go to a person. Every figure has an audit trail, because people make real decisions on these numbers.

Related

Keep reading.

Questions · Sheet C-11

Questions about this case study.

Not covered here? Send us your question and an engineer will answer it.

Ask a question
Why did most of the agent’s failures come from tool definitions?
Because the model followed the definitions it was given. Two tools described overlapping jobs, or a schema allowed a parameter the API would reject. We rewrote the tool contracts and put them under version control.
How are records matched without a shared customer key?
On hard identifiers, not on names or addresses, so every match can be explained.

Talk to an engineer

Your name and email are enough. Add a line about what's going on if you like.

You talk with an engineer from the first reply.