Harness earned one new primitive by preserving opaque Provider protocol state separately from model-visible messages.
The transcript was complete—and the request still failed
Consider a familiar Agent turn:
User asks
→ model emits Tool call
→ Tool executes
→ Tool result returns
→ model continuesIf you are building a Harness, it is natural to treat the semantic conversation as the thing that must survive interruption.
User message. Assistant Tool call. Tool result. Maybe the raw Provider response digest for audit.
That seems complete.
The second-Provider experiment constructed exactly that falsifier with Gemini.
One request preserved the semantic Tool call and the exact Provider continuation signature. The next preserved the same semantic content but stripped only the signature.
The missing state was not optional decoration.
The missing state was also not a message
Google documents thought signatures as encrypted Provider state used to preserve reasoning context across multi-step interactions. For Gemini 3 function calling, manually managed histories must return the relevant signatures or the request can fail validation.
That still does not make a signature a sentence the Agent should read.
The Harness experiment retained a 940-byte continuation with an exact digest. It deliberately kept those bytes hidden from Agent messages.
semantic Tool call
+ Tool result
+ opaque Provider continuation
where:
semantic history ≠ opaque continuationThis is an important kind of state: necessary for the protocol, meaningless as user-facing prose, and unsafe to let arbitrary callers forge.
Why not just put the bytes in history?
Because doing so collapses three different authorities.
- Agent cognition is the semantic material the model is allowed to reason over.
- Provider protocol continuation is opaque state required by the bound Adapter and Provider lineage.
- Caller input is new semantic material supplied by an upstream owner.
If all three become “messages,” a caller can potentially inject reserved continuation-looking fields, Provider-specific bytes start polluting model-visible context, and privacy policy becomes difficult to state.
Harness instead binds continuation authority to the exact prior Provider Tool result and completed-Provider lineage.
Initial Run messages and resumed caller messages cannot mint that authority by copying a shape.
Crash/reopen was the real test
Passing one request in memory would only prove a serialization adapter.
The useful question was whether the continuation could survive the kind of interruption Harness exists to handle.
The live second-Provider run did this:
Gemini Tool response
→ exact continuation retained under Run authority
→ process boundary / reopen
→ SQLite continuity reconstructs authority
→ next Provider request receives continuation
→ model completesThe reopened run finished with summary LIVE_CONTINUATION_OK.
The Provider returned HTTP 200 before and after resume. The continuation remained hidden from Agent messages. Store Doctor remained healthy. Runtime redispatch count after reopen was 0.
The recovery therefore preserved Provider protocol continuity without replaying the physical Tool effect.
Privacy decided whether recovery was even allowed
Durability is not automatically permission to retain content.
Harness already had Runs whose privacy contract allowed metadata-only retention. Those Runs are not silently upgraded just because a Provider protocol would benefit from opaque continuation bytes.
Exact crash/reopen recovery of Provider continuation is available only when the Run Contract already authorizes the necessary content retention.
A protocol need can justify a data type. It does not erase the authority that decides whether those bytes may be persisted.
Five features entered. One left.
The Provider continuation experiment was part of a broader Harness cross-validation round. Five frontiers had to beat simpler controls before becoming product machinery.
This matters because a Provider-specific failure could easily have triggered a large “Provider State” subsystem.
It did not.
The new primitive is deliberately boring
The product addition is named ProviderToolContinuation.
It can carry one Tool-result continuation bound to:
- an Adapter;
- the source turn;
- the source model call.
The request projects ordered Provider continuations separately from model-visible messages. Harness-reserved continuation metadata is stripped from semantic messages. SQLite recovery independently reconstructs and verifies the authority before Provider claim.
No new service was added. No new database schema was required. No built-in Gemini Adapter was promoted.
What the Provider knows is not what the Agent knows
The broader lesson is easy to miss in Agent architecture diagrams.
A model turn has more than one kind of continuity:
semantic continuity — what the Agent can reason about
protocol continuity — what the Provider requires to accept the next request
physical continuity — what Tools actually did
Task continuity — what larger commitment is still openPutting all four into one conversation log does not simplify the system. It hides who can prove each fact.
What would reopen the boundary
The primitive should remain small unless another Provider or protocol exposes a materially different continuation fact that cannot fit the same authority model.
Cross-Provider evidence may eventually justify a richer abstraction. One Provider's opaque bytes do not.
The missing 940 bytes taught us something larger than how to satisfy one API: durable state can be necessary precisely because the Agent should never have to think about it.
Primary sources