Workflow Orchestration. Without the stack.
Purple8's Journey Engine is a production-grade workflow orchestration layer built directly into the graph database. Define stages, SLA policies, and human-approval gates in plain language via MCP tools. Every state transition becomes an immutable graph edge. The scheduler, the audit trail, and the workflow state all live in the same store as your data.
How it stores state
The graph IS the state machine
Every workflow concept maps to a graph primitive. There is no separate workflow database — the same store that holds your knowledge graph holds your process state, and both are queryable together.
JourneyDefinitionThe workflow template — stages, SLA policies, HITL config
JourneyInstanceOne running workflow — current stage, start time, entity reference
ADVANCED_TOEach stage transition — who/what triggered it, when
SLA_BREACHEDWritten on breach — stage, deadline, time over — never deleted
HITL_RESOLVEDHuman decision — approver identity, outcome, timestamp
journey.* namespace
9 MCP tools. Agents run the whole pipeline.
An AI agent can define a workflow, start instances, advance stages, handle SLA breaches, surface HITL decisions, and retrieve the full audit trail — entirely through natural language tool calls.
journey.defineDefine a workflow with stages, SLA policies, and HITL requirements
journey.listList all workflow definitions in the system
journey.startStart a new workflow instance for an entity
journey.advanceAdvance an instance to the next stage
journey.statusGet current stage, SLA status, and history for an instance
journey.sla_alertsList all instances with active SLA breaches or at-risk stages
journey.list_hitlList all workflow instances pending a human decision
journey.resolve_hitlRecord a human approval or rejection decision
journey.auditReturn the full, tamper-evident history of any instance as graph edges
Why not Airflow, Temporal, or LangGraph?
One less service to run. One less bill to pay.
- •DAG files in Python — developers must code every flow
- •Scheduler is a separate process to operate
- •No graph memory — context is flat key-value
- •HITL requires custom sensors or external triggers
- •Audit trail in separate logs; not queryable
- •Separate server cluster to deploy and operate
- •Workflow code in dedicated Worker processes
- •No native knowledge graph or vector search
- •HITL via signals — requires custom handling
- •High operational complexity for small teams
- •In-memory state machine — no durable persistence by default
- •No SLA enforcement or breach detection
- •No HITL gate primitive
- •Audit requires LangSmith (separate service, cost)
- •Graph is code, not data — hard to query or observe
- •No DAGs, no YAML — define in plain language via MCP
- •In-process — zero extra services to operate
- •Full knowledge graph memory on every workflow instance
- •HITL gates are first-class primitives
- •Audit trail IS the graph — always on, always queryable
Use cases
Workflows teams are running today
Loan origination
Multi-stage underwriting with automated risk scoring, compliance checks, and mandatory human review before approval — full audit trail for regulators.
Invoice processing
DocIntel extracts line items, Journey Engine routes to approvers based on spend thresholds, CDC triggers downstream payment on approval.
Construction permit workflow
BIM model ingested via DocIntel, structural and MEP checks run automatically, human sign-off required per discipline, timeline SLAs enforced per stage.
Security incident response
SOC detector fires → containment workflow starts → analyst reviews and approves response → every action timestamped as an immutable graph edge.
Supplier onboarding
Document collection, KYC verification, risk scoring, commercial term review, contract signing — each stage gated, SLA-tracked, fully auditable.
Compliance review
Triggered by regulatory change, assigns review tasks across legal and operations, tracks completion, escalates breaches, produces audit evidence automatically.
FAQ
Common questions
How does workflow orchestration work in Purple8?
Purple8's Journey Engine is the workflow orchestration layer. You define a workflow as a set of stages with SLA policies and optional human-approval gates. Each workflow instance is stored as a graph node; every state transition becomes an immutable graph edge. AI agents or application code advance instances through stages by calling journey.* MCP tools — no DAG files, no YAML config, no separate scheduler process.
What does Purple8 replace in a typical workflow stack?
Purple8 replaces Airflow, Temporal, LangGraph, LangChain, LangSmith, and a separate audit/tracing service — all at once, in a single process. The graph IS the workflow state machine, the audit trail, and the observability layer simultaneously.
Can workflows trigger on data changes (CDC)?
Yes. Purple8 has a built-in Change Data Capture event bus. When a node or edge is created or updated in the graph, subscribers receive the event and can start or advance workflow instances automatically — without polling.
How are SLA breaches handled?
Each stage in a Journey definition can have a SLAPolicy specifying a deadline and escalation action. The SLAMonitor background thread checks running instances continuously. When a breach occurs, a SLA_BREACHED edge is written to the graph — immutably — and the escalation action fires. journey.sla_alerts surfaces all active breaches to agents or dashboards.
Can human approvals be required at specific workflow stages?
Yes — HITL (Human-In-The-Loop) gates are first-class in Journey Engine. A stage marked as requiring approval pauses the instance until journey.resolve_hitl is called by an authorised user. The approver's identity, decision, and timestamp are written as immutable graph edges. journey.list_hitl surfaces all pending decisions.
Replace Airflow in an afternoon
Free to start. Journey Engine is part of the base product. Point it at your first process and go.