Recorded evidence · Chapter 31

Replay Chapter 31: One Agent, Three Drivers

The same scripted run through print, JSON and RPC on the shipped pi binary, and the same failure three ways.

← Read The Interface Is Not the Agent
Execution Recordedshipped binary

This is a recording, not a live run. The experiment ran in the book's test harness on 5 October 2026, with a scripted stand-in for the model. Nothing executes in your browser, and nothing here shows how a real model behaves.

Claim

One agent, three drivers

The same agent behind print, JSON and RPC does the same thing and gives the same answer. What differs is the observer and the failure contract.

Prediction, stated before the run

The final answer and the lifecycle events match across drivers. A failed response is an exit status in print mode, and lives only in the stream in JSON mode and in RPC.

Result: PASS 9 observations · OBSERVED · shipped binary

Evidence

What was observed

ObservationExpectedObserved
All three interfaces end with the same final answer identical identical held
JSON and RPC show the same lifecycle events in the same order identical identical held
The tool ran under the driver yes yes held
A failed response, print mode: exit status non-zero 1 held
A failed response, JSON mode: exit status 0 0 held
A failed response, JSON mode: the failure is in the stream stopReason error error held
A failed response, RPC: the prompt command succeeded true true held
A failed response, RPC: the failure is in the stream stopReason error error held
RPC acknowledges before the run: disposition started started held

Trace

What happened, in order

Print mode, success

The whole interface is the final text and an exit status.

  1. driver print mode exits 0
    0 ms
  2. observer stdout is one string: "the answer is forty-two"
    0 ms

JSON mode, success

Events on stdout. No command responses.

  1. agent agent_start
    0 ms
  2. agent turn_start
    0 ms
  3. agent tool_execution_start (bash)
    0 ms
  4. agent tool_execution_end
    0 ms
  5. agent turn_end
    0 ms
  6. agent turn_start
    0 ms
  7. agent turn_end
    0 ms
  8. agent agent_end
    0 ms
  9. agent agent_settled
    0 ms
  10. driver JSON mode exits 0
    0 ms

RPC, success

A response arrives first and means accepted. Events follow. The process stays up until stdin closes.

  1. driver response to prompt (id p1): success=true, disposition=started
    0 ms
  2. agent agent_start
    0 ms
  3. agent turn_start
    0 ms
  4. agent tool_execution_start (bash)
    0 ms
  5. agent tool_execution_end
    0 ms
  6. agent turn_end
    0 ms
  7. agent turn_start
    0 ms
  8. agent turn_end
    0 ms
  9. agent agent_end
    0 ms
  10. agent agent_settled
    0 ms
  11. driver RPC exits 0 when stdin is closed
    0 ms

Print mode, failed response

The failure is the exit status.

  1. driver print mode exits 1
    0 ms
  2. observer the message is on stderr: "provider exploded"
    0 ms
  3. observer stdout is empty: ""
    0 ms

JSON mode, failed response

The failure is in the stream, and the exit status is 0.

  1. agent the stream carries stopReason: error
    0.2 ms
  2. driver JSON mode exits 0. A script that checks only $? calls this a success
    0.2 ms

RPC, failed response

The command succeeded; the model call did not. The failure is in the stream.

  1. driver the prompt command itself succeeded: success=true
    0 ms
  2. agent the stream carries stopReason: error
    0 ms

Provenance

Where this came from

node
v25.8.2
pi-agent-core
1.0.2
pi-ai
1.0.2
pi-coding-agent
1.0.2
platform
win32
model
faux (scripted)
test
examples/ch31-interface/binary.test.ts
exporter
examples/experiences/ch31.ts

What this does not show

  • The model is scripted. This shows what the process does with a response, not how a real model answers.
  • Run on the shipped pi binary under the platform in the environment panel. Shell behaviour may differ on other platforms.
Inspect the context supplied by this chapter

Pinned to Pi 1.0.2. Drivers: --print, --mode json, and RPC over stdin and stdout, all against the shipped binary with a scripted provider. Claim class: observed. Source: examples/ch31-interface/binary.test.ts.

The recording drives the real pi process three ways with a scripted model. The agent does the same thing each time; what changes is who observes it and how a failure is reported.