Workflow Server

Workflow fidelity

Agents drift: context degrades over long sessions, and without enforcement a model may skip steps, dodge checkpoints, or fabricate state. The server counters this with seven enforcement layers — some hard gates that block, some advisory checks that warn — each operating at a different granularity.

Canonical source: docs/workflow-fidelity.md.

The seven enforcement layers A stack of seven layers. Layer one, cryptographic integrity, applies to every call and is a hard gate. Layer two, the checkpoint gate, blocks transitions and is a hard gate. Layers three to six — cross-activity validation, transition condition tracking, the step completion manifest, and the activity manifest — are advisory checks that produce warnings. Layer seven, the execution trace, records the entire session. L1 · Cryptographic integrity (HMAC) session seal, checkpoint handles, trace tokens — fabrication and tampering rejected L2 · Checkpoint gate active checkpoint blocks transition tools until resolved; response timing enforced L3 · Cross-activity validation workflow consistency, valid transitions, declared techniques, version drift L4 · Transition condition tracking claimed condition must map to the target activity in the transition table L5 · Step completion manifest per-step summary checked for presence, order, and non-empty outputs L6 · Activity manifest workflow-journey summary checked against definition and conditions L7 · Execution trace every tool call recorded; signed trace tokens resolvable via get_trace every call · hard transitions · hard between activities · warns at transitions · warns within activities · warns across activities · warns whole session · records
The seven enforcement layers, from per-call cryptographic integrity to a whole-session audit trail. Solid borders mark hard gates that block execution ("hard"); dashed borders mark advisory checks that return warnings without blocking ("warns").

The hard gates

Integrity (L1). Everything the server hands out or persists is HMAC-signed with a server-held key: the .session-token seal on session state, one-shot checkpoint handles, and trace tokens. An agent cannot fabricate or tamper with any of them — a mismatch between session.json and its seal is a hard error on read.

Checkpoint gate (L2). While a checkpoint is active, transition tools hard-fail; only present_checkpoint and respond_checkpoint are exempt. Responses are validated against the checkpoint definition, and timing is enforced — a minimum response delay for user-answered checkpoints, the full autoAdvanceMs timer for auto-advanced ones — so an agent cannot instantly answer its own question. Details in the checkpoint model.

The advisory layers

Layers 3–6 warn rather than block. Only checks that are cheap and certain hard-stop execution; manifest completeness, version drift, and fetch coverage surface warnings in _meta.validation and the trace because the server can verify observable consistency, not that work was done well. See Protocol for how to read them.

LayerWhen it runsEffectWhat to do
L3 Cross-activitySession navigationWarnsFix workflow switches, transitions, or stale definitions
L4 Transition conditionnext_activityWarnsMatch claimed condition to a real transition
L5 Step manifestnext_activityWarnsReport completed steps with valid ids and outputs
L6 Activity manifestnext_activityWarnsSummarize completed activities with real outcomes

The trace (L7)

The server mechanically records every tool call — name, timing, status, workflow/activity/agent attribution, errors, and any validation warnings. At each activity transition the events are packaged into a compact, HMAC-signed trace token returned in _meta.trace_token; the agent accumulates these opaque strings and can resolve them at any time with get_trace. Agents additionally write a semantic trace (step outputs, decisions, variable changes) to the planning folder; together the two give complete post-hoc visibility.

Context-pressure mitigation

Enforcement is half the story; the server also keeps agents' context windows small so instructions stay in effective attention: lightweight get_workflow metadata instead of full definitions, transitions delivered with each activity, pre-resolved technique bundles, lazy resources, a self-describing bootstrap, and compressed trace tokens (see resolution).

Honest limitations

The enforcement is detection-oriented, not proof-oriented. The server verifies that steps were reported, not that the work was done; that a claimed condition maps to the target, not that it is true; that a checkpoint was answered after a plausible delay, not that a human saw it. The mechanical trace corroborates what tool calls actually happened, and post-hoc audit can cross-reference claims against checkpoint logs — the full list of limitations is in the canonical document.