The Steve Runtime
A generic overview of the OS style runtime that powers every Steve agent.
This section is architecture, not product. It explains the machine that makes the product possible, in a way that stays true no matter which features ship next.
The big picture
Steve runs on a runtime designed like an operating system. There is a kernel, there are capabilities registered into it, and there are clients (the web app, the API) that speak to it through a command interface. Features are not bolted onto the agent: they are registered as capabilities with declared inputs, events and contracts.
The rule that defines the architecture: a new feature is a capability that registers itself into the kernel. The kernel is never modified to add a feature, the same way an operating system is never patched to add a driver.
In this section
- The Steve Kernel: event bus, command pipeline, actors, sagas and the runner process.
- The SAP Protocol: the Synapse Agent Protocol, the open standard for agent payments, tool access and registration that the runtime speaks.
Why the OS framing matters
When you interact with Steve, three properties follow directly from this design:
- Auditability. Commands become events with schemas. Events are replayable and the provenance ledger can always explain a decision.
- Isolation. Tenancy is per wallet. Actor mailboxes serialize each agent's work so two commands for the same wallet never race.
- Reliability. At-least-once delivery with a dead letter queue, idempotent keepers and compensating sagas mean the system converges instead of dangling.