Troubleshooting
The failures that come up most, and the operating change that fixes each one.
The run finished but the result is wrong
Usually the completion test was weaker than the expectation. If the request did not say how the work would be checked, the run had no way to know what wrong meant. Add the check rather than the instruction.
Use session insights to ask which acceptance criteria were verified with evidence and which were asserted without it.
The run keeps restarting or stalling
If a session repeatedly reaches a compute or context limit, reduce the scope or divide the job into independent packages. If the environment caused the failure, fix the workspace before changing the prompt.
The same clarification comes up every run
That is reusable operating context sitting in the wrong layer. Classify it: a fact or policy goes to Knowledge, a procedure change goes to the Skill, a one-time exception stays in the run.
If the prompt keeps growing run over run, some of it belongs elsewhere. A growing prompt is a symptom, not a solution.
An automation fires too often
Add conditions to filter the events that should not act, set an invocation limit, and name a failure owner. Disabling an automation stops new work without deleting its configuration, which is the right move while you tune it.
A write reported success but did not land
Require a read-after-write check as part of completion. A system receipt or a re-read of the record is the difference between believing the write happened and knowing it did.
A site blocks the browser
The run should stop and route the exception rather than imply the action succeeded. If the block is persistent, either the site needs an allowlist entry, the work needs an API path, or a person needs to take over that step.
Review has become a rubber stamp
Check whether exceptions are ever routed. A workflow that never produces one usually has exception rules that are too loose rather than a process that is genuinely clean. Tighten the rules and see what surfaces.