engine-rs - Bastion's Native Execution Engine
Rust execution engine that runs agent workflows as validated graphs, holds live run state in memory, and writes a durable record to Postgres.
Overview
engine-rs is the layer that actually runs things. It takes an agent workflow expressed as a directed graph, validates the graph before executing a single node — cycles, unreachable nodes, and unsatisfied inputs are rejected up front rather than discovered halfway through a run — and then executes it, threading a typed context between nodes. It is embedded rather than standalone: it compiles into `bastion serve`, so the Console starts a run in-process instead of shipping work to a separate service. Live run state is held in memory for speed, while the durable record is written to Postgres against a versioned data contract shared with the rest of the stack. That split is deliberate — the in-memory copy answers 'what is happening right now' at interactive latency, and Postgres answers 'what happened' after the process is gone. The engine drives the SDLC pipeline the whole practice runs on: a served `SDLC_FLOW` run has executed end to end and produced a live model review verdict over a real code diff. Using the engine to build the engine is the most honest integration test available, and it is why the failure modes that matter get found early. The test suite is hermetic — no network, no database, no model calls — and completes in about two seconds, which is what makes it usable as a pre-commit gate rather than something you run before lunch.
Technical Stack
Core
- ▸Rust
- ▸Tokio
- ▸serde
- ▸Graph validation
Persistence
- ▸PostgreSQL
- ▸Versioned data contract
- ▸Durable run records
Integration
- ▸Embedded in `bastion serve`
- ▸Node transport
- ▸Structured LLM review nodes
Testing
- ▸cargo nextest
- ▸Hermetic suite — no network, no DB, no model calls
Key Features
Validates the workflow graph before execution — cycles, unreachable nodes, and unsatisfied inputs are rejected up front
Embeds directly into `bastion serve`, so runs start in-process rather than crossing a service boundary
Holds live run state in memory for interactive latency, and writes the durable record to Postgres
Typed context threaded between nodes, so inter-node state is explicit rather than ambient
Writes against a versioned data contract shared across the stack, so consumers break loudly rather than silently
Drives the SDLC pipeline the practice itself runs on — the engine builds the engine
Hermetic test suite completes in about two seconds, fast enough to gate a commit
Technical Challenges
Deciding what belongs in memory versus Postgres — the in-memory copy answers 'what is happening', the durable record answers 'what happened'
Validating a graph strictly enough to catch real errors without rejecting legitimate branching and merging topologies
Keeping the test suite hermetic while the engine's whole purpose is calling out to models and databases
Evolving the shared data contract without breaking the Console and the Brain that read it