What production readiness actually means for an AI agent

The demo is about a third of it

This is the single most expensive misunderstanding in the field, and it is nobody's fault: the demo genuinely works. Somebody shows an agent booking a meeting, and it books the meeting. The conclusion that the thing is nearly finished is a reasonable one to draw and it is wrong by roughly a factor of three.

What the demo left out is what happens when the calendar API times out, when two people ask for the same slot within a second of each other, when the input arrives in a format nobody anticipated, or when the model is confidently wrong about something and nothing downstream catches it. None of that is exotic. All of it happens in the first fortnight, and handling it is most of the build.

So teams size the budget and the timeline against the demo, discover the other two thirds in month two, and the project acquires a reputation for having stalled when it was in fact proceeding normally. When somebody tells me their last AI project went nowhere, this is what happened about half the time.

Six things that have to exist

This is the list I work through before calling anything production, and it is short enough to hold a supplier to.

• An identity of its own, with access to exactly the systems its job touches and nothing wider, rather than a login borrowed from a colleague.
• A written list of what it does, including what it does not. Anything it does not recognise goes to a person by default.
• An audit trail a colleague can read next week without ringing you.
• An escalation path with a named condition and a named person behind it.
• Monitoring that fires on silence, not only on errors.
• A handover, so the team runs it after the person who built it has gone.

Its own credentials, not somebody's login

The fastest way to get an agent working is to give it an existing user's credentials, and it is the decision that is hardest to unpick later. Two things go wrong. The audit trail now says a person did something a machine did, which makes every subsequent investigation harder than it needed to be. And the agent inherits everything that user can reach, which is invariably far more than its job requires.

An identity of its own, with permissions limited to the task, costs an afternoon at the start and saves the conversation where somebody has to explain to a regulator or an insurer why the system had access to records it had no business seeing.

A trail somebody will actually read

Most systems log something. Fewer log the thing you need, which is a narrative and never a stack trace: what came in, what the agent decided, which tools it called and what they returned, what it did, and why it stopped if it stopped.

The test is whether a colleague who was never involved can open one six weeks later and reconstruct what happened without asking anybody. If the answer is no, what you have is debug output, and the difference shows up on the first day somebody disputes what the system did.

Monitoring that notices silence

Error alerting is the easy half and teams almost always have it. The failure that costs more is the quiet one, where the agent stops doing anything at all and no error is raised because nothing errored. A webhook stopped arriving. A queue drained and never refilled. A credential expired and the call now returns an empty result instead of a refusal.

The alert that catches this is boring and everybody skips it: expected volume over a window. If a line that normally handles thirty jobs a day handles zero by lunchtime, something is wrong even though nothing has thrown. That single check finds more real outages than any dashboard I have built.

Handover is the only test that counts

An agent that only its builder can operate is in a relationship, which is a different arrangement from production. The handover is a property of the design and never documentation bolted on at the end, and you can tell within a week of starting which way a project is going.

What has to transfer is small. Somebody in the business needs to know how to read the trail, how to change what it handles, what makes it stop and fetch a person, who is on the other end of that, and how to switch the thing off. If turning it off requires the person who built it, it was never production.

What the Netherlands and the EU add to this

Nothing on the list above changes, but two items get sharper. The audit trail stops being good practice and becomes the thing you rely on when somebody exercises a right under the GDPR, in Dutch the AVG, or when the Autoriteit Persoonsgegevens asks a question. An agent that cannot say what it did with a person's data is a liability wearing a productivity badge.

The second is where processing happens. If your agent sends data to a model hosted outside the European Economic Area, that is a decision with safeguards attached, such as an adequacy decision or Standard Contractual Clauses, and somebody should have made it on purpose instead of inheriting it from a tutorial.

Beyond that, where the question is about the law rather than the system, it goes to a lawyer. I ship systems that keep a record, hand off to a person when they should, and stop where a human still decides, and I will tell you plainly where the line is.