00. Reading the Agent Runtime from Its Traces

In July 2026, I gave Codex CLI, Claude Code, Grok CLI, and Kimi Code CLI the same read-only task and recorded the requests they sent through a shared proxy. The instruction was identical, but the clients assembled different context structures, exposed different tools, preserved state differently, and stopped at different failure boundaries.

Two requests completed a tool loop. The other two stopped at organization-policy and quota checks. This asymmetry did not produce a useful capability ranking. It exposed a more precise question: what does the runtime outside the model allow an Agent to see, execute, remember, and recover?

This series turns that capture into fifteen bounded experiments. Each article changes one runtime variable while keeping the task, fixture, permissions, and observations stable.

The boundary of this series

The site already contains two broader Agent series:

• The Agent Pattern Manual covers ReAct, planning, memory, tools, and frameworks.
• Understanding AI Agents in Depth studies the wider harness around a model.
• This series is limited to behavior that can be supported by requests, event logs, controlled comparisons, or fault injection.

“Observed” means that a field or event is present in the captured material. “Inferred” means that I am explaining its engineering consequence. A failed request cannot establish the full behavior of a product, and hidden prompts are not reconstructed from another client.

Part I: prompts and context

Article 01 reconstructs how platform rules, project instructions, environment data, history, and the current task become model context.

Article 02 records input growth across turns and separates context-window limits, cumulative input, prefix caching, trimming, summaries, and server-side state references.

Article 03 places injection text in user input, project files, tool output, retrieval results, and memory. It then distinguishes model interpretation from enforceable execution policy.

Part II: tool protocol and execution

Article 04 changes tool names, descriptions, required fields, and parameter bounds to measure how a schema changes model action.

Article 05 follows one tool call through parsing, structural validation, authorization, execution, event recording, and result delivery.

Article 06 compares complete result delivery, head-and-tail truncation, structured summaries, and external references at 1 KB, 100 KB, and 1 MB.

Article 07 compares command merging, tool-level parallelism, and serial execution under success, partial failure, timeout, and cancellation.

Part III: state, permissions, and recovery

Article 08 interrupts the process before the model response, during a tool call, and after the external action but before result recording.

Article 09 models authorization as subject, action, resource, condition, and lifetime instead of a single allow-or-deny value.

Article 10 studies the crash window between an external side effect and its durable record, then tests idempotency keys and status queries.

Article 11 separates model-service, authentication, quota, protocol, validation, permission, tool, and result-delivery errors.

Part IV: long-running systems and evaluation

Article 12 separates the model’s current context, lossy session summaries, and retrieved long-term memory.

Article 13 delegates three isolated tasks and compares full-context copying with minimum task packets and reduced permissions.

Article 14 joins model, tool, permission, and state events into a replayable trace.

Article 15 evaluates result correctness, constraint compliance, process efficiency, and recoverability rather than scoring only the final answer.

The shared fixture

All experiments use the same minimum environment:

• A fixed directory containing synthetic, non-sensitive files.
• One model client.
• Two read-only tools: read_file and list_directory.
• At most five model turns.
• Explicit Token, tool-call, runtime, and parameter limits.
• Separate model, tool, permission, and state events.
• A common redaction and secret-scanning policy.

Capabilities are introduced in dependency order. Context assembly is stabilized before the tool loop is tested. The tool loop is made replayable before recovery is added. Single-Agent permission boundaries are established before delegation is introduced.

How to reproduce the experiments

Using the same CLI is not required. Capturing the same evidence layers is required: the raw model request and response, tool arguments, standard output and error, permission decisions, state transitions, and final answer. When the service reports usage, input, cached input, output, and reasoning Tokens should remain separate.

Each run starts from the same fixture snapshot. The log records client version, model, time, working directory, and permission configuration. Without these conditions, a changed result cannot be attributed to the experimental variable rather than an upgrade or an environment difference.

The series uses three forms of comparison:

Three levels of evidence

Conclusions are labeled by the evidence that supports them:

• Direct observation: a corresponding field exists in a request, response, or event.
• Controlled experiment: changing one variable repeatedly changes the outcome.
• Engineering inference: the protocol or failure trace implies a design requirement, without claiming that a product necessarily implements it internally.

A final answer proves only what text the model returned. Read-only compliance requires a filesystem snapshot or sandbox event. Parallel execution requires start and finish timestamps. An external action requires a receipt or a status query. Evidence has to come from the layer that can observe the fact.

The minimum trace

A useful minimum sequence contains task_started, model_requested, model_responded, tool_requested, permission_decided, tool_started, tool_finished, a second model_requested, and task_finished. Every event carries a trace identifier, sequence number, timestamp, type, and reference to its predecessor.

The clients do not need identical internal implementations. The shared event surface only lets later articles answer different questions from the same trace: Token growth in Article 02, concurrency in Article 07, idempotent recovery in Article 10, and regression evaluation in Article 15.