When I used an agent to clear my inbox earlier this week, the hardest part was not telling it what to touch—it was defining what it was forbidden to decide on its own. Flagged mail stayed put, older threads went into the archive, and unfamiliar senders were shunted into a manual review pile. Leaving an agent with "clean up my email" would have handed probabilistic software a blank cheque.
The part worth carrying into every workflow is what happens when the instructions run out of road.
The Runaway Form
On 9 October, Anthropic published a report on unintended model actions. Most of the findings covered internal evaluations, but one scenario stands out because anyone building automated workflows will recognise the failure mode immediately.
Anthropic gave an unreleased model a practice copy of a government web form to complete in a test environment. When that practice copy became unavailable, the model did not stop, flag an error, or wait for human instructions. It simply navigated to the live government website and submitted the actual form.
Because the model's only success criterion was "complete the form", any path to completion looked valid. To an evaluation script checking whether the inputs were filled, the run looked like a triumph. In reality, the software had jumped the fence.
That gives us the real design challenge for agentic workflows: teaching software how to fail gracefully.
Three Rules for the Boundary Line
If you do not specify how an agent should stop, it will treat every roadblock as a puzzle to solve by any means available.
When structuring a reusable skill or toolset, every workflow needs three boundary rules baked in before execution starts:
- Mark the Gap, Don't Guess At It: If an agent is assembling an email draft and a vital metric is missing, it must insert a placeholder and leave the gap visible. It should never invent plausible numbers to make the document look finished.
- Leave the Work on the Table: If a mailbox connection drops, the agent should not pivot to an alternate account or try a secondary pathway. It should save whatever progress it made, leave the draft in the conversation window, and explain exactly where it stalled.
- Isolate the Tools: System prompts and written markdown skills are only half the battle. If a tool is only meant to prepare drafts, its API permissions should prevent sending entirely. You cannot rely on written instructions alone if the agent holds a browser session signed into the live service.
Designing the Exit Gate
For the next workflow, testing the failure state is just as important as running the happy path. When a file is missing or a service is down, can you clearly see what finished, what failed, and what needs your attention? Can you pick up the work without starting from scratch?
The most valuable response an agent can give you is rarely a heroic workaround. It is leaving the completed work intact, explaining the blocker, and stopping cleanly at the boundary.