Agents that ask first.
How we think about running AI agents: asking a human before the risky move, finishing after a crash, and proving what a run did and cost.
- 01
Your agent will die halfway. Restarting it is the easy part.
An AI agent is a long job that holds state and spends money. Two things break it: dying mid-run, and coming back on a different machine than the one holding its context. We built the runtime for that, and proved it on something less forgiving first - our own deploy pipeline.
- 02
Your agent will do something expensive. Where does it have to ask?
Every agent that can act can act badly. Most stacks answer that with an alert, which arrives after the money is gone. This is the difference between alerting and enforcement, why only the thing running the agent can stop it, and the three places to draw the line.
- 03
Checkpointing is not completion
Saving your agent's state is the easy half. The hard half is noticing it died, resuming it exactly once, and not re-running the side effects that already happened. Most frameworks ship the first and hand you the other three.
- 04
Evals belong in the runtime, not the dashboard
Your eval suite runs on a sample, offline, against inputs you chose. Production runs on everything, once, against inputs you didn't. Scoring where the run already lives closes that gap - and makes 'is the new prompt better' a question with an answer.
- 05
Durable agents in TypeScript, Python, and Go - one runtime
Your models are called from Python, your API is TypeScript, and the thing that has to not fall over is Go. Most durable-execution stacks make you pick one. Here is what it looks like when the run is the shared object and the language is just where a step happens to execute.