why i'm building an agent runtime

when i send another message to an agent, what exactly am i continuing?

there is the conversation i can see, the record the application saved, the request it will send to the model, and any work still running. those are related, but they have different lifetimes.

i want to understand how a runtime keeps those pieces consistent.

that's why i'm building a small personal agent runtime and writing through the experiments. my aim is to understand the behavior well enough to explain it, change it, and see where it breaks. the project gives me something concrete to inspect: a request, an event, a tool result, a process that stops.

one question i care about is what really gets reused between turns. that leads to questions about caching, latency, and cost. before measuring any of those, i need to know exactly what the runtime sent and which parts of the earlier conversation it selected.

the first four notes work through that foundation:

1. what the model can see starts with a saved conversation. if every turn is still in the record, which parts appear in the next model request? what happens when an earlier turn is left out?
2. what survives a restart stops the API process. what can its replacement reconstruct? what can a saved record establish about work that never recorded a result?
3. a tool needs a room adds a bounded JavaScript tool to the runtime. where does that program run, which files can it read, and which credentials can it reach?
4. a retry needs a name submits the same request again. how does the API recognize one intended turn? what uncertainty remains if a tool acts before its result is saved?

these are local experiments using synthetic data. the current demos use a deterministic provider fixture, so they make no hosted model calls. the HTTP requests, process restarts, PostgreSQL persistence, and JavaScript execution in gVisor are real. that lets me inspect the runtime's behavior while keeping the provider's response predictable.

i also want to measure cache reuse between turns, the cost of a session, and the time spent waiting for the first token. how much of an unchanged prefix does a provider actually reuse? what happens after an idle gap? what would keeping that prefix warm cost? those questions need real provider calls and separate measurements. this first set of posts does not answer them yet.

i'm writing because i want the questions and the evidence to be available together. each note should leave something another engineer can inspect: the request that was sent, the events that were saved, the boundary that was tested, and the part that remains uncertain.

if someone disagrees with an explanation, the example should be small enough for us to inspect the same thing.