Why Praetor

Agents are running real work. The tooling is not built for it.

The first generation of agent interfaces are chat windows with extra buttons. They host one conversation at a time, treat the model's output as the unit of work, and assume a human is in front of the screen. That shape is fine for trying things and for demos. It is not the shape that survives an agent running for hours or days against a real codebase.

Once agents are doing actual engineering (opening pull requests, iterating on failing tests, coordinating with other agents) the abstractions a chat client gives you are wrong at every level. There is no notion of a session as a first-class thing. There is no scheduler. There is no recoverable phase model when a turn fails halfway. There is no audit trail that distinguishes the model's intent from the host's execution. There is no way for an agent to do meaningful work without also holding the credentials.

The pattern is familiar. Every new computing primitive starts as a script in a single user's terminal, and only later acquires the surrounding machinery (supervision, scheduling, transactions, isolation) that makes it suitable for shared, durable systems. Agent runtimes are at the script-in-a-terminal stage.

The hard work lives below the screen.

Praetor is a runtime, not a user interface. The interface (terminal, web, API) sits above it. The runtime is the long-running process that hosts agents, dispatches their work, supervises their sessions, and persists their state through restart.

Splitting these layers matters because the interesting properties are runtime properties. Whether a turn is interruptible mid-stream. Whether a failed reload can leave the world half-changed. Whether two sessions can race on the same task. Whether shutdown waits for in-flight work or signals it. None of these are interface decisions, and treating them as such is exactly how production agent systems become brittle.

The interesting question isn't whether an agent can do the work. It's whether it can do the work without holding the keys.

The hard part is what you don't let the agent do.

Most of the discourse around autonomous agents is about capability: what can the model figure out, plan, accomplish on its own. The harder question, and the one we built Praetor around, is the opposite. What can the agent be safely denied while still letting it do real work?

An agent doesn't need to hold your Git credentials to author a change. It doesn't need to run as you to read your files. It doesn't need permission to push in order to demonstrate that a fix works. Praetor formalizes this split as a first-class architectural concern: a trusted reviewer that owns the authority to commit and merge, and an untrusted executor that does the actual editing and verification work inside a sandbox.

The reviewer imports executor output selectively, runs its own verification, and commits. The executor never sees credentials, never touches remotes, never modifies hooks or trust configuration. Autonomy is bounded by what the executor is allowed to do, and that boundary is enforced by the runtime, not by polite request.

The system you want is the system you write.

Every serious tool eventually grows a configuration surface. The choices are well-trodden: a settings panel, a YAML file, a DSL, or actual code. Praetor commits to code from the start. Hooks, prompt builders, tool definitions, workflow logic. All of it is written in the host scripting environment, with full access to the runtime's primitives.

This is a load-bearing decision. Engineers know how to compose code. They do not want to compose dropdowns. And the moment your configuration surface becomes interesting enough to be useful, it becomes interesting enough that nothing short of a real language will do.

Foundations get built once. They should be built well.

Praetor is written in Rust because if agent infrastructure becomes a real category, and it is becoming one, it cannot be a thin Python wrapper around a single conversation. It needs the same care, the same restartability, the same observable failure modes that we expect from a database or a job scheduler. Rust gives us the discipline to enforce those properties; the type system carries the invariants that matter.

We are building it in the open because the hardest problems here are shared problems, and the answer to them should not be locked inside any one vendor's product. Other runtimes will exist. They should agree on the shape of an agent, the shape of a session, the shape of a task graph, the same way the database world eventually agreed on what a transaction is.

That is what Praetor is for. A foundation for the next decade of agent work, where the interesting questions are about the work the agents do, not the brittle plumbing underneath.

Foundations get built once. They should be built well.