Golden Task Sets: A Versioned Test Bed for Agent Evals

A golden task set is a small, versioned collection of real tasks from your business, each paired with a known correct outcome and a clear pass rule. You run the same set against an AI agent before and after every change to its prompts, model, tools, memory or permissions, so you can see whether the agent improved, regressed or stayed the same. The method is simple, but it depends on discipline: real tasks, outcomes approved by the person accountable for the work, and a set that changes only through recorded versions.

Key takeaways

• A golden task set is a short list of real work items with agreed correct outcomes. It is not a generic benchmark.
• Choose tasks from the work your team actually does, and give extra weight to cases where a wrong answer is expensive.
• Write each expected outcome as an observable state or decision so that a grader can check it without guessing.
• Version the tasks, the grading rules and the agent configuration together, and run the set before and after every change.
• Grow the set only when production shows a failure it does not cover, and record every addition.

What a golden task set is, and what it is not

Public leaderboards measure general ability on standardized problems. Your agent does not operate in a standardized world. It works with your customers, your documents, your tools and your approval rules. A golden set measures whether that specific agent completes your specific work correctly. The word golden means the reference answers were checked by someone accountable for the outcome, so the set can serve as a trusted reference point when everything else is changing.

A golden set is also not a stress test of every possible input, and it is not a production dashboard. It sits between those two. It is small enough to run on every change, and it is built from cases that matter. Production monitoring tells you what is happening now. The golden set tells you whether a change made the agent better or worse on the work you already know it must get right. Teams that skip this step usually discover regressions when a customer or an auditor finds them first.

For background on how evaluations are structured for agents, the guidance on demystifying evals for AI agents and the OpenAI evals guide both describe the core ideas of tasks, graders and repeated runs. The practical work is in the choices described below.

How do you choose the tasks?

Start from real requests, not imagined ones. Pull the last several weeks of inputs the agent handled or would handle, from the inbox, the ticket queue, the shared drive or whatever channel the work arrives through. Then select tasks across four groups: routine cases that make up most of the volume, edge cases that caused confusion before, high-cost cases where an error creates rework or exposure, and cases where the correct action is to refuse, ask or escalate.

The last group is the one teams most often leave out. An agent that answers every question is not reliable. A useful set includes requests that fall outside the agent's authority, because those tasks check whether it stops at the right boundary. For a decision on where that boundary should sit, the guide on where an AI agent should stop and ask is a useful companion.

Coverage matters more than count. A few dozen well-chosen tasks usually reveal more than hundreds of near-duplicates. Remove any task that cannot be graded, and remove any task whose correct answer is disputed inside the team. Those tasks belong in a discussion, not in the set.

A task that nobody can agree on is not a test. It is a question to settle first.

Illustrative scenario: a logistics coordinator at a regional distributor wants an agent to answer customers who ask where their shipment is and to flag delivery exceptions. The coordinator exports recent customer messages, groups them by type, and keeps the messages about delayed customs clearance, damaged pallets and address changes, since those cause the most follow-up work. She also adds two messages asking for a refund, where the correct action is to route to a person. The first draft of the set covers eleven situations, and each one has a named owner who will approve its expected outcome.

How should each task define the correct outcome?

Every task needs five fields: the input, the starting state of the systems involved, the tools the agent may use, the expected end state or decision, and the grading rule. The expected outcome is the field most often written badly. Phrases like sounds helpful or addresses the customer are not checkable. Better phrasing names the observable result: the ticket status is set to awaiting customer, the draft contains the tracking reference and no internal cost figures, the agent requested approval before sending the message, or the case was routed to the refunds queue with the original message attached.

Separate outcome checks from quality checks. Outcome checks are usually deterministic: a field has a value, an action did or did not happen, a forbidden item is absent. Quality checks, such as clarity or tone, need a reviewed rubric, and reviewers should agree on it before scoring. Where a deterministic check is possible, prefer it, because it gives the same answer on every run.

Record who approved each expected outcome and when the approval was given. This record is what makes the set golden. If the operations lead cannot explain why an answer is correct, the grader will eventually reward the wrong behavior, and no one will notice until a customer does.

• Input: the exact message, document or event the agent receives, with personal data reduced to what the task needs.
• Starting state: the relevant record, status and permissions at the moment the task begins.
• Allowed tools: the actions the agent may take in this task, matching its current permissions.
• Expected end state: the observable result or decision that counts as correct.
• Grading rule: deterministic check, reviewed rubric, or both, with the name of the approver.

How do you version the set and the agent configuration together?

Store the golden set in the same controlled place as the rest of the agent's documentation, such as a version-controlled repository or a document system with change history. Give the set a version label, and treat any change to a task, a grader or an expected outcome as a new version. Never edit a task silently. A silent edit makes last month's results impossible to compare with this month's, which defeats the purpose of the set.

Record the agent configuration next to each result: the model identifier, the prompt version, the list of tools and their scopes, the memory or knowledge snapshot used, and the permission set. When a score changes, you need to know whether the cause was the model, a prompt edit, a new tool or a changed knowledge document. Without this record, a drop in results turns into an argument about what changed.

Keep a short change log for the set itself. Each entry should say what was added or removed and why. Additions usually come from production failures, which is a good sign, because the set is learning from real problems. Removals should be rare and explained, since a task removed because the agent keeps failing it is hiding a defect.

How do you run the set before and after every change?

The routine is the same whether the change is a prompt edit, a model update or a new tool. Keep it short and repeatable, so nobody skips it under deadline pressure.

• Freeze the current configuration and run the full set against it. This run is the baseline.
• Run each task more than once when outputs vary between runs, and record the spread, not only the best result.
• Apply one change at a time, so that any difference in results has a single likely cause.
• Run the same set, with the same graders and the same version label, against the candidate configuration.
• Compare results task by task. List every task that moved from pass to fail, and read those cases before looking at the averages.
• Decide whether to adopt, adjust or roll back, and write the reason next to the configuration version.
• Add any production failure from the period as a new task in the next version of the set.

The last step closes the loop. A set that is never updated from production slowly stops measuring what matters, while a set that absorbs every surprise becomes too large to run on each change. Balance the two by adding a small number of high-value tasks each cycle and retiring only those that no longer reflect the work.

How do you read the results without fooling yourself?

An average pass rate can hide the failure that matters. A change that improves routine requests while breaking a single approval rule may still look positive on the overall score. Reading results needs a few firm rules, and it helps to write them down before the first run, so nobody argues them afterward.

• A regression on any task tagged high risk blocks the change until a named person has reviewed it.
• Gains on routine tasks do not offset losses on tasks involving approvals, personal data or money.
• A change that passes but uses noticeably more steps or tool calls goes to review before adoption, since cost and latency often move together with behavior.
• A task that passes sometimes and fails sometimes is fixed or clarified. It is never averaged away.
• Scores are reported by category, so the team can see which kind of work improved and which did not.

These rules connect the golden set to operating decisions. The set tells you what changed. The rules tell you whether the change is acceptable. Teams that keep both in one place make faster and calmer decisions when an update arrives from a model provider or a tool vendor.

How Be Human handles this in managed operations

In a Be Human engagement, the first golden set is built during the initial definition of the agent's role, using the tasks that the client's owner selects and approves. Be Human keeps the set under version control alongside the agent's configuration, and reruns it before changes to the model, prompts, tools or permissions. In managed operations, the set also runs on a recurring schedule, and failures feed incident review and the next version of the set. The approach does not promise a particular score. It makes each change measurable against the work the business has already decided matters.

If you are not sure which of your agent's tasks deserves a golden test first, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

How many tasks should a golden set contain? A useful first set is small enough that its owner can read every task in one sitting, often a few dozen. Coverage matters more than the total, so choose tasks across routine work, edge cases, high-cost cases and cases where the agent should stop. Add tasks when production exposes a gap, not to make the number look larger.

Who should approve the expected outcomes? The person accountable for the work should approve them, such as the operations lead or the team lead who would sign off on a human doing the same task. Engineers can build the harness and the graders, but the reference answers need business ownership. Otherwise the set measures what is easy to check rather than what the business needs.

Can a golden set use real customer data? Only with care. Keep the minimum personal data needed to reproduce each task, redact the rest, and limit who can read the set. The guide on data minimization for AI agents covers how to decide what an agent should see in the first place.

How often should the set be rerun? Run it before every change to the agent's model, prompts, tools, knowledge sources or permissions, and also on a regular schedule in production to catch drift. The schedule should match how quickly your inputs change. A set that is never rerun cannot tell you whether today's agent still matches yesterday's approval.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.