Done means
verified.

The last click is not the finish line

Imagine asking an agent to change the billing address on an account. A reasonable plan might be:

1. 01Find the account.
2. 02Open the billing settings.
3. 03Enter the new address.
4. 04Click Save.
5. 05Report success.

The problem is not the plan. The problem is treating the plan as evidence.

Clicking Save proves that the agent attempted to save the address. It does not prove that the application accepted it. To establish that, the agent must inspect what came next: a confirmation message, the updated address on the page, or the same value after reopening the record.

An action is something the agent does.
An outcome is a change in the world.

Plans are useful—and provisional

Planning helps an agent keep its bearings. It turns a vague request into manageable steps and gives long tasks some structure. But a plan is still a prediction. It describes how the agent expects the task to unfold.

The web is rarely so cooperative.

Pages re-render. Buttons move. Sessions expire. Modals appear over the interface. A server rejects an apparently valid request. A single-page application changes state without navigating anywhere. Sometimes a success message appears even though the underlying record has not changed.

A browser agent cannot simply execute a plan and count completed steps. It must repeatedly return to the environment and ask: What is true now?

Act, then look again

A dependable browser agent follows a simple rhythm: observe, act, check.

The agent reads the current state, chooses an action, performs it, and then inspects what changed. If the result matches the intended outcome, it can continue. If it does not, the agent must recover, replan, or explain what blocked it.

The strength of the check should match the importance of the action. Opening a navigation menu may require little more than confirming that the menu appeared. Updating a customer record should involve reading the saved value back. Placing an order calls for stronger evidence: an order number, a confirmation page, or a new entry in the order history.

What matters is that the evidence comes from the environment, not from the agent’s confidence in its own actions.

Completion is a typed decision

This principle is not only a prompt handed to the model. It appears in the runtime as a boundary the model cannot talk its way around.

The first step is to give completion more than two possible answers. OpenSidebar distinguishes a supported result from a failed result, a result that still needs checking, and a result the available evidence cannot settle.

export type CompletionEvaluation =
  | {
      status: "accepted";
      reason: string;
      contract: CompletionContract;
      evidence: CompletionEvidence[];
    }
  | {
      status: "rejected";
      reason: string;
      contract: CompletionContract;
      evidence: CompletionEvidence[];
    }
  | {
      status: "needs_verification";
      reason: string;
      hint: string;
      contract: CompletionContract;
      evidence: CompletionEvidence[];
    }
  | {
      status: "inconclusive";
      reason: string;
      contract?: CompletionContract;
      evidence: CompletionEvidence[];
    };

Naming those states is useful; enforcing them is what changes the behavior. When the agent proposes completion, a guard checks the evidence required by the task contract. Missing evidence turns the proposal into a rejection and sends the agent back to verify.

export function assessMissingEvidenceGuard(
  ctx: CompletionGuardContext,
): GuardOutcome {
  const preflight =
    evaluateCompletionRequiredEvidencePreflight({
      missingRequiredEvidence: ctx.missingRequiredEvidence,
    });

  if (preflight.status === "valid") {
    return { kind: "pass" };
  }

  const missing = preflight.missingRequiredEvidence;
  const reason =
    `Missing required typed evidence: ${missing.join(", ")}.`;

  return {
    kind: "reject",
    guardId: "missing_evidence",
    reason,
    // Recovery instructions and trace effects follow.
  };
}

Plausible behavior is not functional correctness

This distinction also appears in browser-agent research.

WebArena evaluates whether web tasks are functionally correct after execution. Its validators inspect the resulting application state rather than awarding success because an agent followed a convincing sequence of steps.

WorkArena brings the same principle to enterprise work in ServiceNow. The agent succeeds when the requested outcome exists in the application—not when its activity merely looks reasonable.

That difference matters in both directions. A clumsy process can occasionally produce the correct result, while an elegant process can end in failure. If we evaluate only the sequence of actions, we can misjudge both.

Traces explain; validators decide

A trajectory—or trace—is the record of an agent’s run: what it observed, which tools it used, what those tools returned, where it hesitated, and how it responded to errors.

Traces are essential. When an agent fails, the trace can show whether it misunderstood the page, acted on stale information, missed an error message, or simply stopped too soon. Without that record, debugging becomes guesswork.

But a trace is not proof of success.

An agent can produce a beautifully coherent account of a task it did not complete. It can explain why each action made sense. It can even state, with confidence, that the objective was achieved. None of that changes the application state.

Anthropic’s guidance on agent evaluations draws a similar distinction between evaluating outcomes and evaluating transcripts. Both matter, but they answer different questions.

The model does not contain a “done” detector

It is tempting to treat premature completion as a model problem: perhaps the agent needs a better prompt, a stronger model, or another reminder to be careful. Sometimes that helps. It is not the whole answer.

Reliable completion comes from the system around the model: clear goals, useful browser tools, fresh observations, verification rules, approval gates, recovery paths, and traces. Together, these form the agent’s harness.

Addy Osmani describes harness engineering as the work of improving that surrounding system whenever an agent exposes a recurring failure. If agents regularly stop after clicking Save, the durable solution is to make post-action checking part of the normal execution loop.

The goal is not to make the agent sound less certain. It is to give certainty a better foundation.

Sometimes the honest answer is “I don’t know yet”

Not every outcome can be verified automatically.

A background operation may take longer than expected. A website may offer no readable confirmation. Another person may need to approve the request. The action may have succeeded even though the page failed to update.

In those cases, the agent should not turn missing evidence into invented confidence.

Uncertainty is not a weakness. It is a faithful description of the situation.

The agent may need to observe again, check another part of the application, wait for an external result, or ask the user what to do next. For consequential or irreversible actions, human confirmation may be the correct final validator.

This principle extends beyond browser automation. NIST’s guidance on trustworthy AI emphasizes objective evidence, ongoing monitoring, and the ability for humans to intervene when a system cannot detect or correct its own errors.

What this means for OpenSidebar

OpenSidebar is built around a separation between execution and completion.

The agent can form a plan and operate the browser, but those actions do not grant it authority to declare success. It must return to the page, inspect the resulting state, and compare that state with the user’s original objective.

Its tools perform actions. Its verification logic evaluates outcomes. Its traces preserve the evidence needed to understand both.

Do not report the future the plan predicted. Report the state the browser actually reached.

That may make the agent slightly more deliberate. It may add another observation, a field readback, or a second view of the result.

That final check is not wasted motion. It is the point at which automation becomes dependable.

An agent that clicks quickly can look impressive.
An agent that verifies its work can be trusted with something real.