Skip to main content

Supervised tool loop

Separate proposal, policy, approval, execution, and verification.

Supervised tool loop

Activity responsibilities

ActivityResponsibility
build-contextExecute the build context stage and publish its declared outputs for downstream activities.
propose-actionExecute the propose action stage and publish its declared outputs for downstream activities.
policy-checkExecute the policy check stage and publish its declared outputs for downstream activities.
human-approvalExecute the human approval stage and publish its declared outputs for downstream activities.
execute-toolExecute the execute tool stage and publish its declared outputs for downstream activities.
verify-resultExecute 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.

Supervised tool loop workflow execution evidence
Workflow evidence
Supervised tool loop execution evidence
Execution evidence
Supervised tool loop output evidence
Output evidence
Open verified output manifest ↓

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.