Define agent success before writing the prompt

This is lesson 2 of Production AI Agents. Define one expected result for every eligible case before trying prompts. Grade the actual workflow state, keep missing outcomes in the denominator, and record unauthorized effects independently of answer quality.

You have bounded the assistant's job. Now write the checks that will tell you whether its next iteration helps the support team.

Part one: a sentence is too small a unit of success. Imagine two runs on case C01.

Both finish with "I requested your replacement." The first has a receipt from the replacement service, while the second called a tool with the wrong serial and received an error. Grading the final sentence would give them the same result.

A task is the customer job you are evaluating; a trial is one attempt to perform that task; a trace records the observations and calls during the trial; and an outcome records what the system and the customer workflow actually contain afterward. You need all four, but they answer different questions. The outcome establishes success, while the trace helps explain failure.

For this course, one task is deciding and recording the next step for a support case. A successful replacement task ends with exactly one accepted replacement request, for the correct case and serial, which does not establish physical dispatch or delivery, while a successful clarification task records the missing field and routes the case for a response, so define that boundary before selecting a metric.

Part two: build the manifest first. An evaluation manifest is the list of cases that were meant to run.

It prevents a broken runner from improving its score by omitting difficult inputs. Assign stable identifiers, and record the expected outcome separately from the input the model receives.

Here are four cases. C01 is an eligible pump with a known serial, and expects a replacement request with a service receipt. C02 is missing its serial and expects clarification, C03 has its coverage excluded and expects a denial with the applicable policy, and C04 raises a safety concern, which needs a human handoff with a durable queue entry. For the last three, the evidence must also show no replacement.

These are four illustrative cases, not the full twelve-case release packet used later. Keep the populations separate. Four hand-authored examples teach the metric; they cannot establish a production error rate.

Write the expected next step before looking at the agent's answer, otherwise you are likely to reinterpret the task around whatever the agent happened to do. If the case is ambiguous, label the evidence gap and agree how it will be handled. Do not invent a reference answer just to make the spreadsheet complete.

Part three: put safety beside correctness. The diagram in the lesson joins the expected case manifest to the observed outcomes, by case ID.

The manifest contributes one result per case, and the observed outcomes include incomplete trials. From the join, two separate checks run: a task success check that the required result is present, and an authority check that inspects every effect.

The success check passes counts and slices to the release decision, and the authority check reaches the same decision, where a violation can block release. That lower branch prevents a dangerous action from disappearing into an average.

An agent that first changes an unauthorized case, and then produces the correct final answer, still failed the authority check. A cleanup action does not erase the earlier effect from the evaluation.

Use deterministic checks wherever the requirement is exact: the case identifier, the policy version, the number of effects, the presence of approval. A model reviewer can help assess whether an explanation is useful, but it cannot override a wrong case ID because the answer sounds good.

The task-success numerator counts cases that met the expected next step without unauthorized effects. The denominator is all eligible cases in the manifest. Report incomplete cases separately. Later, when you repeat each case several times, keep case coverage apart from trial reliability, because ten retries of the easiest case are not ten new cases.

Part four: a missing result is still work that you owe. Suppose a four-case run produces two correct next steps, one wrong next step, and no result for C04.

The observed task success is 2 out of 4. You may also report 2 out of 3 among the returned results, but that conditional fraction cannot replace the main score. The missing case may be the one that entered an infinite loop.

Apply the same discipline to cost. Attempts on incomplete work consume resources, so if you have a complete attempt ledger, include their spend. If part of the ledger is missing, call the known sum "recorded spend", and explain that the true total remains unknown. A default zero would make a telemetry failure look efficient.

Your turn. Pause the video here. Create a result sheet for the four cases. C01 has one valid receipt, C02 asks for a serial, C03 requests a replacement despite the exclusion, and C04 has no result by the evaluation cutoff. State the numerator, denominator, incomplete count and unsafe-effect count.

Two of four cases succeeded, and one is incomplete. C03 contains one unauthorized replacement request, under the exercise policy. Holding the release is justified, even if the customer-facing text is polite in every returned answer.

Now change the input: add a second C01 result, from an automatic retry. Reject it, or explicitly group the duplicate under the same task and trial identifiers. Do not add a fifth eligible case. The case manifest still contains four customer jobs, and a second effect on C01 would require investigation.

To recap. Join observed results to the expected manifest, inspect unauthorized effects even when the final answer is correct, and keep missing outcomes and their known spend visible.

That's lesson 2. Next in the series: retrieve the policy that applies to this case. The full lesson, with its exercise and drill, is on fdeinterviews.com.