Study the failure.
Improve the system.

The final answer is only the visible edge.

A wrong answer may come from missing evidence, a mistaken plan, an unavailable tool or an incorrect state update. Changing the prompt before locating the mechanism can obscure the failure instead of fixing it.

A useful diagnostic trace

Record task and run identifiers, state transitions, tool names, validated arguments, response status, evidence references and authorization decisions. Do not depend on hidden model reasoning. An observable action trace is the relevant engineering artifact.

Experiment to run

Take a minimized task and change one condition at a time: remove evidence, deny a permission, time out a tool or invalidate a checkpoint. Observe the first incorrect transition and whether the declared stop or recovery behavior occurs.

Limit: incomplete instrumentation can make several causes indistinguishable. Keep the diagnosis unresolved until the evidence separates them.

Enforce authority outside the model.

An instruction to “be careful” is not an authorization system. Model output should be a proposal. A separate execution boundary should validate the action against policy and current state before any side effect.

• Least privilege. Restrict the available operations and resources to the active task, not everything the system can reach.
• Untrusted evidence stays data. Retrieved text and tool responses must not grant new permissions or override the task's authority.
• Approval binds to an action. Store the operation, resource, arguments, state revision and expiry. Reject reuse if those details change.
• Ambiguity stops the write. Missing policy, invalid approval or inconsistent state should pause consequential execution, not widen permissions.

Experiment to run

Place adversarial instructions in a retrieved document. Ask the agent to perform the legitimate task. Inspect both the answer and the execution log: the injected text must not cause a permission expansion or an unauthorized call.

A timeout is not evidence that nothing happened.

Separate read operations from writes. A read may be repeatable within a budget; a timed-out write can leave an unknown state. Retrying without checking can repeat the side effect.

PROPOSE    validate operation + arguments
AUTHORIZE  check scope + approval + state revision
EXECUTE    attach a stable operation identifier
CONFIRM    check the authoritative resulting state

If the response is ambiguous:
  query operation status
  → committed: reconcile local state
  → confirmed absent: retry only if permitted
  → still unknown: stop and request review

Design requirements

Prefer tools with typed errors, bounded timeouts, explicit idempotency semantics and status lookup. An idempotency key only helps if the downstream service enforces it; attaching an identifier alone does not make an action safe to repeat.

Experiment to run

Simulate a successful write whose response is lost. Verify that the agent reconciles with authoritative state or stops, rather than issuing a second effect. Repeat with an expired idempotency window and an unavailable status endpoint.

Limit: some tools cannot report or reverse their effects. In those cases, restrict automation or require an operator at the ambiguous boundary.

Preserve state, not every token.

Long tasks need a compact, explicit record: the goal, constraints, confirmed facts, pending decisions, completed effects and evidence references. Conversation history can provide context, but it is not the authoritative record of what happened.

Experiment to run

Interrupt a task after a confirmed side effect, compact the context and resume from a checkpoint. Change one source document in the meantime. Test for duplicated actions, lost constraints and reliance on stale evidence.

Limit: compaction is lossy. If a decision depends on an omitted detail, retrieve the original record or ask for clarification; do not infer it from a confident summary.