TL;DR: Continuous evaluation for AI agents is a loop. Offline eval sets and persona based scenario tests run on every change, LLM judges and deterministic metrics score responses and tool calls, and release gates block regressions. Production traces close the loop, so every failed conversation becomes a permanent regression test. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing unclear value and inadequate risk controls (Gartner, 2025). ContextQA, the autonomous quality engineer, generates and runs agent tests for responses, guardrails, and tool calls inside your CI/CD pipeline.
Most agent failures surface in production conversations that no offline test anticipated. This guide shows engineering leaders and QA leads how to build a loop that stops prompt and model changes from shipping on gut feel.
Quick answers
How does a failed production conversation become a permanent regression test for an AI agent? Capture the full production trace: user turns, retrieved context, tool calls, and the agent response. Label the correct behavior, mask sensitive data, and convert the trace into a replayable scenario with an expected outcome and a judge rubric. Add it to the offline eval set so every prompt, model, or tool change must pass it in CI.
What should a release gate for an AI agent actually check before a deploy goes out? A useful gate runs the eval set and scenario suite against the candidate build and compares scores to the production baseline. Check task success rate, tool call correctness, and guardrail violations, with zero tolerance for regressions on previously failed production cases. Fail the pipeline on any drop beyond the agreed margin.
How do offline evals and production monitoring split the work? Offline evals are versioned test sets and persona scenarios that run before release, so builds are compared on identical inputs. Production monitoring samples live traces, scores them with the same judges, and flags failures or drift. The loop closes when flagged failures are triaged and added back to the offline set.
What is continuous evaluation for AI agents and when do you need it?
Continuous evaluation is the practice of scoring an agent's behavior against versioned test sets on every change and against sampled production traffic after release. It runs as a loop: production failures become new test cases, and release gates block regressions before users see them.
Traditional tests assert exact outputs with assertEquals(expected, actual). Agents are nondeterministic, so the same prompt can produce different wording, tool call order, or reasoning paths. Evaluation uses graded checks instead. Did the agent call refund_order with the right ID, stay inside policy guardrails, and resolve the user's goal? Teams track pass rates across many runs.
You need it when any of these are true:
- Prompts, models, or tools change weekly. A model version bump can shift behavior with no code diff.
- The agent takes actions. Tool calls that write data, issue refunds, or book appointments need regression coverage.
- Production conversations have already surfaced failures. Each one is a test case you have not written yet.
What do you need before you start?
You need four things: a versioned eval set of real conversations, production trace capture that includes tool calls, a scoring method you trust (rules, LLM judges, or human review), and a CI/CD job that can block a release when scores drop below a threshold.
The scoring method shapes everything else:
- Deterministic checks: Assert on tool call names, arguments, JSON schema, and banned phrases. Fast and stable in CI, but blind to tone and reasoning.
- LLM as judge: A second model grades responses against a rubric such as "resolved the refund without inventing policy." It covers open ended answers but costs tokens per run and needs calibration against human labels.
- Human review: Most accurate on edge cases, and too slow for every pull request. Use it to label new failures and audit the judge.
Store cases in a file like evals/cases.jsonl and run them on every pull request that touches prompts, tools, or model config.
Bottom line: Start with deterministic checks in CI, add a calibrated judge for open ended quality, and reserve humans for labeling.

How do you set up the evaluation loop step by step?
Set up the loop in five steps: build an offline eval set from real conversations, add scenario and persona tests, score every run with judges and metrics, convert failed production traces into new cases, and gate releases on the results.
- Seed the eval set. Export real conversations into
evals/golden.jsonl, each with an expected outcome and the tool calls the agent should make. - Add scenarios and personas. Cover the impatient user, the vague request, and a prompt injection attempt (input that tries to override the agent's instructions).
- Define judges. Use deterministic checks for tool calls and output schemas. Add an LLM judge for correctness and tone.
- Convert failures. Label each failed production trace and append it to
golden.jsonl. - Gate the release.
agent-eval:
stage: test
script:
- node scripts/run-evals.mjs --suite evals/golden.jsonl --judges evals/judges.yaml
- node scripts/gate.mjs --min-pass-rate 0.95 --max-new-failures 0
Observability platforms trace and score conversations well. The deciding question is whether those evals run in CI next to your other suites. ContextQA's AI agent testing checks responses, guardrails, and tool calls alongside your web and API tests.
What are the most common mistakes?
The most common mistakes are tracking one blended score, freezing the eval set after launch, trusting an uncalibrated LLM judge, and running release gates that cannot block a merge. Each lets regressions reach users while dashboards stay green.
- Single blended score: One "quality" number hides which dimension broke. Track task success rate, tool call accuracy, hallucination rate, p95 latency, and cost per task separately, each with its own threshold.
- Static eval set: If no production trace has entered the set since launch, you are testing last quarter's users. Convert every failed conversation into a regression case within the sprint.
- Uncalibrated judges: An LLM judge drifts as prompts and models change. Compare a weekly sample against human labels before letting it gate releases.
- Advisory gates: Evals that never fail the build become noise. Block the merge when any metric crosses its limit.
Bottom line: Score each metric separately, feed production failures back weekly, and make gates blocking.
How do you know it is working?
The loop is working when the same production failure never ships twice. Watch five numbers on every release: task completion rate, policy violations, flaky rate across repeated runs, p95 latency, and time to detect a regression. If they hold steady through prompt edits and model swaps, the loop is doing its job.
Keeping the golden dataset honest:
- Version it in the repo. Store scenarios next to prompts, for example
evals/golden/*.yaml, so every prompt diff has a matching eval diff. - Tag each case by origin. Labels such as
scripted,adversarial, ortrace:<id>show how much coverage came from production. - Promote failures and retire stale cases. Add every escaped conversation with an expected outcome and a judge rubric. Each quarter, prune cases that test retired flows.
A drift check you can run this week: Take one support agent and 30 scenarios. Run them against three versions (baseline, prompt tweak, model swap) with three repeats each, for 270 CI runs. The spread between repeats tells you how much margin your gate thresholds need.
How do you automate continuous evaluation for AI agents with ContextQA?
ContextQA automates the testing part of the loop by generating test suites that check agent responses, guardrails, and tool calls, running them in parallel inside your CI/CD pipeline, and maintaining them as the product changes. Engineers drive it from Claude Code, Cursor, or Codex through the ContextQA MCP server, so evaluation lives where code ships.
A practical workflow:
- Generate: From your IDE, point the MCP server at a ticket or spec. ContextQA produces agent tests covering happy paths, edge cases, and failure states.
- Capture failures: Write the failed production conversation and its expected behavior into a ticket, then generate a regression case from that ticket.
- Gate releases: Add the suite as a CI step so a broken guardrail or wrong tool call blocks the merge. Triage with root cause analysis.
- Stay portable: Export web flows through code export to Playwright.
Automated judges vs. human review: Use automated judges to score every build at scale. Reserve human reviewers for calibrating the judge and for policy, tone, and high stakes cases, because LLM judges can favor longer answers (Zheng et al., 2023).
If a failed production conversation never becomes a permanent regression test, your agent repeats it. See how ContextQA's AI agent testing checks responses, guardrails, and tool calls or book a demo and bring your hardest case.

What should you do right now?
This week, freeze a baseline eval set, wire it into CI as a release gate, and instrument production traces so failures surface within hours. Then every failed production conversation gets triaged, labeled, and added to the eval set as a permanent regression test.
- Export 50 to 200 real conversations into
evals/baseline.jsonlwith expected outcomes. - Define three to five metrics (task success, tool call accuracy, groundedness, refusal correctness) with pass thresholds.
- Calibrate your LLM judge against 30 human labeled samples.
- Run the suite on every prompt, model, or tool change, and block merges below threshold.
- Log every production trace with model version, prompt hash, and tool calls.
- Score a 1 to 5 percent sample of live traffic daily with the same judges, and alert when a 24 hour rolling score drops below baseline.
- Convert each flagged failure into a test case tagged with its trace ID.
Bottom line
Continuous evaluation for AI agents is a loop: offline eval sets catch known failures, persona scenarios probe new behavior, judges and metrics score each run, and production traces feed new cases back into the suite. Triage and labeling turn each failed conversation into a permanent regression test, and release gates enforce it. On Monday, pick one recent failure, turn it into a scored test, and block releases on it.
Sources
Read these primary sources directly before quoting their findings in planning documents.