An agentic workflow can perform well in a curated demonstration and still be unfit for production. The demonstration usually proves that a model can complete one happy path. Production readiness requires evidence that the whole system behaves acceptably across representative work, ambiguity, tool failures, permission boundaries, and human review.

Evaluate the workflow, not only the model.

That workflow includes retrieval, prompts, state, orchestration, tools, policies, approvals, connected systems, and recovery behaviour. A model change can affect the result, but so can a new document parser, API response, permission rule, or timeout.

Define the task before the metric

Start with a precise workflow statement:

Given these approved inputs, produce this output or bounded action, under these policies, within these operational constraints.

Then identify acceptable outcomes. A completed action may be correct, correctly refused, escalated for review, or stopped safely because required evidence is missing. Completion rate alone cannot distinguish these cases.

For each task type, define:

  • required inputs and source authority;
  • expected output or state change;
  • prohibited actions;
  • conditions for abstention or escalation;
  • acceptable latency and cost boundaries;
  • evidence needed to judge the outcome;
  • the person or rule accountable for final acceptance.

This creates an evaluation target grounded in the real process.

Build a representative test set

A useful set contains more than straightforward examples. Include:

  • common successful requests;
  • uncommon but valid variations;
  • incomplete and ambiguous instructions;
  • conflicting source material;
  • stale or inaccessible data;
  • malformed tool responses;
  • timeouts and partial failures;
  • requests outside the agent’s authority;
  • adversarial content inside user input or retrieved documents.

Preserve the expected decision and the evidence required to support it. For nondeterministic outputs, judge properties and outcomes rather than demanding one exact sentence.

Keep part of the set separate from day-to-day tuning. If every failing example becomes a prompt example, the team may optimise for the test collection rather than the workflow’s operating environment.

Evaluate across multiple dimensions

At minimum, assess:

Task outcome

Did the workflow complete the requested job, refuse correctly, or escalate appropriately? Was the final state of the connected system correct?

Grounding and source use

Were material claims supported by approved evidence? Were citations accurate? Did the agent notice missing or conflicting information?

Tool behaviour

Did it choose the correct tool, provide valid arguments, interpret the response correctly, and avoid duplicate actions after a retry?

Policy and permission compliance

Did it stay within the authorised data, tools, actions, and approval boundaries? A safety-critical failure here should not be averaged away by strong writing quality elsewhere.

Recovery and containment

What happened when a dependency failed? Did the workflow stop safely, preserve its state, and provide enough information for recovery?

Human review effort

How often did a person need to correct the result? Was the review material clear? Did the workflow reduce work, or merely move it into an opaque approval queue?

Operational behaviour

Track latency, cost, timeouts, retries, and variation between repeated runs where they affect the service objective.

Use per-dimension acceptance rules. One combined score can conceal a critical weakness.

Test the system in stages

Production exposure should increase through explicit gates:

  1. Offline replay: run historical or synthetic cases without calling live tools.
  2. Sandbox: exercise real integrations against non-production systems and test failure injection.
  3. Shadow mode: observe live inputs and generate outputs without affecting the active process.
  4. Limited pilot: involve a defined group, narrow use case, and mandatory review.
  5. Controlled production: grant only the authority supported by evaluation evidence, with monitoring and rollback.

Each stage answers different questions. Offline replay is efficient for regression testing. A sandbox exposes integration behaviour. Shadow mode reveals the shape of current traffic. A pilot measures real review effort and user acceptance.

Document the rule for entering and leaving each stage.

Evaluate actions at the final state

Tool-call syntax is not the same as task correctness. If an agent updates a ticket, verify the resulting ticket. If it schedules work, verify the final schedule. If an API times out, determine whether the remote operation completed before allowing a retry.

This final-state check is especially important for workflows with side effects. The observable business result is the ground truth, not the model’s description of what it believes it did.

Treat human feedback as labelled evidence

“Looks good” is difficult to improve from. Review interfaces should let people record why a result was accepted, edited, rejected, or escalated.

Useful correction labels include:

  • missing evidence;
  • incorrect source;
  • wrong tool or arguments;
  • policy boundary crossed;
  • incomplete task;
  • poor prioritisation;
  • unclear explanation;
  • unnecessary escalation.

This turns human oversight into a diagnostic signal for the next evaluation cycle.

Make evaluation repeatable

Version the workflow definition, prompts, model configuration, tools, policies, knowledge index, and evaluation set. Store run traces with sensitive data handled according to policy. Re-run critical tests when any material component changes.

Monitor production cases against the same dimensions used before release. New request patterns, source changes, and integration behaviour can shift performance without a model update.

A release decision, not a leaderboard

The purpose of evaluation is to decide whether a defined workflow may receive a defined level of authority. It is not to produce a flattering aggregate score.

A strong release review can say: the system drafts grounded responses reliably, uses read-only tools within policy, escalates ambiguous cases, and saves reviewers useful effort. It is therefore approved for a limited pilot, but not for unsupervised writes.

That is a more valuable result than calling the agent “production-ready” without specifying what production is allowed to mean.

Source notes for review