When Is the Evidence Enough?. Ben Faircloth

An agent can almost always gather one more piece of evidence.

A research agent can open another source. A diagnostic workflow can request another measurement. A tool-using system can inspect another part of its environment before acting. An agent comparing several possibilities can run another query, call another tool, or wait for another observation.

Sometimes the next piece of evidence changes the conclusion. Often it simply reinforces what the system already believed. In either case, gathering it has a cost. It consumes time, compute, tool calls, and sometimes money. In a system that has to respond quickly, waiting can itself become a failure mode.

At some point the system has to stop looking and do something.

The difficult part is that the evidence itself does not contain that stopping point. There is rarely a final observation that announces that the investigation is complete. More information may always be available somewhere. The system has to decide that what it knows is sufficient for the action it is considering.

That makes stopping a decision problem rather than an evidence problem.

The distinction matters because agent loops often make the two look like the same thing. The system gathers information, updates what it knows, and eventually acts. From the outside, it can appear as though enough evidence simply accumulated and the action followed naturally.

But evidence can tell the system what it currently has reason to believe. It cannot, by itself, tell the system how much belief is enough.

That requirement has to come from somewhere else.

Evidence changes what the system believes

Suppose an agent is trying to determine whether some proposition \(H\) is true.

The proposition could be that a condition has been satisfied before invoking a tool, that the available sources support a claim strongly enough to answer a question, or that a system state is stable enough to proceed with an action. The specific task can vary. The structure is the same.

At time \(t\), the agent has accumulated some evidence:

E_t = \{e_1, e_2, \ldots, e_t\}

Each new observation changes what the evidence supports.

One way to represent that change is with a posterior probability:

P(H \mid E_t)

The notation matters less than the separation it creates. The observations are one thing. The system's current belief about the proposition, given those observations and the assumptions of the model, is another.

That belief does not have to move steadily upward.

A run of supportive evidence may increase the posterior. The next observation may point the other way and reduce it. Later evidence may restore the earlier belief or weaken it further. Nothing about sequential evidence collection guarantees that confidence should improve with every step.

This is important for agents because the system does not get to see the entire evidence stream before deciding where it should have stopped. It has to make that decision from the state available at the time.

If the current posterior is 0.82, the system knows what the evidence supports under its model. It still does not know whether 0.82 is enough.

That is a different question.

A requirement turns belief into a decision

Now suppose the application is allowed to act once the posterior probability of \(H\) reaches 0.80.

The decision rule is:

P(H \mid E_t) \geq 0.80

A more cautious application might require:

P(H \mid E_t) \geq 0.95

Nothing about the evidence process has changed. The system gathers observations in the same way and updates its belief in the same way. What changes is how much support the application requires before it is willing to act.

More generally, let \(\alpha\) represent the requirement:

\text{act when } P(H \mid E_t) \geq \alpha

Otherwise, the system continues gathering evidence.

The value of \(\alpha\) does not come from Bayes' theorem. It does not come from the language model, either. It comes from the work.

A low-consequence, easily reversible action may tolerate more uncertainty. A consequential action may justify waiting for stronger evidence. A system that recommends the next document to inspect may reasonably stop much earlier than one that is about to make an irreversible change to an external system.

This is why there is no universally correct confidence threshold for an agent.

The same evidence can be sufficient for one action and insufficient for another because the consequences of being wrong are different.

That sounds obvious when stated directly. It is less obvious once the requirement is buried inside an agent loop and reduced to a variable named confidence_threshold.

At that point the threshold can start to look like a technical property of the agent rather than a decision about what the application considers sufficient.

It is neither.

It is a boundary between evidence and action.

A simplified implementation makes that boundary visible:

while budget_remaining():
    observation = observe()
    evidence.append(observation)

    posterior = update_belief(evidence)

    if posterior >= requirement:
        return ACT

return ESCALATE

There is little sophistication in the code itself. The useful part is that the stopping condition is explicit.

The evidence-gathering process does not get to redefine the requirement. The posterior does not decide that 0.87 feels close enough. The application compares the current evidence with a condition that exists independently of it.

That is what turns belief into a decision.

The same evidence can support different stopping points

The companion experiment makes this distinction concrete.

Two agents evaluate the same proposition. They use the same prior assumptions and the same belief-update process. The underlying evidence sequence is the same.

The only difference is the amount of posterior support each one requires before acting.

The first agent uses:

\alpha = 0.80

The second uses:

\alpha = 0.95

The first agent reaches its requirement after four observations and acts.

The second does not stop until observation nineteen.

That result is already enough to show why the stopping rule belongs outside the evidence process. There was nothing in observation four that made it intrinsically final. It was final only for the system whose requirement had been satisfied.

The next observation makes the distinction more interesting.

Had the first agent continued gathering evidence, observation five would have pushed its posterior back below 0.80.

The system that stopped at step four never sees that reversal.

That does not mean it made the wrong decision. At the point where it acted, the evidence satisfied the requirement it had been given. The system behaved exactly according to its rule.

What the example exposes is a consequence of stopping that is easy to hide in an abstract formulation.

When an agent stops gathering evidence, it gives up the opportunity for later evidence to change its mind.

A stricter requirement keeps the system exposed to more evidence before it commits. Sometimes that will prevent a premature action. Sometimes it will merely delay a decision that could have been made safely much earlier.

The important question is not whether early or late stopping is better in the abstract. It is what the application requires before the cost of continued uncertainty is lower than the cost of continued investigation.

That tradeoff belongs to the decision.

More confidence costs more evidence

One evidence sequence shows how the stopping rule works. It cannot tell us whether step four or step nineteen is typical.

Noisy evidence means another run may look very different. A strong early sequence might satisfy the requirement almost immediately. A weaker sequence might keep the agent gathering for much longer even though the underlying proposition is the same.

To understand the stopping policy rather than one particular run, we can repeat the experiment across many possible evidence streams.

This is where Monte Carlo simulation becomes useful.

The simulation is not being used to invent model outputs or create synthetic benchmark scores. It is being used to observe what the same stopping rule does across many plausible sequences of evidence.

In the current experiment, the hypothesis is true and the evidence-generating process favors it clearly enough that every simulated agent eventually reaches its requirement.

What changes is how much evidence the agent needs before it is willing to act.

At a required posterior of 0.80, the median stopping point is about three observations.

At 0.95, it rises to about nine.

At 0.99, it rises to about twenty-one.

The specific numbers are properties of this experiment. Change the prior, observation noise, underlying state, or likelihood model and the numbers will change.

The interesting result is the shape.

Increasing the requirement consumes more evidence, and the marginal cost grows as the system asks for stronger and stronger support before acting.

Across repeated evidence streams, stricter stopping requirements delay action. The particular values belong to this experiment; the useful result is the relationship between the requirement and the amount of evidence the agent consumes.

That relationship has a direct operational meaning.

If an observation is a document retrieval, every additional step costs latency and compute. If it is a tool call, it may cost money or introduce another external dependency. If the system is waiting on a person, more evidence may mean additional human effort. If the agent is operating under a time constraint, delaying action may itself carry risk.

A requirement for greater certainty therefore does not exist only in probability space. It changes the amount of work the system performs before it acts.

A seemingly small move from 0.95 to 0.99 can be a large change in behavior.

That does not make 0.99 excessive. It means the application should have a reason for paying the additional cost.

A stronger requirement is not automatically a better one

It would be easy to look at the previous figure and conclude that the more cautious agent is simply better.

That would turn a tradeoff into a ranking.

A higher threshold delays commitment and gives the system more opportunity to encounter evidence that contradicts its current belief. In some settings, that additional caution is exactly what the application needs.

In others, it is wasted work.

If an agent is deciding whether to open one documentation page or another, insisting on 99 percent posterior confidence before taking the next step could make the system needlessly slow. If it is deciding whether to execute a high-consequence action that is difficult to reverse, the same requirement might be entirely reasonable.

The probability does not resolve that judgment.

A posterior can describe what the available evidence supports under a particular model. It cannot decide what level of support the application should require.

That is why the requirement has to remain visible.

The system should be able to answer two separate questions:

What does the evidence currently support?

And what level of support does this action require?

If those questions are collapsed into a single confidence value, it becomes difficult to tell whether a failure came from poor evidence, a poor belief model, or an inappropriate requirement.

That separation becomes even more important once the underlying probability model is taken seriously.

A posterior such as

P(H \mid E_t)

is not an objective confidence meter embedded in the agent. It is conditional on the prior, the likelihood model, and the observations supplied to it. A biased evidence source, a badly specified likelihood, or an inappropriate prior can produce a perfectly valid posterior calculation that poorly represents the real problem.

The stopping rule does not fix those weaknesses. It assumes that the belief state is useful enough to act on.

That is another reason not to treat the number as the decision itself.

The probability is evidence for the decision. The requirement determines what the application is willing to do with it.

Some evidence streams never become enough

The current experiment is intentionally clean.

The hypothesis is true, and the observation process provides enough signal that every simulated agent eventually reaches its stopping threshold. That makes the effect of the requirement easy to see because the agents differ primarily in how long they wait.

Real systems are not guaranteed that outcome.

The hypothesis may be false. The evidence may remain ambiguous. The observations may be too noisy for the posterior to move decisively in either direction. The sources available to a research agent may simply not contain enough information to support a conclusion.

An agent cannot keep looking forever.

Once that possibility is admitted, the stopping rule needs another condition. The system may have a maximum number of observations, a time limit, a cost budget, or some explicit condition for declaring that the available evidence is insufficient.

The decision space becomes larger than ACT or CONTINUE.

It may include:

\text{ACT}\]\[\text{CONTINUE}\]\[\text{ABSTAIN}\]\[\text{ESCALATE}

Those options are not exceptions to the stopping problem. They are part of it.

A system that knows when it has enough evidence also needs a way to recognize when enough evidence is unlikely to arrive within the resources it is allowed to spend.

That moves the question from simple confidence toward bounded action.

The system may be sufficiently confident to proceed. It may have enough evidence to reject the proposition. Or it may reach the end of its budget without enough support for either conclusion.

What happens next is again a property of the application, not something the evidence decides by itself.

The evidence path updates what the system knows. Requirements and budgets determine what the system is allowed to do with that knowledge.

The stopping rule belongs in the system

This is where the problem reconnects with the application architecture from the first Teaching Note.

TN-001 separated constraint, state, decision, and response because applications become difficult to reason about when those responsibilities disappear inside a language-model call.

An evidence-gathering agent has the same structure.

The accumulated evidence and current posterior are part of state. The requirement and evidence budget constrain what counts as an acceptable decision. The decision is whether to act, continue, abstain, or escalate. Whatever the system does next becomes the response.

The model can participate in that process without owning the entire process.

It may generate the next research query. It may interpret a retrieved document. It may propose which tool to call next. It may even help estimate whether a particular observation supports the hypothesis.

None of those roles requires the model to decide for itself how much evidence the application should demand before acting.

That distinction is useful because otherwise the stopping problem is often reduced to a prompt instruction:

Keep investigating until you are confident.

The phrase sounds reasonable but leaves the important part undefined.

How confident?

Under what model of uncertainty?

At what cost?

And what happens if confidence never reaches that level?

Those are system questions.

An agent that is allowed to answer them implicitly may stop too early, continue indefinitely, or behave differently across runs for reasons that are difficult to inspect.

Making the stopping rule explicit does not solve every one of those problems, but it gives them somewhere to live.

Enough is not in the evidence

Return to the original problem.

An agent gathers observations one at a time. Each observation changes what the system has reason to believe. At some point, the system acts.

It is tempting to describe that sequence by saying that the agent finally gathered enough evidence.

That skips the important part.

There is no amount called enough inside the evidence itself.

Four observations were enough for the agent whose requirement was 0.80. The same point was not enough for the agent that required 0.95. Across repeated runs, stricter requirements consumed progressively more evidence before action. In harder cases, the evidence may never satisfy the requirement at all.

The evidence tells the system what it currently supports.

The requirement tells the system what the work demands.

The stopping rule connects the two.

That separation is what makes it possible to reason about why the agent acted when it did, what would make it wait longer, and what should happen when waiting no longer makes sense.

An agent can almost always gather one more piece of evidence.

The harder question is whether it should.

Exercise

Start with the stopping experiment from the companion repository and keep the evidence-generating process fixed. Change only the required posterior and observe how the distribution of stopping times changes.

Then reverse the experiment. Hold the requirement fixed and change the evidence process by increasing the observation noise or moving the true state closer to the decision boundary.

Finally, impose a maximum evidence budget.

The goal is not simply to make the agent stop.

Watch which part of the system changes the outcome. A stricter requirement should delay action even when the evidence process is unchanged. Noisier evidence should alter how quickly belief moves even when the requirement is unchanged. A budget should force the system to confront cases in which enough evidence never arrives.

Those are different causes, and the point of the exercise is to keep them visible.

Connected Notes

TN-001Constraint, State, Decision, ResponseSeparates the responsibilities that are often collapsed into a language-model call. This note examines one of those responsibilities more closely: once evidence has accumulated in state, what determines whether the system should act or continue gathering?FN-002The Benchmark Ends at DeploymentArgues that system decisions require evidence generated under the conditions in which the system will actually operate. This Teaching Note looks at what happens next: once evidence is being gathered, what determines when there is enough of it to support action?

PublishedOctober 2026

AuthorBen Faircloth

Codegithub.com/benfaircloth/tn-002-from-measurements-to-decisions

Cite asFaircloth, B. (2026). "When Is the Evidence Enough?" BenFaircloth.com, Teaching Note 002.

All teaching notes