Core Update: Making Agent Reasoning Recoverable through Dual-Chaining Framework
Vivo’s Knowledge-driven Computing (KDC) team recently published “How to Make Agent Reasoning and Actions Recoverable Software Facts,” the sixth installment of the KDC engineering series. It addresses a critical gap between prototype and production: being able to execute one loop does not mean the system can run reliably in real products. Based on internal practice, the team proposes dual-chaining architecture—linking business causality and runtime facts—and decouples Session, Harness, and execution environments to handle refreshes, restarts, and interrupted approvals.
- Lead author: vivo engineer Xiao Bo; AI collaborator: ChatGPT (GPT-5.5)
- Creation mode: Human-led, AI-collaborated (author holds all responsibility)
- Series position: KDC’s sixth engineering supplement; first five established Reality→Feedback闭环
- Availability: KDC remains in open research phase; no commercial product yet
Three Distinct Facts Must Not Be Confused
The paper argues that Agent systems contain three fact types that must be separated—confusing them causes production failures:
- Domain reality: External world states such as whether refund money has arrived; software can only perceive indirectly
- Business judgment facts: What goals, knowledge, and evidence led to a conclusion and suggested an action; corresponds to KDC’s reasoning objects
- Software runtime facts: Actual operational states during a run—whether Run started, Tool completed, etc.
A key counterintuitive insight: tool.call.completed does NOT mean funds arrived, and pendingApproval=null does NOT mean user approved. Runtime can authoritatively declare “this call completed,” yet cannot infer business outcomes from runtime facts alone. UI can display an approval banner, but cannot infer authorization was revoked just because the banner disappeared. This is precisely why system restarts cause duplicate refund calls: knowledge and policy are correct, yet the runtime fact chain is broken.
Dual-Chaining: Bridging Business Causality and Runtime Facts
Vivo proposes two interconnected chains, stability depends on cross-referencing stable identifiers:
- Business causal chain: Reality → Knowledge/Memory → Reasoning → Skill → Capability → Policy Decision → Action → Feedback → Reality
- Runtime fact chain: Runtime Event → State → View → Checkpoint → Resume ←→ User Control ←→ Runtime Event
Connecting them requires stable identity tags including runId, turnId, reasoningObjectId, skillId, capabilityId, policyDecisionId, approvalId, toolCallId, artifactId, feedbackId. These IDs let the system trace: which judgment a banner belongs to, which capability spawned a Tool Call, which goal an Artifact supports. Vivo specifically warns: connection relies on stable IDs—not copying more text. Frequent context compression that loses key ID references still causes recovery failure.
Decoupling Session, Harness, and Execution Environment
Inspired by Anthropic’s Managed Agents, vivo decomposes Agent Harness into three layers:
- Session: Persistent event log and state, rebuildable across Harness instances
- Harness: Stateless loop controller and context organizer, rebuildable from Session after crash
- Sandbox: Isolated execution environment, handles actual code/Tool execution
This decoupling yields three benefits:
- Recovery no longer tied to original instance: New Harness can take over from external Session,只需 interface and Event Schema compatibility
- Brain and hands scale independently: Single Harness drives multiple Sandboxes; long-running tasks continue after model call ends
- Security boundary upgrades from prompt constraints to structural constraints: High-privilege credentials never enter model context; capability agents issue minimal permissions and record executionEnvironmentId, sandboxTrustLevel, credentialScope, etc.
Practical Guidance: Distinguish State, View, and Control in Agent Design
- Adopt immediately if: You’ve deployed ReAct but face approval loss, duplicate execution, or untraceable state problems—pricing the runtime fact chain with stable identifiers and persistence should be priority one
- Wait longer if: Your project lacks stable Tool Call state tracking—avoid letting frontend infer runtime state from chat text (e.g., generating approval buttons from the phrase “requires user confirmation”)
English readers can refer to vivo’s first five KDC articles for full theoretical grounding: Reality First, Knowledge Engineering, Action Governance, and Long-Running都能已建立.
Final Word
Production-ready Agent maturity is no longer about whether a single-model inference is correct, but whether the system maintains fact-chain consistency after power loss, restart, or interruption. Dual-chaining and Harness decoupling mark the critical divide between “one successful run” and “reliable product.”