What production-ready means for an agentic AI system: a checklist

“Agentic AI” covers everything from a chatbot with one tool to a planner coordinating a dozen workers. What separates a demo from a production system is not the number of agents. It is whether the system behaves predictably when things go wrong, and whether anyone can prove how it behaved.

This is the checklist we use before an agentic system goes live. Each item is something a client can verify.

1. Every tool has a typed contract

Each tool the agent can call has a validated input and output schema. Malformed calls are rejected before they touch a system.

How to check: send a tool call with a missing or wrong-typed field and confirm it is rejected with a structured error.

2. Every run has a budget and a timeout

Agents can loop. A run carries a cost ceiling and a time limit, and each stage has its own timeout. Retries are bounded, with backoff, and a circuit breaker stops a failing dependency from being hammered.

How to check: ask for the per-run cost report, and what happens when a downstream API is unavailable.

3. Permissions are the narrowest the task needs

Most agents should be read-only. Write access is designed explicitly, for specific actions, and anything not designed in is rejected by the system rather than by a prompt instruction.

How to check: ask which actions the agent can take that change something, and where that list is enforced.

4. Consequential actions wait for a person

Drafting, searching and analysing can be automated. Sending, filing, approving and writing to a system of record go through a named person, and their decision is recorded with the output.

How to check: find the approval step in the workflow and the record it leaves.

5. Quality is measured on an agreed task set

Before the build, agree a held-out set of representative tasks and how each is scored. Run it on every prompt, model or tool change, and block releases that lower the score. Where LLM-as-judge scoring is used, calibrate it against human review.

On our Saudi PDPL compliance platform, the LangGraph-based chatbot is evaluated with DeepEval and Ragas, and generated documents are held to a measured content fidelity rather than an impression.

How to check: ask for the evaluation set, the latest score and the score history.

6. Every call is traced and replayable

Every model and tool call is traced with its input, output, prompt version and cost. Configuration is snapshotted per run. A bad output can be reproduced and fixed instead of argued about.

How to check: pick a past run and ask to see every step it took.

7. Failures are loud and structured

A failed step produces a structured error and a dead-letter record with the input needed to reproduce it, never a plausible answer or a silent gap.

How to check: ask what the user sees when a step fails.

8. The model can change without the application changing

Model calls go through one gateway with a registry behind it. Swapping providers, or moving to a self-hosted open-weight model for cost or residency, is a configuration change.

How to check: ask how long it would take to switch the main model, and what would need retesting.

9. Someone who did not build it can run it

There is a runbook, a known-gaps register and an architecture document covering the request lifecycle, configuration surface and policies.

How to check: ask your own team to read the runbook and answer, “what do we do when it fails at 2am?”

A note on frameworks

Frameworks such as LangGraph are useful for stateful, multi-step workflows. They do not make a system production-ready on their own, and for simpler pipelines plain code with a clear runner is easier to test and operate. Choose per system, and write down why.

If you are evaluating an agentic AI proposal, this list is a reasonable set of questions to ask. It is also what our agentic AI engagements are built around.