Six Fields Beginners Should Record Before Trusting an AI Agent

Six autocomplete suggestions appeared for “AI agent evaluation framework” on 2026-08-16, but that attention signal does not tell a beginner which agent to trust. Before buying or deploying one, record six fields in the same evaluation card: input, output, evidence, human approval, failure recovery, and stop condition. Run the first test with synthetic or approved non-sensitive information. If the agent cannot complete that narrow test without creating an uncontrolled action, stop the evaluation.

The three-line answer:

Record what enters the agent, what should come out, and what evidence supports the result.
Define where a person must approve the work and how a failed run will be recovered.
Set the stop condition before the test, not after an impressive demo.

This is a buying-decision playbook, not a certification method. The six-field card is a Builderlog teaching device. It is not an official template from OpenAI or NIST.

A polished demo leaves the important cells blank

An agent demo usually emphasizes the visible result. A report appears. A task moves. A message is drafted. The smooth ending can hide the harder questions: What information entered the system? Which claims can be checked? What happens when the output is wrong? Could the agent act before anyone notices?

That is why the six fields belong in one table. Separating them into scattered notes makes it too easy to inspect the output while forgetting approval or recovery.

The first evaluation should also be deliberately boring. Use synthetic or approved non-sensitive inputs. Do not let the example send, pay, publish, delete, or change permissions. The goal is to inspect behavior without creating a consequence that needs an apology later.

A useful agent evaluation begins with an action boundary, not a feature list.

The six-field evaluation card

Copy this card once for each task you want the agent to perform. Evaluate a concrete workflow, not the product’s general promise.

A filled card for a fictional “convenience store BOGO deals app” might define a narrow task: turn synthetic product records into a draft comparison table. The expected output is a structured draft. Evidence consists of references back to the supplied records. A person reviews the draft. Nothing is published or sent.

That example can pass only the stated test. It does not prove production safety, accuracy, reliability, compliance, savings, or revenue.

[Comparison diagram: A single row flows from approved input to draft output, evidence review, human approval, and either acceptance or recovery. A stop marker sits before every external action.]

Evidence is broader than an accuracy score

The OpenAI Evals API reference describes an evaluation as testing criteria combined with a data-source configuration. It also exposes evaluation runs and statuses, allowing runs to be compared across models or parameters.

That structure is useful because it separates the test definition from the run. It does not promise that an evaluation predicts production outcomes. A passing run remains evidence about its criteria and data, not every condition the agent may encounter later.

The NIST AI Risk Management Framework Core places AI risk work under Govern, Map, Measure, and Manage. It says testing and evaluation should be documented before deployment and during operation. Its measurement guidance includes metrics, uncertainty, benchmarks, reporting, documentation, and independent review.

The NIST AI Metrology Center adds a practical constraint: measurement approaches and tools should fit the use case. In other words, the right evaluation depends on the decision and operating conditions. A generic score cannot replace a task-specific acceptance test.

These sources support documented, use-case-specific evaluation. They do not validate this six-field card as an official standard.

A passing test is evidence about defined conditions, not permission to trust every future run.

Run the card before comparing products

Start by writing one sentence that describes the job. “Help with research” is too broad. “Convert approved synthetic records into a draft comparison table” is testable.

Next, prepare inputs that contain no sensitive information. Preserve a clean copy outside the agent’s reach. Write the expected output structure before running the test, including content that must never appear.

Then define the evidence requirement. If the output contains a claim, specify how the reviewer will trace it to the supplied material. Unsupported claims should remain visible as failures, even when the prose sounds plausible.

Place human approval before every consequential action. During the first example, the agent should produce a reviewable draft only. Sending, paying, publishing, deleting, and changing permissions remain outside the test.

Finally, simulate an ordinary failure. Provide an incomplete synthetic record or request a field that is absent. Observe whether the agent exposes the gap, invents an answer, or continues toward an action. Record the result without repairing the test halfway through.

Use the completed card to compare candidates under the same conditions. OpenAI notes that runs can be compared across models or parameters; the same principle helps with a buying decision. Keep the criteria and data stable while changing one candidate or configuration.

Stop conditions prevent demo momentum

A stop rule matters because evaluation can drift. Once a result looks promising, it is tempting to excuse a missing citation, unclear approval boundary, or awkward recovery path as something to fix later.

Use this checklist before continuing:

• Stop if the input source or permission cannot be explained.
• Stop if a required output cannot be judged with written criteria.
• Stop if an important claim cannot be traced to evidence.
• Stop if the agent can take a consequential action before human approval.
• Stop if the original state cannot be preserved or restored independently.
• Stop if the predefined failure condition occurs.
• Stop if the seller’s claim requires production proof that the evaluation does not provide.
• Stop if current documentation no longer matches the feature being evaluated.

A stop does not always mean the product is unusable. It means the current test does not justify proceeding. The next move may be to narrow the task, strengthen the evidence requirement, or choose a tool with a smaller action surface.

Write the rejection rule while you are still unimpressed.

The limits belong beside the result

This evidence packet was reviewed on 2026-08-16. The demand check returned six autocomplete suggestions for the exact query “AI agent evaluation framework.” Autocomplete is attention evidence only. It is not search volume, ranking, purchase intent, traffic, conversion, or revenue evidence.

A small test set can miss rare failures. It cannot represent every production context. Human review and a stop rule reduce uncontrolled action, but neither makes an agent safe by itself.

Model names, APIs, evaluation features, and pricing can change. Check the linked official documentation before purchase or deployment. This playbook includes no direct contact, third-party outreach, marketplace bid, comment, or message.

My final decision is simple: do not buy or deploy an agent for a consequential workflow until all six fields contain testable answers and the stop checklist remains clear. A persuasive demo is not a substitute for that record.

Copy the six-field card and complete it for one narrow, non-sensitive draft task before evaluating another feature.

Related build logs

• Six Fields Beginners Should Document Before AI Automation
• The OpenAI–Hugging Face Incident: 7 AI Agent Safety Checks for Beginners