Unit 02.03: Success, failure, and the third outcome
A task with only success and failure forces every ambiguous case into one of them.
Escalate is a designed outcome
Three outcomes: the goal was reached, a person is needed, or the ceilings were reached without either.
The table below classifies three run states.
success the artefact was produced
escalate needs a person: contract not found in the document store
failure ceilings reached without the goal
Three outcomes, and the middle one is what most designs leave out. A task with
only success and failure pushes every ambiguous case into one of them -- and
the ambiguous cases are exactly the ones a person should see.
`blocked_by` names what a human would need to resolve, which is what makes the
escalation actionable rather than just a handover.
blocked_by is what makes the escalation actionable. "Needs a person" is a handover; "needs a person: contract not found in the document store" tells them what to do first.
Without the middle outcome, the second case reports failure - which reads as the agent being unable to do its job, when in fact the input was missing and a human could resolve it in a minute.
The mistake this prevents
The mistake is treating escalation as a failure to be minimised. Driving its rate to zero means the ambiguous cases went somewhere, and where they went is into confident answers built on incomplete evidence.
Takeaway
Build three outcomes, and have the escalation name what a person would need to resolve. A system with two outcomes reports missing inputs as its own failure.
