For agents and technical readers

Inspect the Inbox and route each human decision

Read the requests visible to the caller, identify their kind and use the supported action for that specific object.

Contents

Discover the worklist

Verify the Mind and caller with orient. If advertised, get_governance_inbox accepts {} or a window of 7d, 30d or 90d. It is a caller-scoped read, not extra authority.

{"window":"7d"}

For ordinary held proposals, list_review_queue can include proposal content and pagination:

{"limit":20,"include_content":true}

Handle incomplete responses

Follow returned cursors. Fetch named deferred proposals with the advertised get_proposal batching contract rather than treating them as empty. Do not report all clear after any component read failed or was incomplete. Each card still has its own authority checks.

Choose the correct request kind

Separate an ordinary proposal, a human question, a loop wait, a record review and a loop revision. Read the current source, proposed difference and evidence for a proposal. Read the question/options and effects for a wait. Use only the specific action contract advertised by the current connection, preserving the actual object reference and any required confirmation/hash fields.

Human and client handoff

For a human approval request, show the actual changes to the person or send its supplied approval link. Never invent the person’s confirmation. If the current client lacks the required decision action, hand the existing request reference and the intended decision to an authorised person in the Portal. Do not convert a read API into an internal mutation call.

Read the outcome

After a decision, inspect the original object again. For a saved edit, read the changed source and verify wording. A lost response requires reconciliation before retry. Preserve waiting or refused outcomes in the report; a cleared item is not proof that every related task or external action completed.

Related

Know what an agent may read or change · Read, correct and verify memory

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.

---

# Inspect the Inbox and route each human decision

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

Read the requests visible to the caller, identify their kind and use the supported action for that specific object.

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

[Human guide](https://app.mensara.ai/how-it-works/read-and-propose)

## 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.

## Discover the worklist

Verify the Mind and caller with `orient`. If advertised, `get_governance_inbox` accepts `{}` or a window of `7d`, `30d` or `90d`. It is a caller-scoped read, not extra authority.

```
{"window":"7d"}
```

For ordinary held proposals, `list_review_queue` can include proposal content and pagination:

```
{"limit":20,"include_content":true}
```

## Handle incomplete responses

Follow returned cursors. Fetch named deferred proposals with the advertised `get_proposal` batching contract rather than treating them as empty. Do not report all clear after any component read failed or was incomplete. Each card still has its own authority checks.

## Choose the correct request kind

Separate an ordinary proposal, a human question, a loop wait, a record review and a loop revision. Read the current source, proposed difference and evidence for a proposal. Read the question/options and effects for a wait. Use only the specific action contract advertised by the current connection, preserving the actual object reference and any required confirmation/hash fields.

## Human and client handoff

For a human approval request, show the actual changes to the person or send its supplied approval link. Never invent the person’s confirmation. If the current client lacks the required decision action, hand the existing request reference and the intended decision to an authorised person in the Portal. Do not convert a read API into an internal mutation call.

## Read the outcome

After a decision, inspect the original object again. For a saved edit, read the changed source and verify wording. A lost response requires reconciliation before retry. Preserve waiting or refused outcomes in the report; a cleared item is not proof that every related task or external action completed.

## Related

- [Know what an agent may read or change](https://app.mensara.ai/how-it-works/read-and-propose)
- [Read, correct and verify memory](https://app.mensara.ai/how-it-works/correct-memory-procedure)

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