# Your Agent Didn't Fail. Your Harness Did. Vinoth Govindarajan, OpenAI | AI Engineer World's Fair 2026 | 18:26 Source: https://www.youtube.com/watch?v=BInpv7lGp1o Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/your-agent-didnt-fail-your-harness-did Published: 2026-07-29 Tags: agents, observability, reliability ## TL;DR - Most production agent failures happen in the harness around the model, where state, ordering, execution, and delivery are managed. - A model proposes an action, the harness commits it, and a receipt proves what the system allowed, attempted, executed, and delivered. - A run receipt audit should answer what woke the agent, what state it inherited, what authority it used, what executed, and what evidence survived. ## Summary Vinoth Govindarajan argues that many production agent failures are system failures rather than model failures. An agent can send a successful reply while failing to persist the turn, so the next response is based on incomplete state. Two writers can load the same state and silently erase each other's changes. A tool call can wait forever when no deadline or cancellation path exists. An approval can survive a restart even though the action it authorized has expired. A tool can report success while the user sees nothing. Govindarajan uses OpenClaw as a public case study and presents a simple contract: the model proposes, the harness commits, and a receipt proves the result. The receipt must connect the trigger, inherited state, authority, execution, and user-visible evidence. His practical recommendation is to audit one real production path using five questions, so teams can inspect what happened instead of relying on a fluent transcript. ## Key ideas ### A successful reply can hide a broken durable record [00:01](https://www.youtube.com/watch?v=BInpv7lGp1o&t=1s) The opening incident has a healthy-looking user interface and no crash, but the system forgets that the agent recorded a refund. The user experiences success while the next turn inherits incomplete reality. Govindarajan says a crash gives operators a boundary and an error, while silent success gives them a lie. The model can remain coherent because it is reasoning over a broken history. Delivery therefore does not prove persistence. A send can succeed while the durable turn or future context is missing. ### The harness owns state transitions and receipts prove what happened [02:20](https://www.youtube.com/watch?v=BInpv7lGp1o&t=140s) Govindarajan's production contract is: "A model proposes, the harness commits, and the receipt proves it." The model can suggest a message, tool call, edit, or command, but it is not the production boundary. The harness owns the state transition, authority check, ordered commit, and surviving evidence. He reduces this to owning the state, ordering the mutation, and proving the action. A transcript records what the agent said. A receipt records what the system allowed, attempted, executed, and what the user-visible edge confirmed. ### The harness rebuilds each turn from an explicit working set [04:14](https://www.youtube.com/watch?v=BInpv7lGp1o&t=254s) Events can arrive from chat, webhooks, timers, heartbeats, or another external system. The control plane maps each event to a session key, which defines the state boundary. The harness then rebuilds the working state for the turn from sources such as the transcript, session state, memory, policy, and tool definitions. The model only sees what the harness supplies. If an input is missing or stale, the answer can still sound coherent. Govindarajan's point is that coherence does not prove the working set was complete. ### Every mutable state boundary needs one ordered commit path [05:48](https://www.youtube.com/watch?v=BInpv7lGp1o&t=348s) An OpenClaw race involves two callers loading the same old state, changing different records, and saving them. The second save silently erases the first. Both operations can be locally correct, yet the final result is wrong. Govindarajan does not call for eliminating concurrency. Parallel reads, independent retrieval, and multiple sessions can continue. The narrower rule is one ordered commit path for one mutable state boundary. A queue, mutex, transaction, or lock can provide that path. Users experience ordering as behavior: a correction can feel forgetful, and a stuck lane can feel dead. ### Unfinished work must have a terminal outcome [10:09](https://www.youtube.com/watch?v=BInpv7lGp1o&t=609s) A dangling tool call leaves a session with a tool call but no matching result. The process may have died, the connection may have dropped, or a timeout may have happened before the result was recorded. The production problem is that the run waits for an event that will never arrive, while new messages queue behind it. Runs need deadlines and cancellation. Watchdogs must make stuck work visible, and recovery commands must not wait behind the work they are meant to fix. Every external boundary needs an ending such as success, failure, timeout, cancellation, or a maximum attempt count, recorded in the receipt. ### Approval must stay bound to the action it authorizes [11:23](https://www.youtube.com/watch?v=BInpv7lGp1o&t=683s) An approval can drift when an approved callback remains durable across a restart and is treated as retryable after its valid authority has expired. Govindarajan says approval is a scoped execution state, not a vague memory that a person clicked yes. An approval object should identify who approved, the session and run, the tool and arguments, the duration, the outcome, and the receipt. Expiration should terminate the action rather than create a retry loop. The model can request an action, but the system decides whether the authority is valid. ### Internal tool success does not prove user-visible delivery [13:05](https://www.youtube.com/watch?v=BInpv7lGp1o&t=785s) A message tool can report success because an internal path accepted the request, while the web chat or terminal interface renders nothing. The agent may later say, "I already sent it," while the user truthfully says, "I never saw it." Govindarajan describes proof as a chain: the model proposed something, policy allowed or denied it, execution was attempted, and the user-visible edge confirmed or failed to confirm the result. The transcript records the agent's words, and the tool result records one component's claim. The receipt must preserve evidence at the boundary that matters. ### A five-question receipt audit makes a run inspectable [14:08](https://www.youtube.com/watch?v=BInpv7lGp1o&t=848s) The audit starts with one agent, one trace, and one real production path. It asks what woke the agent, what state it inherited, which authority it used, what executed, and what evidence survived. The trigger might be a user message, webhook, timer, tool result, subagent, or replay. The inherited state includes the transcript, session state, memory snapshot, policy version, and tool surface. Authority records the actor, session, tool, run, arguments, scope, and lifetime. Execution records the call, attempt number, idempotency key, and external result. Evidence ends at the boundary the user cares about, such as a rendered message, changed file, updated ticket, or existing calendar event. ## Notable quotes - "A model proposes, the harness commits, and the receipt proves it." (02:20) - "A powerful engine with no brakes is not autonomy. It is a liability with good acceleration." (03:19) - "A successful send proves transcript. It does not prove the future context." (06:36) - "Internal success is not external proof." (13:37) - "The model did not need a better prompt. The system needed a better harness with complete receipt." (16:25) ## Tools & references mentioned - OpenClaw - OpenAI Agents SDK - Agent Stack - OpenAI - Apple - Uber - Telegram ## Who should watch - You run agents that can send messages, modify files, update tickets, or call external APIs, and you need to know whether a reported success reached the user and durable state. - Your incidents involve stale context, duplicate actions, overwritten changes, stuck tool calls, or approvals that survive longer than the actions they authorize. - You want a practical audit for one production path instead of relying on transcripts or model evaluations alone.