How to Evaluate AI Agents in a Patient World

Evaluating an AI agent in a patient world means reading the path, not only the final answer. The path includes what information the agent gathered, how it treated uncertainty, whether its actions were permitted, how it used evidence the world actually disclosed, whether it respected state transitions, and what differed across branches. A polished conclusion can hide a bad path. A careful path can end in a commit you still disagree with. Evaluation has to be able to see both.

The usual score, in a chat, is whether the last message looks right to a reader. That score measures writing under a pasted vignette. It does not measure whether the agent asked for a fact it lacked, invented a fact the world had not disclosed, or committed an action the policy should have rejected. Patientic is being built so those distinctions are stored in the environment, where an evaluation can point at events instead of impressions. This is a method for simulation. It is not a method for grading real clinical decisions.

Start from the world, not the paragraph

An evaluation that starts from the paragraph will launder the paragraph's assumptions. If the vignette already contained every fact, gathering information was never possible, and you cannot praise or blame the agent for it. If the policy lived only as a sentence in the prompt, a violation is a matter of tone, and two reviewers will disagree about whether the tone was careful enough.

Start from the world. Fix the patient state, the scenario, the seeds, and the policy version. Those belong on the receipt, because an evaluation that cannot name them is an evaluation of a moving target. The argument for recording them is in Why Every AI Patient Run Needs a Simulation Receipt. With the world fixed, the agent's proposals become comparable events: accepted, rejected, or answered with a narrower disclosure than requested.

The environment is what makes the events comparable. An agent needs permissions, inspectable state, and consequences, or the "event" is just another sentence. That requirement is the point of AI Agents Need Environments, Not Just Context Windows. Evaluation inherits it. You cannot grade a gate that was never closed.

Six readings of the same run

One run supports more than one question. Collapsing them into a single score hides which question you actually answered. The readings below are separate on purpose. An agent can do well on one and poorly on another.

Information gathering is visible only if hidden facts exist and requests are logged. An agent that narrates "I would review the history" has not gathered anything. An agent that issues a permitted request and receives a disclosure has. The evaluation cites the request and the disclosure, not the narration. If the world had nothing left to disclose, say that, and do not invent a gathering task the scenario never contained.

Uncertainty is the complement. Before a disclosure, the agent should not be credited for reasoning that uses the hidden fact. After the disclosure, using it is fair. The history has the timestamp. This is a stricter test than "sounded unsure," which any model can perform with a few caveats while smuggling the answer into the next sentence. The state either contained the fact for that actor or it did not.

Permitted actions are a policy reading. Count accepted commits and rejected proposals. A rejection is not a footnote. An agent that immediately rephrases the same rejected action is failing a constraint, even if the eventual accepted action looks fine. The environment's job is to keep the rejection in the log so the evaluation cannot forget it. A transcript that only shows the successful retry has edited the failure out.

Evidence use ties commits to disclosures. The question is mechanical: for a fact the commit relies on, is there an earlier event that disclosed it to this actor on this branch? If the fact appears first inside the agent's proposal, the agent introduced it. Introduction is not use. In a simulation this catches a common failure mode, where the model continues a story with details the world never stored. Those details can make the answer look specific. Specific is not the same as grounded.

State-transition discipline asks whether the run obeyed the machine. Time should advance when the design says it advances. A fork should keep its parent. A rejected action should leave the state unchanged. If the stored history shows a jump that no accepted event explains, the defect may be in the harness rather than the agent, and the evaluation should say so. Blaming the agent for a broken clock teaches you nothing about the agent.

Branch outcomes are the comparative reading. Hold the split fixed, change the agent's commit or compare two agents from that split, and read the event sequences that follow. The outcome is the difference in the simulation: which facts were disclosed, which actions were accepted, where the clock stood. It is not a health result, and it is not a winner. Calling one branch better requires a criterion you declared before looking, and even then the criterion applies only inside the recorded setup.

fixed world (patient, scenario, seed, policy, evidence pack)
        |
        v
agent proposals --> accepts / rejects --> events
        |
        +-- gathering: requests and disclosures
        +-- uncertainty: no use of undisclosed facts
        +-- permissions: rejected actions stay rejected
        +-- evidence: commits cite disclosed facts
        +-- transitions: clock and fork match the events
        |
        v
second branch from the same split --> compare event sequences

The diagram is a checklist with an order. The world is fixed first. Events are recorded next. The six readings are views of those events. The second branch is how you stop a single lucky path from being the whole evaluation.

What not to collapse

Do not collapse these readings into one leaderboard number and then talk as if the number were clinical performance. A simulation can show that agent A gathered a fact and agent B committed without it. That is a finding about the recorded runs. It is not a finding about patients in the world outside the scenario. Publishing the finding without the receipt, the policy version, and the criterion is how a demo becomes a claim.

Do not evaluate an agent on facts the scenario never made available, and do not punish it for refusing an action the policy forbids. Encode the expectation in the world, or admit you are reviewing a piece of writing.

A small evaluation, stated plainly

A minimal evaluation in this design is a short document that a stranger can re-run. It names the receipt. It lists the actions the agent proposed and the environment's decisions. It marks, for each reading you claim to have done, the events you used. It includes at least one fork when the claim is about a choice, because a choice you did not branch is a choice you only narrated. It states the boundary: synthetic, educational, or otherwise permitted scenarios; no diagnosis; no treatment recommendation; no performance claim about real care.

That document will look modest next to a demo that ends on a confident paragraph. Modesty is the evidence. The paragraph can still be read, as a sample of how the agent talks. It is the last artifact in the evaluation, not the first. Patientic is being built toward environments where this kind of reading is possible, on the product surface those agents would operate, and not toward a score that pretends the simulation was a clinic.

Related reading

• AI Agents Need Environments, Not Just Context Windows
• Synthetic Patient Simulation: What It Is—and What It Is Not