The Steve Kernel

Event bus, command pipeline, actors and the runner process, explained generically.

The Steve kernel is the runtime core. It borrows its model from operating systems: a small trusted core, registered modules for every feature and strict boundaries between them.

The command pipeline

Clients do not mutate state directly. Everything enters the kernel as a command on the command bus:

This is the syscall model: the kernel validates, routes and records, while capabilities do the domain work.

Capabilities

A capability declares:

• Commands it answers.
• Events it emits, with schemas registered in the event registry.
• Contracts on how state domains are touched.

Features that exist as capabilities today include wallet sync, trading strategy, policy, memory, the launchpad community layer and capital. A new feature ships as a new capability, without kernel changes.

The event bus

The bus is the nervous system. It runs on Redis Streams with a storage adapter, falls back to in-process delivery when the storage layer is unreachable, and guarantees:

• Fair dispatch across consumers, so no consumer starves.
• Schema evolution with versioned events, so old consumers survive new producers.
• At-least-once delivery with a dead letter queue. The runner replays dead letters through their retry wrappers, so delivery survives process restarts.

Actors and tenancy

Agent work is serialized through actor mailboxes: one mailbox per wallet, so commands for the same wallet execute in order and never race. Tenancy is enforced at this layer: each wallet is an isolated tenant with its own sessions and state.

For long running work, the scheduler grants leases. A lease guarantees at-most-one executor for a task across every process, which is what makes multi-process deployment safe.

Sagas

Multi step operations run as sagas with compensating actions. If step three of five fails, the saga engine unwinds the first two steps in reverse, leaving the system coherent. This is how execution and rebalancing flows avoid half applied states.

The runner process

The runner is the runtime's init process. It ticks the scheduler, drains the dead letter queue and exposes a health snapshot checked against invariants. It runs as a dedicated process, separate from the web server, and starts idempotently.