Why agents need outcomes, boundaries, and stop conditions

A workflow follows your steps. An agent pursues your goal. That difference sounds philosophical right up until you have to write the goal down.

Because the goal you hand an agent is a specification, and it gets executed with a compiler's literalism. Underspecify it and the agent does not fill the gaps with your intent. It fills them with whatever best satisfies the words you actually used.

Three things that have to be written down

Success criteria a machine can check. "Improve the report" is not a criterion; it is a hope. "Every section contains current-quarter figures, each with a cited source" is checkable, by the agent and by you. If success can only be assessed by a human squinting at the output, you have delegated a vibe.

Boundaries, enforced outside the prompt. What it may spend, which systems it may touch, what it must never modify. These belong in credentials and runtime limits, not in a politely worded instruction. More on that distinction on day 38.

Stop conditions. Done, blocked, out of budget, and the fourth one everyone forgets: looping. An agent repeating the same failing approach will do so cheerfully until something external intervenes.

1if risk == "high":
2    escalate_to_human()
3elif retries > 2:
4    stop_with_reason("retry budget exceeded")
5elif evidence_quality < threshold:
6    ask_for_more_context()
7elif tool_budget.remaining == 0:
8    stop_with_reason("tool budget exhausted")
9else:
10    continue_workflow()

Bounded action, with explicit reasons to stop.

The review exercise worth stealing

Hand your goal specification to a colleague and ask them a single question: what would a malicious-but-compliant reading of this do?

Not "what should it do": what could it do while technically satisfying every word you wrote. That reading is available to the agent too, and it is the one you will meet in production when the inputs stop resembling your test cases.

The answers are usually uncomfortable and always cheap to fix at this stage. "Reduce open ticket count" is satisfied by closing tickets without resolving them. "Maximise response quality" is satisfied by taking forty minutes and thirty tool calls per request.

Vague goals produce confident agents doing the wrong thing efficiently. The first run usually looks impressive, which is precisely what delays the discovery.

Could you write down what success means for your agent precisely enough that a stranger could verify it?