Your Agent Didn’t Fail. Your Harness Did.

[upbeat music] Thank you for choosing to spend this session with me.

My goal today is simple. I want to convince you all that most of the production failures are not-- most of, most of the agent failures are not model failures.

Those are harness failures. So let's start with one production incident.

The user saw the reply. The system forgot it happened. This is a failure shape I want to start with. Not a hallucination, not a crash, not a bad answer.

The user-visible edge looked healthy while the durable record ha-had a hole.

In this example, the user asked the customer-- the agent to remember a refund for a customer.

The assistant said it recorded the fact for the next turn. The interface looked normal, no red screen, no obvious failures. But the next turn cannot reconstruct the fact. The user experienced success.

The system inherited incomplete reality. Why this matters? A crash is annoying, but at, at least it gives you a boundary. You know so- you know something stopped. You usually see an error.

You can often start from last known good point. Silent success gives you a lie. Delivery can succeed while the persistent fails. The user has no reason to doubt the reply.

The operator has no obvious alarm. The next turn can still sound confident

because the model is coherent. But it is coherent over a bo-broken history.

That is why agent reliability matters, and agent reliability cannot stop at model quality.

Hi, I'm Vinoth. I work on core data and AI infrastructure at OpenAI.

Before that, I worked on distributed systems at Apple and Uber. Outside of the work, I write the Agent Stack, where I try to explain how the production AI and data systems work under the hood.

I'm not a mentor of OpenClaw, and this is not a OpenClaw product pitch. This is a pure system design talk. I'm using OpenClaw as a public case study because

its issues, code, docs, makes the harness around the a-agent unusually visible.

Here's the production contract for the talk. A model proposes, the harness commits, and the receipt proves it. The model ca-- may suggest a message, a tool, a edit, or an command, but model is not the production boundary.

The harness owns the state transition, the authority check,

the ordered commit, and the receipt is the evidence that survives the turn. OpenClaw is the case study, and the contract is the takeaway.

If you remember only three things from this talk, make it these: own the state, order the mutation, and prove the action.

A fact needs only one owner and one replay path. Shared mutable state needs one ordered commit path. And transcript is not the proof. A transcript tells you what the agent said.

A receipt tells you what the system allowed, attempted, executed, and what the user-visible edge confirmed.

To create a simple mental model, I created this car analogy of the harness. The model is the engine.

It matters a lot. But nobody, uh, buys a production car by just looking at the horsepower alone. You also care about steering, brakes, road rules, dashboard, and a black box.

The model gives you capability, but the harness gives you control.

A powerful engine with no brakes is not autonomy, it is a liability with good acceleration.

Here is the harness blueprint I wanted to, uh, discuss today. Every agent we know of, like personal agents such as OpenClaw or Hermes, coding a-agents such as Codex, Cursor, OpenCode, or Claude Code, uses the same underlying architecture.

Events enter, enter from many surfaces: a chat, webhook, timer, or heartbeat, or another external system. The control plane maps the events to a session key, and the session key de-determines the state boundary.

The session lane gives you one active writer for the mutable state.

The runtime calls the models and tools. Tools act through approvals and policies. An audit trail becomes the run receipt. This is the blueprint: event, session key, throttle, tools, audit.

The blueprint is the talk, and the incident was the proof that each boundary matters.

Context is assembled. Uh, uh, in agent runtime, th-there's not-- does not usually remember in human sense. It is stateless.

The harness rebuilds the working state for the each turn. The working set may include the transcript, session state, memory, policy, tool definitions.

The model only sees what the harness supplies. If one input is missing or stale, the answer may still sound coherent. Coherence does not prove the working set was complete.

These failures are not new. We already know about timeouts, retries, idempotency, logs, ordering, and state ownership. What changed is the a-agent setting.

Now these failures sit around a probabilistic planner with dynamic plans. It's rebuilding the context for every turn. There are more event sources, and it can act through more action surfaces.

So these failures are familiar.

Agents makes them easier to trigger and harder to explain. That's why Agent harness matters.

Let's talk about the first failure mode. This is the same failure mode I started this talk with. The user sees a success, the source of truth cannot replay it.

Delivered is not remembered. In this state hole OpenClaw issue, a Telegram replay could succeed while the router turn was not returned to the active context or transcript. The user saw the response, the log looked healthy,

but the next turn had no durable record of that exchange. A successful send proves transcript. It does not prove the future context. That distinction matters because the model can answer fluently over an incomplete record.

The missing boundary was not intelligence, it was the state ownership.

By owner, I do not mean a person, I mean the system of record whose persisted state becomes the truth.

A calendar event belongs to the calendar system, a support status belong to the ticketing system, while a code change belongs to a workspace or repository, and a conversation turn belongs to a session transcript, and a user preference belongs to a memory store.

Storage tells you where the bytes live. Ownership tells you who can reconstruct the reality.

A replay is not a reliable memory until, until a named owner can replay it. A system has to persist the turn, it has to name the owner or system of record, and it has to make the replay possible.

The real question is simple: For every fact the agent might use later, who owns it, and how would you replay it?

If no owner can replay the fact, the s- the system did not reliably remember it.

Once we know who owns the state, the next question is: Who's allowed to change it, and in what order?

Two correct writes can still produce one wrong outcome, and last writer wins is not a consistency model.

In this overlapping writer OpenClaw issue describes a load-modify-save race. Two callers loads the same old state. Each changes a different record. The sile-- The sec- the second save silently erases the first.

The user may see a dismissed commitment return or receive a duplicate follow-up. Neither writer is malformed. Both operations are locally correct. The missing boundary is serialization around the commit.

The invariant is not no concurrency. That would be too slow, and it would miss the point. You can fan out sub-agents. Parallel reads are fine. Independent retrieval is fine.

Many sessions can also run at once. The rule is narrower and simple. One ordered commit path for one mutable state boundary.

This mechanism may be a queue, a mutex, a transaction, or a lock. You can use locks or mutex across the sessions and queues or transactions within a session.

Be conservative with the commit time and not across the whole system.

Users do not see queues or locks, they see behavior. A last correction feels forgetful, a stuck lane feels dead, and completion before delivery feels confused. Ordering is a product feature because users experience ordering books as personalities.

Let's-- Now let's talk about time. In production, silence cannot be neutral. Let's review, uh, the next, uh, failure mode is life cycle failure mode. The RAN waits for an event that cannot arrive.

Silence is not a terminal state. In this dangling tool call issue, the session contains a tool call but no matching tool result. A process may have died, a connection may have dropped, a timeout might have happened, happened before the results were recorded.

The exact cause, uh, matters for debugging. The production failure is much simpler. The RAN is waiting for an event that will never arrive.

New messages queue behind that silence. To the user, the agent simply looks stuck.

RANs needs deadlines and cancellation. A deadline bounds the wait. Watchdog makes the stuck work visible. Tools needs timeouts and error results. Channels needs recovery commands that do not wait behind the stuck work they are trying to fix.

Every external boundary needs an ending: success, failure, timeout, cancel, or max attempts.

Most im-importantly, the receipt records the terminal outcome, so the next step does not have to guess. Bound the work before the work bounds you.

Now let's, uh, we can move on from state to authority, because a chat becomes risky when it becomes an action. Capability is not execution. The model can request an action.

Request ability is not authority. Approval needs a shape.

In this approval drift issue, expired approved callback was treated as retrievable. The state call-callback stayed durable, survived restarts, and blocked later channel work. The button click existed, the valid authority did not.

This is the mistake. Treating approval as a vague memory that the human was near the system or clicked yes.

Approval is a scoped execution state. It must stay bound to the action it authorized, and expiration must terminate rather than loop.

A useful approval object answers who approved, in what session and RAN. For wh-which tool and for which arguments, and for how long, and with what outcome.

It also point to the receipt. If those fields fall off during a retry, replay, or a channel callback, the harness can no longer prove the action was being executed as the action being approved.

The general lesson is simple. Capability is not execution. Least privileges narrows the tool surface. Scoped credentials ensures the right identity is used for the action. Approval and audit decides what happens before and after the execution.

The model can reason about the boundary, but it should not be the boundary. The model can request, but the s- still the system decides.

Finally, even if the tool says success, the user visible world may disagree. Internal component reports success, the user visible surface shows nothing. This is the inverse of the opening incident we saw.

In this missing edging-- edge proof issue, the message tool reported success for a web chat or TUI run, but the message did not render. Normal assistant reply still appeared.

The tool pro-proved that the internal path accepted the request. It does not prove the user saw the result. That difference changed the conversation. The agent may later say, "I already sent it," and the user may truthfully say, "I never saw it."

Internal success is not external proof. Proof is a chain, not a claim. Model proposed something, policy allowed or denied it, execution attempted it, user-visible edge confirmed or failed to confirm the outcome.

The receipt preserves that chain. A transcript records what the agent said. The tool results records what one component claimed.

A receipt records what the agent can verify at the boundary that matters.

Let me recap all the incidents. Here are the file failure shapes you, you to look for: a state hole, overlapping writers, dangling tool call, approval drift, and missing edge proof.

For each one, let's ask the same question: What did the user see? Which boundary it broke? And what would the receipt have caught?

Here is the audit I want you to run when you get back to your team. Pick one agent system, not all of them. One.

Trace one production-- one real production path and ask for the receipt.

The audit has five questions: What woke it up? What state did it inherit? Which authority did it use? What executed? And what evidence survived? These

questions expose causality. They turn a few fluent conversation into an inspectable production run.

First, what woke it up? A user message, webhook, timer, tool result, sub-agent, or a replay. Name the trigger and its identity. Without that, you cannot reason about deduplication, order, or authorization.

Second, which state did it inherit? Transcript, session state, memory snapshot, policy version, and tool surface. The model only reasons over the working set the harness assembled.

Third, which auto-authority did it use? Record the actor, session, tool, run, arguments, scope, and lifetime. A model request is not permission. Authority should bind to a one pending action.

Fourth, what executed? Record the tool or API call, arguments, attempt number, idempotency key, and external results. This is a side effect boundary, not the poor summary of what the agent intended.

Fifth, what evidence survived? Did the ticket get updated? Did the message got rendered? Did the file got changed? Did the calendar even exist? The receipt should end at the boundary the usual-- the user usually cares about.

Now let's apply the opening incident, uh, the same audit to the opening incident. What woke it up? A user message. What state it owned that was the broken boundary?

What executed the channel send? What evidence survived delivery? What did not save-- survive the durable turn?

Delivery survived while the st-state did not. That gap is the harness failure.

The agent, uh, do-- did not need a better model. The model did not need a better prompt. The system needed a better harness with complete receipt.

Let me recap the same three things I asked you to remember the, from the start of my talk. Own the state, order the mutation, and prove the action.

A better model helps inside the turn. Ownership, ordering, life cycle, authority, and proof keep the system sane across turns.

A model proposes, the harness commits, and the receipts-- receipt proves it. Once text can become an action, the useful question changes. Do not only ask whether the model can reason, uh, ask whether the system can own the state, order the mutation, bound the work, constraint authority, and preserve evidence.

A loop can answer a turn, and harness can serve a production.

If you want to go deeper, scan the QR codes. The first points to the agent-- OpenAI Agents SDK, where all these, um, harness are already built in so that you can use to build your own agents.

And second points to The Agent Stack, where I write about the production agents systems in more detail. I'll be at the OpenAI booth after this talk if you want to talk about your harness design.

Thank you. [audience applauding] [outro jingle]