-
Notifications
You must be signed in to change notification settings - Fork 4
CHAP vs workflow engines
Workflow engines execute and recover processes. CHAP records the accountable collaboration that happens inside and across those processes.
CHAP is not a replacement for Temporal, Apache Airflow, Argo Workflows or another orchestration system.
Temporal provides durable workflow execution that can resume after failures. Airflow develops, schedules and monitors workflows, including batch and agentic workloads. Argo Workflows orchestrates container-based jobs on Kubernetes. These systems decide what code runs, when it runs, how dependencies progress and how execution recovers.
CHAP standardises the messages and evidence around human-agent work: task assignment, artefacts, review, approval, rejection, override, abstention, escalation and handoff. A workflow engine can carry or trigger CHAP methods without giving up control of execution.
| Question | Workflow engine | CHAP |
|---|---|---|
| Primary job | Schedule, execute, retry and recover work | Coordinate and evidence accountable participants and decisions |
| Main unit | Workflow, DAG, activity, step or task | Workspace, task, artefact and envelope |
| Control flow | Core concern | Out of scope |
| Timers and retries | Core concern | Transport and application responsibility |
| Human review | Engine or application-specific pattern | Standard review and decision semantics |
| Human modification | Often state or payload update | Structured override with diff, rationale, tags and intent |
| Operational history | Execution events and logs | Signed, hash-linked collaboration evidence |
| Cross-engine portability | Usually requires integration | Shared protocol vocabulary across runtimes |
A durable workflow history may show that an approval activity was scheduled, a signal arrived and the next activity ran. That is excellent evidence about execution and recovery.
It may not express the complete human judgement:
- The exact agent artefact presented for review.
- Whether the reviewer accepted or modified it.
- The field-level change and declared rationale.
- The reviewer's role and authority in the collaboration.
- An abstention or escalation as a first-class outcome.
- A portable evidence format another workflow engine can interpret.
An application can add all of this to its workflow history. CHAP provides a standard way to do so without making the workflow engine itself the cross-system protocol.
A workflow can call the CHAP Coordinator at consequential boundaries:
- Create a CHAP task when the workflow starts accountable work.
- Complete the task with the agent's proposed artefact.
- Send
review.requestbefore the workflow waits for a person. - Record the human response as approve, reject or override.
- Continue the workflow with the accepted artefact.
- Cite the resulting external action or record its execution separately.
Use idempotency keys because workflow activities may retry. A retry must not create a second approval for the same human action.
Keep the CHAP task or evidence identifier in workflow state. The engine retains operational state and recovery information, while CHAP retains the accountable decision record.
This avoids copying the full evidence chain into every workflow event. It also allows audit tools to verify decisions across multiple workflow technologies.
Two organisations may use different runtimes. One uses Temporal, another uses Airflow, and a specialist service runs Argo Workflows. CHAP can provide a common participant and decision vocabulary at the collaboration boundary while each engine continues executing its local process.
A2A may carry agent-to-agent delegation between organisations, and MCP may carry tool calls within a step. CHAP links the accountable human-agent decisions across them.
A workflow builds an application, runs tests and prepares a deployment plan. An agent summarises risk and recommends production release.
The engine pauses before deployment. CHAP records the plan as an artefact and sends review.request to the release manager. The manager removes one high-risk migration step, explains that a dependency is not ready and approves the revised plan. CHAP records an override. The workflow resumes with the accepted plan and runs the deployment activities.
If an activity later fails, the workflow engine owns retry and compensation. The CHAP record still shows what the manager approved. A separate execution event should show whether the approved plan was actually carried out.
CHAP is not designed to replay arbitrary application code, schedule containers or maintain every local variable. Keep execution state in the engine.
A signal named approved may be enough inside one codebase. At an organisational boundary, record the referenced artefact, participant, authority and decision type explicitly.
The CHAP evidence chain should contain accountability-relevant messages, not a second copy of scheduler heartbeats and low-level task logs.
Define what happens when the CHAP decision succeeds but workflow resume fails, or the workflow acts but the evidence write fails. Reconciliation must preserve one authoritative decision.
Use the engine's own history when the process stays inside one runtime, the decision model is simple and no independent consumer needs portable semantics.
Add CHAP when several frameworks or organisations share the process, modified agent outputs need a standard representation, or decision evidence must be interpretable and verifiable outside the engine.
- CHAP with LangGraph human-in-the-loop
- CHAP vs application-specific approval logs
- MCP, A2A and CHAP: how the open agent stack fits together
- Temporal Workflow Execution overview
- Apache Airflow documentation
- Argo Workflows documentation
- CHAP specification
- CHAP relationship to other standards
If CHAP needs an adapter for your workflow engine, star the repository and open a focused integration issue with the review boundary you need to represent.
Last reviewed: 25 August 2026.