a retry needs a name

part of the agent runtime lab.

when you ask for something twice, you might want two things.

or you might want one thing, and be unsure whether the first request arrived.

the server needs a way to tell those intentions apart.

i added a small HTTP API to my personal agent runtime. a client can create a session, submit a turn, and inspect the saved events. PostgreSQL keeps the record while the API process does the work.

each submission carries an Idempotency-Key: a name the client chooses for one intended turn.

the server saves turn.started before returning 202 Accepted. the response includes the turn's identity. completion comes later, as another event.

if the reply disappears, the client can submit the same effective input and history setting with the same key. the server finds the original turn and returns it. this works while the turn is running and after it has completed.

the key belongs to the session, so a replacement API process can find it too.

in the browser demo, i reloaded the client and retried its last submission. the API returned 200 with the original turn. the session still had 21 events. another execution had not been added.

the response text came from a deterministic offline fixture. the HTTP requests and PostgreSQL persistence were real. this test was about the runtime's handling of submissions; it made no hosted model calls.

reusing the key also creates a useful disagreement. change the input or the effective history setting, keep the same key, and the API returns 409 Conflict. the client has given one name to two different requests.

using a new key is an explicit new submission, even if the words are identical.

there is a boundary to this promise. the key identifies admitted work. it does not establish that every external action performed by a tool happened exactly once. a tool could change something and then lose its connection before the runtime records the result.

that uncertainty needs its own handling. this prototype refuses to replay unfinished work automatically.

the next experiment should put a synthetic write on each side of an interruption. i want to inspect what the saved record can establish before deciding whether to repeat an action.

the client can ask again. the runtime should first know which question it is answering.

inspect the saved retry observation