Discover the current environment
- Call
orient {}and verify the intended principal and Mind. - Call
list_skills {}, thenget_skill {"name":"loop-composer"}if offered. - Call
list_actions {}and use only its current action IDs, argument shapes, effects and dry-run support. - Call
list_loops {}; inspect a possible existing loop withget_loopbefore creating a duplicate.
A missing operate_loops grant is a stop. Do not substitute a raw file write or automation to bypass it.
Exact lifecycle example
The following input to loop_compose is a fictional checklist. Its constant comparison checks the workflow mechanism only; it does not assess real work, call a model, use a donated action or demonstrate a business result. It schedules a human confirmation every five minutes once separately approved and activated. Use it only for an explicitly authorised disposable test, then retire it.
{
"name": "Fictional checklist practice",
"description": "Disposable lifecycle example with no external action.",
"spec": {
"purpose": "Ask the owner to confirm a fictional checklist.",
"version": 1,
"supersedes": null,
"trigger": {"every": "5m"},
"inputs": [],
"nodes": [
{"node": "deterministic_check", "check": "equals",
"subject": "fixture-ready", "expected": "fixture-ready",
"on_fail": {"escalate": "Fixture not ready"}},
{"node": "wait_human",
"question": "Confirm this fictional checklist was reviewed.",
"audience": "owner", "timeout": "1h",
"on_timeout": {"escalate": "Checklist not confirmed"}},
{"node": "complete_escalate", "outcome": "complete",
"reason": "Fictional checklist confirmed", "escalate_to": "owner"}
],
"quality": {"rubrics": [], "sample_rate": 1, "min_pass_rate": 1},
"escalation": {"to": "owner", "channel": "queue", "max_open": 1,
"on_budget_exhausted": "fail"},
"autonomy": {"effect_ceiling": "read_only", "auto_run_max": "read_only"},
"budget": {"max_nodes_per_case": 5, "max_wall_clock": "2h",
"max_spend_usd": 0, "max_open_cases": 1}
}
}
Omit owner and rollout; the gateway supplies the caller and shadow mode. On a passing response retain loop_id, status, version and summary. Inspect the stored object using get_loop {"loop_id":"<returned id>"}.
Rehearsal, review and activation
For a real job, use only discovered actions. Rehearse an invoke_action with dry_run only where that action supports it; reads can still cause network activity or cost. loop_replay checks stored regression cases and is distinct from an action dry run. Superseding revisions need the applicable passing replay.
On a client that exposes these owner lifecycle actions, the exact act envelopes are:
{"action":"loop_replay","item_id":"<loop id>"}
{"action":"loop_approve","item_id":"<loop id>"}
{"action":"loop_activate","item_id":"<loop id>"}
Each line is a separate request, not a JSON array. Invoke only the applicable action after inspecting the preceding result and confirming authority. Approval alone does not activate.
The tested hosted connector refuses loop lifecycle actions as unavailable. On that connection, stop at the stored proposal and hand the loop ID to an authorised operator using a supported Portal or client. Do not try a private endpoint or a different identity.
Observe and recover
Read get_loop and inspect actual cases with get_case {"loop_id":"<loop id>","case_id":"<case id>"}. Identify each node's result, waits and terminal outcome. Use the supported approval card for a human wait after inspecting the exact requested work.
On failure or interruption, inspect the existing case and outputs before retrying. Use act {"action":"loop_pause","item_id":"<loop id>"} through an authorised supported lifecycle interface. Retire a disposable loop with loop_retire after reconciling open cases.
Verification boundary
This exact spec shape was accepted as proposed/shadow on a development build. Scheduled execution, owner-wait completion, retirement and donated-action integration were not proved through the tested hosted connector. A source-valid request is not a live case pass.
Related
Practical guides for people and agents