Supervised tool loop

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

build context→propose action→policy check→human approval→execute tool→verify result

Supervised tool loop

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

Source bundle

The executable workflow and its implementation files are maintained in the separate AkôFlow examples repository. The documentation intentionally keeps code, container recipes, generators, and validation scripts out of the narrative page.

Open the complete source bundle ↗

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.

Workflow evidence

Execution evidence

Output evidence

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.