For agents and technical readers

Read a loop case and reconcile a wait

Use the returned loop and case identifiers to inspect real recorded progress. Loop management reads require the relevant operate_loops authority; being able to read ordinary company notes is not that grant.

Contents

Find and read the loop

Call list_loops with {} where exposed. Select the actual loop id and call get_loop:

{"loop_id":"<returned loop id>"}

Inspect its content, state, version, status, rollout and case summaries. Approved plus shadow is different from approved plus active. Do not infer an executed result from a loop's existence or approval.

Read one case

Call get_case with identifiers returned for that loop:

{"loop_id":"<loop id>","case_id":"<case id>"}

Inspect case, timeline, pending_wait, current status, close reason and available output. Respect redactions. Read each row's own shadow/execution marker: a shadow case can contain real read-only steps and metered checks.

The timeline does not supply every field a diagnostic might want; missing per-step timestamps or activity references are not a licence to invent them.

Answer a wait and verify continuation

If a human answer is required, show the actual question, options and available due time. Use the attention procedure and the current request reference. After acceptance, re-read the same case to determine what continued and whether it eventually completed, failed or escalated.

On timeout or error, preserve the current state and reason. Do not resubmit the original trigger to fake a resumed case.

Read aggregate metrics separately

get_loop_metrics requires a supported window of 7d, 30d or 90d; loop_id is optional. For one loop:

{"loop_id":"<loop id>","window":"7d"}

Counts, rates and spending describe the recorded window. They do not establish source truth or prove that a particular business outcome was correct. Retain exact case evidence for repeated corrections.

Related

Understand a loop case and follow its result · Prepare a loop correction and replay its replacement · Compose and supervise a bounded loop

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.

---

# Read a loop case and reconcile a wait

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

Use the returned loop and case identifiers to inspect real recorded progress. Loop management reads require the relevant operate_loops authority; being able to read ordinary company notes is not that grant.

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

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

## Use the released interface with current authority

Availability: Core0.20.11 / Portal0.3.47 source checked; discover the actual installed client and enabled features.

Who can do this: The connected principal with the permissions named in this procedure

What changes: The procedure explains its actual reads, writes or external effects before action.

Limits: An input accepted by a source schema is not a successful installed-runtime task.; Keep human decisions, client exclusions and pending results explicit.

Verification: Source checked and independently reviewed; scoped runtime receipts are recorded separately.

## Find and read the loop

Call `list_loops` with `{}` where exposed. Select the actual loop id and call `get_loop`:

```
{"loop_id":"<returned loop id>"}
```

Inspect its content, state, version, status, rollout and case summaries. Approved plus shadow is different from approved plus active. Do not infer an executed result from a loop's existence or approval.

## Read one case

Call `get_case` with identifiers returned for that loop:

```
{"loop_id":"<loop id>","case_id":"<case id>"}
```

Inspect `case`, `timeline`, `pending_wait`, current status, close reason and available output. Respect redactions. Read each row's own shadow/execution marker: a shadow case can contain real read-only steps and metered checks.

The timeline does not supply every field a diagnostic might want; missing per-step timestamps or activity references are not a licence to invent them.

## Answer a wait and verify continuation

If a human answer is required, show the actual question, options and available due time. Use [the attention procedure](https://app.mensara.ai/how-it-works/review-attention-procedure) and the current request reference. After acceptance, re-read the same case to determine what continued and whether it eventually completed, failed or escalated.

On timeout or error, preserve the current state and reason. Do not resubmit the original trigger to fake a resumed case.

## Read aggregate metrics separately

`get_loop_metrics` requires a supported `window` of `7d`, `30d` or `90d`; `loop_id` is optional. For one loop:

```
{"loop_id":"<loop id>","window":"7d"}
```

Counts, rates and spending describe the recorded window. They do not establish source truth or prove that a particular business outcome was correct. Retain exact case evidence for repeated corrections.

## Related

- [Understand a loop case and follow its result](https://app.mensara.ai/how-it-works/loop-cases)
- [Prepare a loop correction and replay its replacement](https://app.mensara.ai/how-it-works/loop-correction-procedure)
- [Compose and supervise a bounded loop](https://app.mensara.ai/how-it-works/build-loop-procedure)

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