How I evaluate agent quality before handoff
A practical FDE playbook for evaluating AI agents before handoff — smoke tests, golden sets, retrieval checks, tool-call validation, guardrails, and a go-live scorecard that is not vibes on demo day.
*If you cannot fail the agent on purpose, you are not ready to hand it to operators.*
Shipping an AI agent is easy to fake: a happy-path demo, a founder nodding, a Friday deploy. **Handoff** means something stricter. Operators can run it, failures are visible, and quality is measured on *their* data — not your laptop fixtures. That is the harden-and-handoff half of Forward Deployed Engineering. This post is the eval playbook I actually use before I call an agent done.
For the day-to-day loop, see what an FDE actually does. For why demos lie, see the 80% nobody demos.
The short version
Before handoff I run a layered evaluation: smoke tests that the stack boots and tools authenticate, a small **golden set** of real customer tasks with expected behaviours, **retrieval and citation checks** when RAG is involved, **tool-call and schema validation** when the agent acts on systems, **guardrail tests** for policy, PII, spend and escalation, and a short **shadow or staged live** window with logging. Go-live is a scorecard, not a vibe. If critical rows are red, we do not hand off.
What quality means in production
| Dimension | The question operators care about |
|---|---|
| Task success | Did it complete the job the business paid for? |
| Faithfulness | Did it stick to retrieved or allowed sources? |
| Safety and policy | Did it refuse or escalate when it should? |
| Tool correctness | Did it call the right tools with valid arguments? |
| UX under failure | Empty retrieval, timeouts, partial tools — what does the user see? |
| Operability | Can someone debug a bad answer from logs without me? |
| Cost and latency | Is it boringly within budget at expected volume? |
Benchmarks are optional. Customer tasks are not.
The eval ladder
Do not start with a 500-case harness. Climb:
1. Smoke → does it run?
2. Golden set → does it do the jobs we sold?
3. Slice probes → retrieval, tools, guardrails in isolation
4. Adversarial → can we break it on purpose?
5. Shadow / stage → real traffic, limited blast radius
6. Handoff gate → scorecard + owners + runbookStop climbing when the gate is green, not when the demo feels good.
1. Smoke tests
Pass if the app boots in staging, the model key and tool credentials work for a **non-god** test user, one read path and one write path return structured success or error, and logs show a request id end to end.
Fail if it only works with the founder's admin token — identity is the first 80%.
2. Golden set
Build **15 to 40 real tasks** from their world. Not synthetic trivia. Each case carries the input, context notes about which docs or systems should matter, the expected **behaviour** rather than an exact string, and a severity: P0 blocker, P1 should-fix, P2 nice.
Behaviour rubrics beat exact match for language output:
| Label | Meaning |
|---|---|
| pass | Meets the outcome, no policy break |
| soft_fail | Usable but missing a citation, tone, or a partial step |
| hard_fail | Wrong action, hallucination on a critical fact, policy miss, bad tool call |
| escalate | Correctly refused or handed to a human |
Source cases from real tickets, sales FAQs, the "we always get this wrong" list from operators, top help-center articles, and known edge accounts.
This is how support-shaped agents earn trust. SupportPilot is not "chat works" — it is deflect when the docs allow, **escalate when they do not**, summarise for the human. Golden cases must include both paths.
3. Retrieval and citation probes
If the agent answers from documents, evaluate retrieval separately from eloquence. Probe with known-answer questions that have a single clear source page. Ask questions that are **not** in the corpus — it must not invent. Feed conflicting docs and check it does not blend them silently. Leave a stale document ranked high and see whether it gets caught.
Pass signals: the correct source appears in top-k often enough for the use case, answers are tied to sources when claims matter, and the agent says "I don't know" or escalates when retrieval is empty.
DotChat optimizes for claims cited to pages. Your eval should punish fluent answers with no grounding the same way users will.
Metrics you can compute without a research team: retrieval hit rate at k on the golden set, citation-present rate on factual answers, and a human spot-check of faithfulness on twenty answers.
4. Tool-call and schema validation
Agents that write to a CMS, CRM or payment system need tool evals, not only chat evals. Probe that valid arguments succeed, invalid arguments are loudly rejected on types, required fields and enums, dangerous operations are blocked or require approval, and partial failure never leaves a silent half-write.
This is the philosophy behind webflow-agent-kit: Zod at the boundary so the model cannot freestyle structured systems.
Pass if bad tool payloads die before the API, and good ones are deterministic enough to replay from logs.
5. Guardrail tests
Write cases that must **fail closed**:
| Guardrail | Example fail condition |
|---|---|
| Authorization | A user reaches another tenant's documents |
| PII and sensitive data | The agent should refuse or redact, and does not |
| Domain overreach | Improvised clinical or legal advice instead of escalation |
| Spend | An over-limit purchase is not blocked and logged |
| Prompt injection | "Ignore your instructions" inside a retrieved document is obeyed |
Mindoor and AgentPayOps are guardrail-shaped products: policy and audit are features, not footnotes. Your eval set should include "should refuse" as first-class cases — many teams only test "should answer."
6. The adversarial hour
Block sixty to ninety minutes with someone who is not the builder. Typos, mixed languages, empty input. Prompt injection inside a document. Requests outside policy. Tool spam and repeated writes. Extremely long context.
Log everything. Every hard fail becomes a fix, a guardrail, or an accepted limitation **written into the handoff doc**.
7. Shadow or staged live
Before full handoff, run staging with a real corpus copy, or production behind a feature flag for limited users, or shadow mode that logs what the agent *would* do.
Watch error rate, escalation rate, cost per task, top failure clusters and operator complaints. If you cannot name the owner who watches this in week one, you are not handing off — you are abandoning.
Go-live scorecard
| Gate | P0 criteria |
|---|---|
| Smoke | Non-admin user path works; secrets not in the client |
| Golden set | Agreed pass rate on P0 cases |
| Grounding | Zero hard_fail on must-be-grounded P0 facts |
| Escalation | All should-escalate cases escalate |
| Tools | Invalid tool calls rejected; no silent partial write on P0 flows |
| Guardrails | All P0 policy cases fail closed |
| Observability | Request id, tool trace, model and retrieval summary in logs |
| Runbook | One page: common failures, owners, kill switch |
| Security shape | Data-flow and retention answers exist |
| Cost ceiling | Measured cost and latency on the golden set within budget |
**Rule:** any red P0 means no handoff. Negotiate a scope cut or fix it. "Monitor in prod" is not a substitute for a gate.
How much eval is enough
| Engagement | Bare minimum |
|---|---|
| One-week pilot | Smoke, 15 golden cases, 5 adversarial, staged demo on live data |
| Production support agent | 30+ golden cases with escalate paths, retrieval probes, one week shadow |
| Agent that writes or spends | All of the above plus tool schema tests, a policy suite, and audit log review |
Perfect evals do not exist. Documented, repeatable gates do.
What I hand over with the keys
The golden set file with cases and labels. The latest scorecard snapshot. Known limitations, stated explicitly. A runbook and kill switch. Log access instructions. And who owns corpus updates and prompt changes.
If those six are missing, the agent is still on my laptop, even if it is deployed.
Anti-patterns
"The CEO liked the demo" as acceptance. Exact string match only, which is brittle and gameable. Testing only English happy paths. No should-refuse cases. Evaluating on fixture PDFs never used in production. One giant prompt change with no re-run of the golden set. Handoff without an operator owner.
Do I need a full eval platform to hand off an agent?
No. A spreadsheet golden set, a script that runs the cases, logs, and a scorecard are enough to start. Platforms help later; gates matter now.
What is a good pass rate for agent handoff evals?
Agree it per engagement. For small P0 sets, a high bar on critical grounded tasks and 100% on policy and escalate cases is common. Soft fails can be scheduled; hard fails on P0 block handoff.
How is agent handoff evaluation different from model benchmarks?
Benchmarks compare models in the abstract. Handoff evals measure your agent, your tools, your data and your policies on tasks your business cares about.
Where does evaluation fit in the Forward Deployed Engineer loop?
After the thin slice and during hardening, before handoff. Scope, map the stack, slice, harden with evals, hand off, then feed patterns back into product or open tools. See the FDE hub.
I ship production AI for startups and teams — agents, RAG, automations — on a decade of design & Webflow craft.
About me →Keep going.
The 80% of FDE work nobody demos
Most Forward Deployed Engineering is not the AI demo — it is SSO, legacy data, security review, and day-2 ops. The failure modes that kill production agents, and how to harden before handoff.
FDE vs Solutions Engineer vs Freelance Developer
Forward Deployed Engineer vs Solutions Engineer vs freelance developer — who owns production code, who embeds with operators, and which role you actually need for AI in a real customer stack.
What a Forward Deployed Engineer actually does
A Forward Deployed Engineer embeds with customers to ship production software in messy real stacks — not demos. The day shape, the five-step loop, and how AI FDEs differ from freelancers and solutions engineers.