For agents and technical readers

Compose and supervise a bounded loop

Propose a loop, inspect its state, and hand approval or activation to an authorised supported interface. Verify a case before reporting execution.

Contents

Discover the current environment

  1. Call orient {} and verify the intended principal and Mind.
  2. Call list_skills {}, then get_skill {"name":"loop-composer"} if offered.
  3. Call list_actions {} and use only its current action IDs, argument shapes, effects and dry-run support.
  4. Call list_loops {}; inspect a possible existing loop with get_loop before 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

Start with one useful job

Join the waitlist

Plain text for AI agents. Same content as the human page.

## For agents

- What Mensara is: it gives a team its own Mind, one shared memory for the team and their AI agents, built by Xanadu Labs LLC.
- Status: signup is not open. A person joins the waitlist at https://app.mensara.ai/#waitlist. Agents cannot create an account or sign up.
- How you can help your person: explain what Mensara does, check whether it fits a job their team repeats, and share the waitlist link.
- Agent references: https://app.mensara.ai/llms.txt lists every page as Markdown and the tool input references for connected agents.

---

# Compose and supervise a bounded loop

Operating procedures · For agents and technical readers · [How it works](https://app.mensara.ai/how-it-works)

Propose a loop, inspect its state, and hand approval or activation to an authorised supported interface. Verify a case before reporting execution.

[Page as Markdown](https://app.mensara.ai/how-it-works/build-loop-procedure.md)

[Human guide](https://app.mensara.ai/how-it-works/first-loop)

## Compose and supervise a loop

Availability: Released loop composition; lifecycle depends on permissions and client support.

What changes: Composition proposes a shadow loop; activation separately enables recurring work.

Verification: Synthetic lifecycle spec accepted in development. Scheduled case and donated-action acceptance pending.

## Discover the current environment

1. Call `orient {}` and verify the intended principal and Mind.
2. Call `list_skills {}`, then `get_skill {"name":"loop-composer"}` if offered.
3. Call `list_actions {}` and use only its current action IDs, argument shapes, effects and dry-run support.
4. Call `list_loops {}`; inspect a possible existing loop with `get_loop` before 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

- [Build your first recurring workflow with a loop](https://app.mensara.ai/how-it-works/first-loop)
- [Pilot interface reference](https://app.mensara.ai/how-it-works/pilot-interface-reference)

[Join the waitlist](https://app.mensara.ai/#waitlist)