I approach this as a systems problem: define success, make state explicit, bound authority, and require evidence before release.
1. Define the finish line
Start with what must be true when the workflow ends.
An answer was generated. Was the user’s request resolved? A tool returned successfully. Did the intended change occur? A handoff was initiated. Did someone accept responsibility?
Write down:
- The successful end state.
- The unacceptable outcomes.
- The conditions that require a stop or handoff.
- The evidence that distinguishes completion from an attempted action.
If the team cannot agree on these, it is too early to optimize the model.
2. Evaluate situations that change the decision
Build scenarios around conditions that require different behavior: missing information, conflicting instructions, unavailable tools, interruptions, repeated requests, and uncertain results.
For each scenario, specify the required outcome, permitted actions, and conditions for human involvement. Include cases where the correct behavior is to ask, wait, or stop.
An aggregate score can hide a consequential failure. Release decisions need to show which situations improved, which regressed, and whether those regressions are acceptable.
The deliverable is a scenario set that can block a release.
3. Separate proposals from confirmed effects
A model’s statement that something happened is not evidence that it happened.
Keep requests, authorizations, attempted actions, confirmed effects, and unresolved outcomes in explicit workflow state. Record retries and completion criteria there too.
This distinction matters when a dependency times out. The action may have failed, succeeded, or partially completed. Retrying without resolving that uncertainty can create a second problem.
The system must be able to determine what remains safe to do.
4. Give each action a boundary and a recovery path
For every consequential action, define:
- What must be true before execution.
- Who or what may authorize it.
- How repeated execution is prevented or made safe.
- What happens after failure or an uncertain result.
- Who owns the next step if automation stops.
A handoff is complete only when responsibility has transferred and the recipient has enough context to continue.
Recovery belongs in the workflow before launch.
5. Collect evidence that supports the next decision
Connect the user’s request to state transitions, model decisions, tool results, retries, and the final outcome.
The operating team should be able to answer:
- What happened?
- What is still uncertain?
- What should happen next?
Collect enough evidence to answer those questions within privacy and retention constraints. More logs are useful only if they improve diagnosis or recovery.
6. Set the release bar before reviewing results
Agree on the required scenario coverage, acceptable failure severity, latency and cost limits, rollout scope, and rollback conditions before evaluating a candidate release.
Then make the decision explicit: release, limit the rollout, or hold.
The evidence must support the scope of the release. A narrow evaluation supports a narrow rollout.
After launch, define what would cause the team to pause or reverse the decision. A release bar must remain enforceable once real users depend on the system.
7. Make ownership survive the launch
Name an owner for evaluation, production signals, recovery, and release decisions.
When a failure occurs, use it to change the system: add a scenario, correct a state transition, narrow an action boundary, or repair a recovery path. Assign the change and verify it.
A lesson is complete when it changes future behavior.
These answers make reliability reviewable. The model will still make mistakes. The architecture determines whether those mistakes become visible, remain bounded, and lead to a recoverable next step.