Agent evaluation and assurance, answered in full.

Most commonly because there was never an evaluation, only a demonstration. Without a ground-truth set, agreed acceptance criteria and a release gate someone outside the build team can hold, the production decision becomes a negotiation with no evidence to settle it, and negotiations without evidence default to no. Three failures usually sit underneath: only the final answer was scored rather than the agent's trajectory, nothing was designed to monitor it after go-live, and no named person was asked to own the live system, its run cost and its incidents. Tenhaw pairs its builds with the receiving team for that reason. On a London specialty insurance proof of concept the client's engineer paired throughout and finished 70% confident they could run the process unaided.

Separate the two questions usually tangled together, whether it is good enough and who is receiving it. For the first, write the acceptance criteria the business owner would sign, then measure the existing system against them honestly, which is a two to three week piece of work that produces either a gate you can pass or a costed list of what is missing. For the second, name the person who will own the live system, its run budget and its incidents, and get them to agree the criteria before you re-test. Tenhaw names that receiver during the pilot rather than afterwards. Pilot purgatory is usually the second problem wearing the costume of the first, because teams keep improving a system nobody has been asked to take.

Scoring the sequence of steps an agent takes (which tools it chose, what it retrieved, how many steps it used, what it cost, and when it decided to stop) rather than only the final output. It matters because an agent can produce a correct answer through a process that is unsafe, unrepeatable or prohibitively expensive, and output-only scoring makes that invisible until production.

Yes, and it is one of the more useful things an external partner is for. An internal team recommending a delay is arguing against a date their own management committed to, with their next promotion in the room. Tenhaw has recommended against release at least once on every engagement it has run, usually where a launch date was being defended rather than a readiness assessment being made. If a supplier has never told you not to ship, that is information about the supplier rather than about your programmes.

Confidence derived from provenance rather than from the model's own certainty score. Tenhaw did exactly this on a live London specialty insurance engagement, scoring entity-resolution output by which third-party source the data came from, combined with model certainty and a search-based cross-check. Where the data came from gives you a defensible basis for routing before any labelled set exists, and it is explainable to the business owner, which a self-reported score is not. It is not a substitute for ground truth, and building one is still worth pushing for, but an organisation with no appetite for a labelling exercise is not stuck with nothing.

Someone outside the team that built the agent, with the standing to block a release. Tenhaw builds systems and designs the evidence but does not sell the gate. An engagement either side can end on thirty days' notice is the wrong permanent home for a decision your second line has to keep making. Where the build team owns the benchmark, the benchmark tends to describe what the system already does. This is an accountability question rather than a tooling one, and it is settled during operating-model design by mapping who decides, on what evidence, and who can overrule them.

The same criteria that gated the release, so degradation is comparable rather than anecdotal, plus cost and latency distributions and the rate at which humans override the agent. Override rate is often the most useful early signal, because it moves before accuracy metrics do and it is measured on real decisions.

Four parts, and they are more ordinary than the phrase suggests. A dataset of real cases with the answer a qualified person would accept, held under version control and grown every time something goes wrong in production. A runner that executes the system against every case reproducibly, pinning the model version, the prompts, the retrieval corpus and the tool permissions, because a result you cannot reproduce is an anecdote. Scorers, which are a mixture of exact checks, rule-based assertions and, for open-ended output, a model acting as judge. And a report a non-engineer can read, showing the score against the threshold, what regressed since the last run, and what each run cost and how long it took. The UK AI Security Institute's open-source Inspect framework is built around exactly that shape, datasets, solvers and scorers, which is a reasonable sanity check on any design somebody presents to you. The part people underestimate is the dataset, because it is the only part that cannot be bought.

Start with real cases pulled from the workflow itself, each paired with the answer a qualified person would accept, and build the set with the business owner rather than leaving it to the engineers. Agree the pass thresholds during design, so the set becomes the release gate rather than a retrospective justification. Keep it under version control alongside the prompts, model versions and tool permissions it exercises, and grow it every time something goes wrong in production, because live failures are exactly the hard cases the original set was missing. Runners and scorers can be adopted from open-source frameworks; a labelled set that reflects your own workflow is the part you have to make yourselves.

Monitoring tells you the system is running. Evaluation tells you whether it is right. An agent can be fully available and quietly getting worse, because model behaviour drifts, retrieval corpora change and the input distribution moves, and none of that shows up on an uptime dashboard. The fix is to carry the offline evaluation criteria into production, running degradation monitoring alongside availability monitoring, with alerting thresholds and the rollback decision agreed before go-live rather than during the first incident. Most programmes budget for evaluation before release and nothing for the two years afterwards, which is why degradation is so often discovered by users rather than by the team that built the system.

Start during design rather than after a demonstration, because the whole value is in agreeing what good means before there is a system to defend. Tenhaw agrees the ground-truth set and the pass thresholds with the business owner during design so they become the release gate, and publishes the method for doing it in full, free to adopt without hiring anyone. The four parts are offline evaluation against that set, trajectory scoring of the steps the agent takes rather than only its final answer, online monitoring once it is live, and a gate someone outside the build team can hold. The runner, the scorers and the report are ordinary engineering once the definition is settled.

You get a specific, costed list of what is missing, which is a better position than a vague sense that the system is nearly there. A fail usually names a class of cases the system handles badly rather than condemning the idea, and those cases go into the dataset so the next run measures the fix rather than the impression. Hold the release, or ship the cases that pass and route the rest to a person until a later run clears them. That choice is a business decision rather than an engineering one. Failing a threshold and missing a date are different problems, and the second should never be solved by quietly moving the first.

Not the full apparatus. Scale it to consequence, so a tool that drafts text a person reads and edits before it goes anywhere does not need an independent gate owner or evidence mapped to four regulatory regimes. Tenhaw grades its own engineering rules the same way, publishing 72 of them on GitHub with an RFC 2119 severity on each rather than equal weight. The light tier still needs a definition of good agreed before anything is built, a small set of real cases with the answer a qualified person would accept, and something watching for degradation, because model behaviour drifts whether or not the use case is risky. The heavier version earns its cost when a decision touches a customer, money or a regulator.

Yes, if it is specified that way at the start; otherwise the same work gets done four times. Tenhaw specifies that mapping at the start, and the client owns the inventory, evidence and code from day one. For a UK insurer, one design can answer four regimes. A model and decision inventory holding prompts, corpora, tool permissions and model versions with named owners is what model risk management asks for, and SS1/23 states that expectation for UK banks; insurers sit outside its formal scope and are asked anyway. Outcome measures emitted as the system runs are the Consumer Duty evidence. Degradation monitoring with an exercised fallback is what an impact tolerance rests on, and field-level provenance to source is the Solvency II data quality expectation.

It moves the argument earlier, to where it is cheap. Tenhaw builds the ground-truth set inside a retainer month that carries a value target, and a month that moves no number the client agreed is reported back as a failed month, so the set is built on the delivery clock rather than beside it. The thresholds are agreed during design alongside acceptance criteria you would be writing anyway. If you cannot state what good looks like, you cannot manage the work. Skip it and the production decision becomes a negotiation with no evidence to settle it, which is where programmes lose quarters. After the first run the harness makes delivery quicker, because a change is scored against every case at once.

Yes, and it is one of the better arguments for having a harness at all. A run pins the model version alongside the prompts, the retrieval corpus and the tool permissions, so changing any of them gives you a different system and the previous result no longer describes it. Re-run the same dataset, compare against the same thresholds, and read what regressed since the last run. Providers update and retire versions on their own schedule rather than yours, which is why the re-run wants to be a routine job somebody owns rather than a project somebody funds.

It hands over with everything else. On a Tenhaw engagement the exit date is agreed at kickoff, the final sixty days of a build run as a documented handover taper, and recruiting your permanent team is a stated deliverable of the retainer engagements. The dataset, the runner, the scorers and the report sit under version control in your own repositories, and the criteria that gated the release are the ones already monitored in production, so there is nothing to rebuild. What matters more is that a named person has been asked to own the live system, its run cost and its incidents, because if nobody has, evaluation quietly stops when the project does. Naming that receiver belongs in the pilot rather than afterwards.

Yes, and designing for that is part of the work. What qualifies someone to hold a release gate is independence and the standing to say no, not the ability to read the code. What the team needs is evidence it can act on: the score against the agreed threshold, what regressed since the last run, and what each run cost and how long it took, written for the audience that will ask for it rather than reconstructed under pressure later. Agree the criteria with risk during design instead of presenting results afterwards, and name the regime each artefact answers, so they are checking evidence rather than translating it.