Let your workflows escalate to VDF AI instead of migrating to it.

Draw the line the deterministic path should keep

Write down what your engine will continue to own outright: validation, state transitions, compensation, SLA timers, and every case a rule already resolves. Escalation only makes sense as an exception to a path that stays authoritative — if you find yourself escalating the majority of cases, the rules are the problem, not the reasoning.

Make the trigger explicit and measurable

Name the condition in code, not in a comment. In practice it is one of four: a classifier below a confidence floor, an unmatched rule, a case sitting past an SLA threshold, or a queue depth that a shift cannot clear. Log the trigger on the case so you can later count how often each fired and whether escalation actually helped.

Mint a short-lived token per escalation

Authenticate with an HS256 JWT in the Authorization header. Issue it from a service identity at call time rather than parking a long-lived credential in the workflow engine's connection settings.

curl -sS -X POST "$AGENTHUB/api/agent/health" \
  -H "Authorization: Bearer $VDF_JWT"

# 401 { "success": false, "error": "JWT token invalid", "code": "invalid_token" }

Verify auth against a health call before wiring the real branch — it separates credential problems from payload problems on day one.

Hand the case over and keep the run identifier

Execution returns immediately with an identifier. Persist it on your case record in the same transaction that marks the case escalated, so a crash between the two never loses the link.

POST $V3/networks/claims_exception_review/execute
Content-Type: application/json

{ "input": { "claim_id": "C-88213", "reason": "no_rule_match", "documents": ["…"] } }

-> { "run_id": "6a2c…" }

Track the run instead of blocking on it

Subscribe to the event stream where your engine supports long-lived connections, and fall back to polling the run record where it does not. Both read the same state, so a hybrid — stream when you can, poll on reconnect — is safe.

WS   $V3/runs/<run_id>/events        # live: type, ts, node_id, payload
GET  $V3/runs/<run_id>               # run record (poll with backoff)
GET  $V3/runs/<run_id>/nodes/<node>  # the specific step you care about

Poll with backoff rather than a tight loop, and cap total wait with a timeout that maps to your own SLA — an escalation that has run past its usefulness should go to a human, not keep waiting.

Bring back a decision, not a paragraph

Read the node whose output your next step actually consumes and map it onto your own domain vocabulary — an enum your process already understands, plus the supporting text. Store the run identifier and the proof reference alongside it so the case file answers "why" without anyone logging into a second system.

GET $V3/runs/<run_id>/proof           # provenance for the case file
GET $V3/runs/<run_id>/related?top_k=5 # comparable prior runs

Keep the human queue as a first-class outcome

Route anything the run could not settle to the reviewers who handle it today. When they correct it, capture the correction as hints on that run and apply them to a derived network — the queue stops being pure cost and becomes the training signal for the next version.

GET  $V3/runs/<run_id>/hints
POST $V3/runs/<run_id>/apply_hints -d '{ "mode": "new_network" }'

Harden the branch like any other dependency

Give the escalation path the same operational treatment as a payment gateway: exponential backoff that honours Retry-After on a 429, a circuit breaker that diverts to the human queue when error rates spike, an idempotency key so a retried workflow step never starts a second run, and a per-period cap so one upstream incident cannot exhaust a month of capacity in an afternoon.