Step Runner
The Step Runner is the heart of the platform — responsible for claiming tasks, executing workflow steps sequentially or in parallel, managing context, persisting results, and handling retries with distributed locking.
How the Runner Fits In
Database
Stores workflows, tasks, step definitions, logs, and schedules.
Scheduler
Creates tasks automatically based on cron or time-based triggers.
Step Runner
Claims tasks and executes steps in strict order or in parallel.
Executor
Dispatches each step to the correct tool implementation.
Lifecycle of a Task
Polling
Runner polls for PENDING tasks that are ready to execute.
Claiming
Task is atomically marked RUNNING to prevent double execution.
Context Init
Initial execution context is created for the task.
Step Execution
Each step runs sequentially or in parallel using the shared context.
Persistence
Step results and logs are written to the database.
Completion
Task is marked COMPLETED, FAILED, or PENDING_APPROVAL.
Supported Step Types
LLM Step
Run prompts with context injection and memory support.
HTTP Step
Call external APIs with dynamic payloads.
File Step
Read and write files inside the sandboxed runtime.
Email Step
Send templated emails using workflow data.
Delay Step
Pause execution for a specified duration.
Browser Step
Take screenshots, evaluate scripts, extract content.
Document Query Step
Query documents using RAG retrieval.
Condition Step
Branch execution based on boolean expressions.
Switch Step
Route to multiple cases based on a value.
Parallel / Join Step
Execute branches concurrently and synchronize.
Approval Step
Pause for human approval before proceeding.
Agent Call Step
Delegate execution to a specialized agent.
MCP Step
Call tools exposed by MCP servers.
Execution Context & Memory
Every task maintains a mutable execution context that is passed between steps.
{{last}}references the previous step output- Named variables can be injected into prompts and payloads
- Agent memory can persist facts across multiple tasks
- Trace IDs are attached to every log for end-to-end debugging
Error Handling & Reliability
Failures
Errors are captured per step with stack traces and timestamps.
Retries
Steps can retry with exponential backoff before marking the task as failed.
Distributed Locks & Parallel Safety
Parallel and join nodes use MongoDB-backed distributed locks and semaphores. This ensures that even when multiple workers are running, branches do not race or corrupt shared state.
- Lock manager enforces concurrency limits per worker.
- Join nodes wait for all branches to release their locks.
- Fail-fast strategy aborts remaining branches on first failure.