← Romulus overview
Architecture
Execution that survives a restart.
A workflow resumes from its execution record. Workers handle attempts, and the record holds the state the next attempt needs.
What each part owns.
- Execution record
- Keep the run ID, workflow version, completed step outputs and next execution position together. Commit the result and the transition as one state update so a worker never resumes from a partially recorded step.
- Worker ownership
- Give each attempt a time-limited claim on its step. When an attempt loses ownership, reject its late updates so the replacement worker is the only one that can advance the run.
- Persistent waits
- Record the expected event, correlation ID and optional deadline. Store arriving events before matching them so a fast callback can still wake a workflow that has just started waiting.
- External operations
- Record an operation ID before sending a write. On an ambiguous timeout, ask the provider for the outcome or reuse the same idempotency key if the provider supports it. Hold for review if neither path is available.
Follow a run through recovery.
- Before the write. Save the CRM update intent with an operation ID and the previous completed step.
- After a timeout. Record that the outcome is unknown. A request may have applied before the response was lost.
- During recovery. Look up the recorded operation. If the provider confirms success, save the returned result and advance the run.
Authorise tool actions with Remus.
Remus, also by New Odyssey, covers scoped tool permissions, human approvals and decision records. Pair those capabilities with Romulus when a recoverable workflow needs to read or change protected resources.
For a refund workflow, persist the proposed action and wait for a correlated approval event. On resumption, have the trusted executor recheck the request, approval expiry and current policy through the authorisation boundary. A saved checkpoint records progress; it does not grant permission to execute a tool.