Agentic workflows fail in ways orchestration frameworks were never designed to stop. The frameworks answer how a multi-step run executes reliably; they do not answer whether a tool call should have been made, whether an output was structurally valid before it committed, or what happens to already-committed side effects when step three fails. Those questions are decided at runtime, or not at all.
The four failure classes
| Failure class | What it looks like | Why execution mechanics does not stop it |
|---|---|---|
| Hallucinated tool calls | An agent invents a tool, or calls a real tool with invented parameters | Durable execution faithfully runs the invalid call it was given |
| Unvalidated outputs | A malformed or fabricated structured result commits as workflow state | State graphs persist whatever a node returns |
| Partial commits | Step 3 fails after steps 1–2 already wrote to external systems | Retry re-attempts; it cannot undo a write that landed |
| Unauditable state | No reconstruction of what the run did, in what order, on what evidence | Logs are assembled after the fact, by convention |
The guarantee stack
Each failure class is answered by a guarantee with a mechanism — a specific engine phase that enforces it and a specific Evidence Ledger event that records it. This is the whole of the answer; the rest of the reference is detail.
| Failure class | Guarantee | Enforcing phase | Ledger evidence |
|---|---|---|---|
| Hallucinated tool calls | No call leaves the plane without passing tool-input validation | Schema gate, before execution | Validation failure recorded; no tool_call event exists |
| Unvalidated outputs | Nothing becomes workflow state until verification passes | Verifier, before commit | verification event with verdict and critique |
| Partial commits | Committed side effects roll back in reverse order | Compensation | compensation events, reverse order, per step |
| Unauditable state | Every decision lands in an append-only, checksum-chained trail as it happens | All phases | The full event trail |
Governance in the runtime
The difference between a governance layer and a governance convention is where the check lives. Bolted on, checks are advisory and skippable. In the runtime, they are on the only path to execution.
| Bolted on | In the runtime |
|---|---|
| Advisory checks a developer may skip | The engine cannot reach a tool without passing the Policy Gateway |
| Logs assembled after the fact | Events land in the Evidence Ledger as they happen |
| Rollback is a runbook | Saga compensations are engine behavior, declared per step |
| Enforcement varies by team | Guarantees are properties of every run of the SOP |
The category
Orchestration frameworks — Temporal, LangGraph, CrewAI, AutoGen — solve execution mechanics: durable runs, state graphs, agent coordination. None of them claims to stop a hallucinated tool call, verify a structured output against declared criteria, or reverse committed side effects. That is not their defect; it is a different layer. Escepine is that layer as a standalone execution plane: the SOP runs on it, and the guarantees above are properties of the run.
NOTE — The sentence above is the only place in this reference that names specific frameworks. Their role here is definitional: they mark the boundary of the execution-mechanics category. The engine's runtime composition is documented once, in implementation notes.
When not to use Escepine
| Do not use when | Why |
|---|---|
| The workflow is a linear script with no external side effects | A shell script is cheaper; there is nothing to govern |
| Every step is HUMAN | No execution to police — the plane adds gates, not value |
| Self-serve SDK integration is the requirement today | Delivery is white-glove; there is no self-serve tier |
| The path is a single latency-critical call | The pipeline exists to make failure safe, not raw throughput fast |