Skip to content

Free · 4 minutes · nothing leaves your browser

Is your AI agent production-ready, or just working today?

12 questions on the things that actually cause incidents — not model choice or prompt style. You get a score out of 100, a breakdown across three pillars, and your gaps ranked by production risk with a fix and an effort estimate for each.

Reliability

Can you prove it still works after a change?

Cost & latency

Do you know what a conversation costs and how slow it gets?

Observability

When it fails at 2am, can you find out why?

Assessment questions

Question 1
1

Do you have an automated eval suite that runs when a prompt or model changes?

Not unit tests on your glue code — evals on the agent's actual outputs against known-good cases.

Why this question matters

No regression safety net on agent behaviour

Every prompt tweak is an unmeasured bet. You will ship a regression, hear about it from a customer, and have no way to tell which change caused it.

Fix: Freeze 30–50 real inputs with expected outcomes, score them with a mix of assertions and LLM-as-judge, and gate merges on the aggregate.

Effort: 3–5 days for a first suite that pays for itself immediately · Risk if unaddressed: critical

Question 2
2

Are your eval cases drawn from real production traffic?

Synthetic examples written by the team systematically miss the inputs that actually break agents.

Why this question matters

Evals do not reflect real user behaviour

Your suite passes while real users hit failures nobody imagined. Confidence goes up, quality does not.

Fix: Add a one-click 'capture this run as an eval case' path from your trace viewer, and make triaging new failures a weekly ritual.

Effort: 2–3 days once tracing exists · Risk if unaddressed: high

Question 3
3

Are prompts versioned and tied to the deployment that used them?

If a customer reports a bad answer from last Tuesday, can you reconstruct the exact prompt that produced it?

Why this question matters

Prompt changes are untraceable

Debugging becomes archaeology. You cannot reproduce a reported failure, so you cannot confirm a fix.

Fix: Treat prompts as versioned artefacts in git, stamp the version onto every trace, and make rollback a deploy-free operation.

Effort: 1–2 days · Risk if unaddressed: high

Question 4
4

Are tool-call arguments validated before execution?

Models hallucinate arguments: wrong types, invented IDs, out-of-range values, occasionally destructive ones.

Why this question matters

Hallucinated tool arguments reach real systems

This is the failure mode that causes actual damage rather than just a bad answer — wrong record updated, wrong customer emailed, wrong row deleted.

Fix: Validate every tool input against a strict schema, re-check authorisation server-side rather than trusting the agent, and require confirmation for irreversible actions.

Effort: 2–4 days, and the highest-value work on this list · Risk if unaddressed: critical

Question 5
5

Do you know the token cost of a single average conversation?

A number, not an estimate — attributable per feature, per tenant, or per customer.

Why this question matters

Unit economics are invisible

You cannot price your product, forecast spend, or tell which feature is quietly consuming the budget. Cost surprises arrive monthly.

Fix: Log token counts and computed cost on every call with feature and tenant tags, then chart cost per conversation as a first-class product metric.

Effort: 2–3 days · Risk if unaddressed: high

Question 6
6

Is there a hard ceiling that stops runaway spend?

Per-request token caps, per-user daily limits, a global circuit breaker — something that fails closed.

Why this question matters

No circuit breaker on spend

One looping agent, one adversarial user, or one bad deploy can produce a five-figure bill over a weekend. Alerts notify you after the money is gone.

Fix: Enforce max token caps per request, rate limits per user per day, and a global kill switch that degrades to a cheaper model or a queue rather than spending without bound.

Effort: 2–3 days · Risk if unaddressed: critical

Question 7
7

Do you route different tasks to different models by difficulty?

Classification, extraction, and formatting rarely need your most expensive model.

Why this question matters

Paying premium rates for trivial work

Usually the single largest recoverable line item — often 40–70% of spend on sub-tasks a much cheaper model handles at equal quality.

Fix: Classify tasks by required capability, route accordingly, add prompt caching on stable system context, and verify quality per tier with your eval suite.

Effort: 3–5 days, typically the fastest measurable ROI · Risk if unaddressed: medium

Question 8
8

Do you track p95 latency per agent operation, not just the average?

Averages hide the multi-step runs where users give up and leave.

Why this question matters

Tail latency is unmeasured

The average looks acceptable while a meaningful slice of users waits 40 seconds and abandons. Retries and multi-step chains live entirely in that tail.

Fix: Instrument per-step timing, alert on p95 by operation, and set an explicit latency budget that streaming or partial results must satisfy.

Effort: 2 days · Risk if unaddressed: medium

Question 9
9

Can you replay a single agent run end to end — every step, prompt, and tool call?

One trace ID that shows the whole decision path, not scattered log lines.

Why this question matters

No per-run trace

Every investigation starts from zero. Mean time to diagnosis is measured in days, and some failures are simply never explained.

Fix: Adopt step-level tracing (OpenTelemetry or a purpose-built LLM observability tool), propagate one trace ID across the whole run, and make traces searchable by user and outcome.

Effort: 3–5 days · Risk if unaddressed: critical

Question 10
10

Does your team have shared, named categories for how the agent fails?

"Tool argument hallucination" and "retrieval miss" are categories. "It was wrong" is not.

Why this question matters

Failures cannot be counted, so they cannot be prioritised

Without categories there are no rates. The team fixes whatever was complained about loudest rather than what happens most.

Fix: Name your failure modes, tag every incident against them, and review the distribution monthly. Fix by frequency times severity.

Effort: 1–2 days to define, ongoing to maintain · Risk if unaddressed: high

Question 11
11

Are outputs checked for policy, PII, and grounding before reaching the user?

Especially relevant if the agent touches customer, financial, or health data.

Why this question matters

Guardrails rely on the model following instructions

Prompt-based rules are advisory, not enforcement. One jailbreak or one unusual input and unreviewed content — or someone else's data — reaches a user.

Fix: Enforce checks in code outside the model: PII detection, policy classifiers, and grounding verification against retrieved sources. Log every block as a signal.

Effort: 3–5 days depending on regulatory surface · Risk if unaddressed: high

Question 12
12

Is there a named person accountable for whether the agent works?

Not the whole team, and not the person who happens to be on call.

Why this question matters

Agent quality is nobody's job

Reliability work loses to feature work every sprint, because features have an owner arguing for them and reliability does not.

Fix: Name an owner, give them explicit time, and have them report a small number of reliability metrics on the same cadence as product metrics.

Effort: An organisational decision, not an engineering one · Risk if unaddressed: high

About this scorecard

How is the score calculated?

Each of the 12 questions is answered on a 0–3 scale and multiplied by a weight reflecting how often that gap causes real incidents. The weighted total is normalised to 0–100 against a maximum of 87 weighted points, and reported per pillar as well as overall.

The weights are my judgement from production work, not an industry standard. The ranking of your gaps matters more than the absolute number.

Is my data sent anywhere?

No. The scorecard is plain JavaScript running in your browser on a static page. There is no backend to send anything to, no analytics on your answers, and nothing stored. Reloading the page loses your answers, which is the tradeoff for not storing them.

If you choose to send your result via WhatsApp at the end, that message is composed in your browser and you see it before it sends.

What is a good score?

Most teams shipping agents today land in the 30s or 40s on a first honest attempt, which is why the bands are set where they are. Above 75 is genuinely production-grade. Above 90 is rare.

If you score above 90 you almost certainly do not need to hire me, and I will say so.

Can I get the result as a PDF?

Yes — the results panel has a print button, and printing to PDF gives you a clean report with your score, pillar breakdown, and every gap with its fix and effort estimate. The print stylesheet strips the navigation and interactive controls.

It is deliberately a browser print rather than a generated file, so nothing has to be uploaded to produce it.

Rather have someone else do this properly?

The scorecard is the self-serve version of the first week of an audit. The paid version runs against your actual code and traffic instead of your recollection, and produces an eval suite your team keeps.