Supervised tool loop
Separate proposal, policy, approval, execution, and verification.
build contextpropose actionpolicy checkhuman approvalexecute toolverify result
Activity responsibilities
| Activity | Responsibility |
|---|---|
build-context | Execute the build context stage and publish its declared outputs for downstream activities. |
propose-action | Execute the propose action stage and publish its declared outputs for downstream activities. |
policy-check | Execute the policy check stage and publish its declared outputs for downstream activities. |
human-approval | Execute the human approval stage and publish its declared outputs for downstream activities. |
execute-tool | Execute the execute tool stage and publish its declared outputs for downstream activities. |
verify-result | Execute the verify result stage and publish its declared outputs for downstream activities. |
Inputs
- Goal and state
- Policies
- Tool credentials
Outputs
- Verified change
- Decision record
- Execution evidence
Provenance to preserve
- Proposal revisions
- Approver
- Idempotency key
Runnable example
This is the complete checked-in bundle for this pattern. Download the environment, scope, topology, workflow, input, container recipe, runner, and validation contract from this page before executing it.
Verified local execution
These captures and the output manifest were produced by the fixture's local Docker run and validator. They are published with the same bundle as the runnable files.



Execution considerations
This pattern requires durable pause and resume. A daemon restart must not execute an approved action twice.
AkôFlow boundary: the engine schedules, deploys, executes, transfers data, and records evidence. The ML or agent framework remains an implementation choice inside each activity.