Agent Workflow Runtime Governance: Classify Failures, Evidence Packages, and Escalation Paths

Why Demo-Successful Agent Workflows Still Need Human Firefighting

The article opens with an equipment manufacturer's after-sales triage workflow: read ticket and attachments, recognize images, extract text, retrieve repair manuals, propose triage, submit to ticket system. In demos with complete, conflict-free tickets every node passes. But a single problematic ticket — blurry photo, wrong model recognition, outdated repair bulletin, ticket already closed by someone else — breaks the flow. If the process lacks predefined handling paths, operators must manually check logs, supplement materials, and change states — ad-hoc firefighting.

Human involvement is not the problem. Ad-hoc human intervention after failure, forcing people to re-investigate from scratch, is firefighting.

The previous article covered capability contracts (when a capability can be used, who is responsible). This article examines how those contracts are enforced at runtime: what to check at each step, where to route errors, who confirms, when to stop. The "runtime" is the mechanism responsible for checks, routing, and state tracking during task execution, implemented by existing workflow engines and business services.

Classify Failures Before Retrying

A node returning only "success" or "failure" is insufficient. Timeout, blurry photo, insufficient evidence require completely different handling. The article defines four categories:

Technical failure : call timeout, service unavailable, format parse error. Handling: limited retry only if retry conditions met; for write operations with unknown result, reconcile first.

Data issue : unreadable image, missing device model, conflicting key fields. Handling: request supplementary materials, invoke deterministic validation, or route to data repair queue.

Business uncertainty : ambiguous candidates, insufficient judgment evidence, or rules requiring human review. Handling: generate evidence package, hand to authorized business role for confirmation.

Controllable progression : evidence, rules, authorization, and state all meet current step thresholds. Handling: proceed to next task; for business actions, generate action candidate then enter pre-submission review.

Clear violations of hard constraints must be blocked directly, not treated as business uncertainty. Human confirmation can only choose within authorized scope, cannot automatically waive constraints. Temporary interface unavailability may benefit from retry; missing photo cannot be fixed by repeated model calls; ambiguous model needs evidence verification, not more confident language. Conversely, labeling everything "success" is equally dangerous: a model category does not guarantee sufficient materials; ticket interface acceptance does not guarantee entry into target processing queue.

Assess Before Deciding to Repair or Continue

Many teams treat evaluation as offline pre-launch testing: prepare a test set, measure accuracy, decide release. Good pre-launch metrics do not guarantee the current ticket's materials are qualified. At critical steps, re-check: does this result support the next step? Checks need not always invoke models; field validation, rules, and version comparison can cover part of the work.

In the after-sales triage flow, at least four checks apply:

Input completeness : device, fault description, attachments, ticket status satisfy current capability contract.

Evidence consistency : classification suggestion supported by nameplate, historical repairs, manual clauses, or on-site materials.

Rule fitness : hits mandatory block or escalation rules for safety, warranty, region, batch faults.

State freshness : ticket, device, and authorization info are current usable versions.

Checking every judgment at every step slows the flow; only validating JSON format misses real problems. Check depth depends on risk. Low-risk, advisory suggestions can be lighter; steps involving resource allocation, ticket state changes, or external commitments require re-verification of state, rules, authorization, and mandatory human confirmation per strategy.

An often overlooked issue: can experts handle the volume? Routing more tickets to humans may reduce auto-mistriage but lengthens queues. From a systems engineering view, review thresholds, staff capacity, and SLAs must be considered together. Mandatory human-review tasks cannot be auto-approved due to queue congestion. Alleviate congestion by adding staff, priority scheduling, or limiting auto-link concurrency; set timeouts and human-escalation for backlogged tasks. Accepted tasks within scope must remain in subsequent statistics, not disappear from denominator due to rate limiting.

Repair Is Not Asking the Model to "Think Again"

On error, teams often re-call the model, change prompt, or ask for self-reflection. Misunderstanding a sentence may improve; missing photo, ledger conflict, or write timeout require different fixes.

Blurry image, corrupt file → request retake, fallback OCR lane, record material quality. Not : repeatedly ask same model to guess image content.

Device model conflicts with asset ledger → call authoritative ledger verification, flag conflict, request confirmation. Not : let model arbitrarily pick a model from context.

Repair manual version expired → refresh knowledge version or route to knowledge maintenance queue. Not : wrap old material conclusions as latest rules.

Classification confidence insufficient → present candidates and evidence to service specialist for confirmation. Not : generate a "certain" answer with stronger tone.

Write operation interface timeout → reconcile by request identifier first; only resubmit if confirmed unprocessed and retry conditions met. Not : treat unknown result as failure and blindly repeat submission.

Data repair, retry calls, and business judgment confirmation must be arranged separately. Rule-deterministic fixes follow rules; missing materials go to material owners; business judgments go to authorized people with evidence and options. Models can assist but cannot make unfounded confirmations for these people.

When Escalating to Humans, Send the Evidence Package

If "escalate to human" only sends "Please handle exception ticket 12345", the receiver must still hunt materials and rules to understand why the model stopped. System-saved time is lost here.

Therefore, notifications must carry an evidence package containing:

Authoritative identifiers of current ticket, device, customer.

Current state and its read timestamp.

Model or operator candidate results.

Used and missing evidence.

Hit business rules or conflict points.

Allowed confirmation options and subsequent actions each triggers.

Who must confirm, confirmation validity period, escalation target.

Example: ticket WO-20260916-118 "device overheating restart, photo model X200 conflicts with ledger X210". Assistant originally suggested thermal repair team. Runtime detected model conflict, paused auto-triage, handed verification to service specialist:

Conflict blocks only ordinary triage dependent on that fact, not all handling. Supplement, verification, and risk escalation per independent rules and authorization may proceed; escalation must retain conflict record, cannot treat unverified model as fact. With this package, the specialist knows what to verify, what actions are allowed, and how the flow continues after resolution. Human confirmation step must be designed in from the start.

Request Sent, Still Must Confirm the Job Is Done

In this case, the final workflow node is "submit triage request". Node call success only means interface processed to some step; whether ticket actually entered the specified repair team's queue requires source system result.

Safer design separates "generate action candidate" from "initiate formal action".

Action candidate passes reviews, then controlled action service generates formal action request carrying at least: target object, action type, parameters, business version, basis, authorization context, idempotency key, validity period. Formal request must still pass source system permission and state checks; cannot bypass execution boundary just because upstream reviewed.

Fact confirmation and action approval must be recorded separately. When human approval needed, approval must bind specific object, action type, parameters, candidate version; if key content changes, original approval expires, must re-submit approval.

If during "awaiting human confirmation" the ticket is closed by someone else or manually moved to another queue, the old suggestion must not silently execute. Runtime must re-check current state and version before submission. For side-effect actions, interface "accepted" is not final completion; still rely on source system state or controlled receipt.

Otherwise logs show every node succeeded, but ticket was routed to wrong queue by stale suggestion.

Define Who Handles Errors and When to Stop Before Launch

Arrange the above into a "State and Escalation Path Table". When exceptions occur, system and handlers know the next step:

waiting_input : critical materials missing or unreadable → request supplement, retain existing evidence; responsible: ticket initiator or service specialist; exit: re-check after materials qualified; timeout → exceptional close.

retryable_failure : recoverable and retry conditions met, no pending side-effect reconciliation → retry per count, backoff, time window; responsible: platform ops team; exit: re-check after success; count or time exhausted → exceptional close.

data_conflict : source records conflict → flag conflict, block actions dependent on conflict fact; allow supplement, verification, and risk escalation per independent rules and authorization; responsible: data owner or business specialist; exit: re-check after conflict resolved and logged; escalate per agreed path retaining conflict record; timeout → exceptional close.

needs_review : rules require business fact confirmation or specific action approval → dispatch evidence package, distinguish confirmation from approval; responsible: authorized business role; exit: re-check after approval; reject → exceptional close; expire → re-validate and re-dispatch per SLA or close.

ready_to_execute : action candidate passed evidence, rules, state, authorization review → generate formal request, record request ID, submit; responsible: controlled action service; exit: if request sent, track receipt; explicit reject → exception handling.

awaiting_result : request sent, no confirmed final result → query and reconcile by request ID; do not blindly resend when result unknown; responsible: action service and source business system; exit: confirmed success → completed; explicit failure or reconciliation timeout → exception handling.

completed : source system confirms action success and reaches contract target state → archive action receipt, evidence, audit records; responsible: controlled action service; exit: terminal state; subsequent changes create new linked task.

closed_with_exception : hard constraint block, human reject, unsafe recovery, or SLA exceeded → stop auto-progression, hand to responsible person with audit retained; responsible: process owner; exit: terminal state; if continuation needed, create new linked handling task.

"Completed" here means this action executed per request, e.g., ticket entered requested repair team queue — not that device repair finished, nor that triage judgment was correct. After runtime completion, output verification per contract is still required; only when quality, timeliness, and observation window requirements are met does it count as verified qualified output. Later discovered mistriage adds quality record and revises measurement, preserving original execution facts.

Exceptional close only stops current auto-flow; unconfirmed side-effects must continue reconciliation via linked handling tasks, not lost with flow closure.

Simple Flows Need Not Adopt Full Mechanism

For low-risk, advisory-only internal knowledge QA that does not directly trigger actions, full action request and multi-role approval system is usually unnecessary; but still need defined retrieval scope, source citations, permission filtering, basic quality validation, and feedback entry. Read-only answers can influence subsequent human operations; cannot deem risk low just because "no write interface".

But if a workflow:

Combines facts across systems and affects downstream tasks;

Impacts customers, funds, resources, compliance, or safety;

Runs long enough for state changes during execution;

Depends on multiple models, knowledge versions, or external systems;

Requires recovery after exceptions, not simple failure;

then evaluation, repair, human confirmation, and execution boundaries must be designed as runtime capabilities, not left for ops staff to remediate after the fact.

Summary

The ticket with model conflict stopped as expected. Who receives evidence, how to continue after verification, who takes over after timeout — all pre-arranged, so handlers don't re-investigate from scratch each time.

With these arrangements, the next question: how many processed tickets count as qualified delivery? Next article "AI Reports Show Success, Why Becomes Rework in Business Hands?" continues discussion.

Reference

InfoQ, "Model Strong, Why Demo Still Can't Enter Production?" This article uses the vendor engineering practice's framework of "operators, orchestration, evaluation, and human confirmation" to discuss enterprise AI runtime governance, not adopting its case data as general conclusions.

https://www.infoq.cn/article/j2kBZR1JiZxATpU7gjtS