agent-runtime

Why

The model loop is not the interesting part. The controls around it are: what a tool call is allowed to do, who approves the consequential ones, what stops a run that goes wrong, and what record is left behind. I wanted those decided outside the model, and verifiable.

What it does

The agent proposes; the runtime decides. Every tool call is validated against a schema and evaluated by policy before it executes, and the agent has no influence over that policy.

Side effects can require approval. Approvals are bound to a hash of the exact request, re-checked when a run resumes, and refused if the record was altered. Limits on steps, tool calls, tokens, cost, and elapsed time are enforced by the runtime rather than requested of the model, and the active-time limit excludes the wait for a human.

Runs, steps, and an append-only event log live in SQLite. A run can be interrupted, inspected, and resumed, and an interrupted step is reconciled rather than re-executed, so side effects don’t happen twice.

How it’s verified

Model calls can be recorded and replayed byte for byte, so the whole loop runs deterministically against a scripted agent with no network. The status document lists each control with the named test that exercises it, and repo-steward supplies the requirements: abstractions get added when its first consumer demonstrates the need, not before.

What it isn’t

It isn’t a model SDK, and it isn’t stable yet. The API is pre-1.0 and changes when its consumer needs it to.

The code

agent-runtime is public under MIT, with its architecture and control status documented alongside it.