iv — the forge
Automation shouldn't feel fragile.
The reliability is forged in the runtime. We engineer the orchestration layer the way Hephaestus forged armor for the gods - like an operating system, not a chatbot - so agents keep working when models misbehave and upstreams slow down.
- i
Every task carries a policy - timeout, retry, budget, idempotency - and runs in a container drawn from a warm pool, so cold starts never show.
- ii
There are no checkpoints to fall out of sync. Executor state is a fold of the run's event log, so a killed executor rebuilds every run and finishes it.
- iii
Structured outputs are schema-validated at every boundary; malformed responses are repaired or fail typed before they touch your data.
- iv
Large data never travels inline. Files and tables move as handles, so a run costs the same whether it reasons over a hundred rows or fifty thousand.
- v
No agent framework is baked into the executor. The harness lives inside the runner image, and swapping it touches zero engine code.
The agents spend their time working, not failing quietly.
Model output is untrusted input.
The runtime treats what comes back from a model the way a kernel treats userspace: never as something to be believed, always as something to be checked at the boundary.
- Task bodies speak JSON-RPC over stdio from a warm container pool, and reach resources only through a Unix socket minted for that run.
- Events are appended before execution; recovery folds the log rather than re-running the model.
- When an agent's output fails its schema, a truncated error diff goes back to the model - two attempts, then a typed failure into the run log.
- Every value carries an envelope: producer, causing event, taint, and budget spent. Taint is recorded today, not yet enforced.
when it does not go smoothly
Anything works on a good day. Here are the bad ones.
the model invents something
It does not get through.
Every result has a declared shape, and one that does not match is not passed along. The error goes back to the model to correct, twice at most, and then the run fails plainly and says which step failed and why.
report.spec@1 · repair 2 of 2 exhausted · typed failure written
model output is untrusted input→the machine dies halfway
The run picks itself back up.
Nothing is held in the engine's head. Every event is appended to one log, and the state of a run is read back out of it, so a run interrupted in the middle carries on from where it stopped rather than starting over or quietly vanishing.
executor restarted · run resumed from seq 41 · completed
the log it recovers from→a person has to sign off
It waits, for as long as it takes.
A step can be gated on a human approval. The run suspends — through restarts, overnight, over a weekend — until somebody approves or denies it, and both answers become part of the same record as everything else.
awaiting approval · 2 approvers · run suspended durably
the record it keeps→