Direct answer: Write the acceptance criteria before the agent acts. Afterwards, check the resulting system state independently. A tool receipt confirms an operation, not the user's outcome.

AI agents can produce convincing summaries of unfinished work. The problem is not confined to small local models. Reasoning quality, tool execution and verified completion are different things.

Where the workflow breaks

Follow the chain: request → interpretation → plan → tool call → external action → observed state → completion report. Each boundary can introduce error. A model might misunderstand the goal. A tool might write a file containing the wrong data. A browser might still display cached content. Or an agent might stop because of a generation limit and still describe the target as done.

Microsoft's AgentRx failure taxonomy distinguishes nine types of failures. They include intent–plan misalignment, ignoring required steps, invalid tool calls, invented information, misreading tool results, missing permissions and system failures. Correct diagnosis matters more than blaming every failure on the model.

Write a completion contract before the first action

  1. Goal: describe the user-visible result, not just a command.
  2. Target: identify the exact device, account, repository, environment or file path.
  3. Obligations: list required files, behaviours, constraints and approvals.
  4. Evidence: define the check that can prove each obligation.
  5. Stop conditions: specify what happens if evidence is missing, checks fail or authorisation is unavailable.

What a useful completion record looks like

Task: Build a working landing page
Status: INCOMPLETE
Observed: HTML saved; CSS saved; JavaScript parse FAILED
Still required: browser interaction PASS; live deployment PASS
Next step: repair JavaScript, then rerun checks
Claim allowed: local files exist; deployment NOT verified

That record is less impressive than “I built the full page”, but far more actionable.

A task changes the world, produces a tool receipt, then requires independent observation and a postcondition check. Only verified evidence leads to done; absent evidence leaves the task incomplete.
A receipt is input to verification, not a final answer. This is a design method, not a measured universal accuracy claim.

How to check different tasks

  • File: reopen it, inspect expected content, check syntax, hashes and required sections.
  • Software: compile and run tests, then exercise the relevant real user path.
  • Website: check the deployed URL, correct assets, live navigation and mobile/desktop rendering.
  • Database or business record: query the authoritative store for the exact ID and required value.
  • UI automation: confirm the resulting application state; a click alone is not proof.
  • Research: verify original sources behind individual claims, note disagreements and dates.
  • Visual output: test structural requirements and include human review for subjective quality.

Six controls that matter more than adding another model

  1. Persistent requirement ledger: keep obligations outside the model's conversational summary.
  2. Typed tool contracts: distinguish invalid arguments, denials, outages and content failures.
  3. Independent read-back: observe the result again after an action changes state.
  4. Explicit states: VERIFIED, FAILED, INCOMPLETE, CONFLICT and APPROVAL_REQUIRED where relevant.
  5. Bounded recovery: retry with limits, snapshots and duplicate-action protection.
  6. Repeatable tests: preserve model, prompt, version, environment, logs and scorer settings; measure false completion separately from ordinary failure.

For self-correction, a 2024 TACL survey found reliable external feedback more promising than simply asking a model to reassess itself. Context-rot experiments show why longer transcripts are not an automatic solution. And OpenAI's February 2026 SWE-bench review illustrates why benchmark contamination and test quality matter.

Tools: reuse before adding dependencies

For Rust, start with cargo test, existing typed interfaces and tracing. For dynamic websites, use an existing browser and screenshot testing path. Look at UK AISI Inspect and the Anthropic agent-evaluation guide for test design. These are references, not instructions to add new runtimes to production.

Verification adds latency and operational cost. Scale the checks to the consequence of failure: low-risk reversible drafts need less than external publication, financial changes or remote-device control.

Five-minute final check

  1. Can you point to every requested deliverable?
  2. Did you inspect the result rather than only the command output?
  3. Did the relevant tests and real user path pass?
  4. Did any missing evidence remain openly INCOMPLETE?
  5. Can someone else reproduce the result from retained evidence?

What SC LABS has measured

Our October survival test scored 10/15, with six generation-length terminations and incomplete code before recovery. In a different Controller experiment, a successful file-write receipt contained wrong semantic data and the reported score remained 8/9. These are specific historical results, not universal frontier or local failure rates.

For the product and its current maturity boundaries, see ARKTOR and the SC Agent Lab evidence. These links explain our engineering direction, not a claim that every new completion gate is already deployed.

Continue with evidence verification, completion gates, independent read-back and playbooks. The companion Engineering Journal article explains why these controls matter in real work.