For agents and technical readers

Compose, approve and inspect an automation

Build a trigger and ordered action chain from the live installed palette. Approval can enable future dispatch, so agree the intended effects before the lifecycle action.

Contents

Discover installed actions

Call orient and list_actions with {}. Use the returned app ids, action ids, argument schemas, effects and declared outputs. A catalog entry is not an installed action. If the job requires a quality gate or human wait, use a loop.

Load get_skill with {"name":"automation-composer"} when available. Confirm the trigger, inputs, outside effects and connections within the user's authority.

Submit the agreed composition

The following is a template, not an accepted example. Replace identifiers and args with a real palette entry and a trigger supported by the current schema:

{"name":"<agreed name>","description":"<bounded purpose>","trigger":{"every":"1d"},"steps":[{"app_id":"<installed app id>","action_id":"<declared action id>","args":{}}]}

Call automation_compose. Required fields are name, description, trigger, steps; each step needs app_id, action_id, args. Use prior-output bindings only where the live palette declares compatible outputs and bounds. For a replacement, use supersedes with the existing automation reference after reading it.

Read the returned automation id and proposed state. After a lost response reconcile the stored composition before retrying; the first call may have persisted it.

Review and control the stored automation

An authorised person inspects the exact trigger and steps. If the client's act action allowlist supports them, lifecycle calls take the returned automation id as item_id:

{"action":"automation_approve","item_id":"<automation id>"}

Other supported lifecycle actions are automation_reject, automation_pause, automation_resume, automation_retire, subject to the current status. Approved automations are dispatch-eligible; do not describe approval as a shadow-only preview.

If the client excludes these actions, provide the automation reference and requested decision to an authorised operator or Portal. Do not bypass the client's allowlist.

Inspect an actual run

Read the automation's state and normal scheduled/event run through the supported Portal or operator interface. Check per-step failure and output. The chain stops at a failed step, and installed app authority is checked again at dispatch. A held output needs ordinary review; read back the saved source after application.

Retiring stops future dispatch but does not undo prior effects. A lost action response must be reconciled before repeating an external-effect step.

Related

Automate a routine task with installed actions · Control agent autonomy, budgets and access

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, approve and inspect an automation

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

Build a trigger and ordered action chain from the live installed palette. Approval can enable future dispatch, so agree the intended effects before the lifecycle action.

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

[Human guide](https://app.mensara.ai/how-it-works/automate-a-task)

## 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 installed actions

Call `orient` and `list_actions` with `{}`. Use the returned app ids, action ids, argument schemas, effects and declared outputs. A catalog entry is not an installed action. If the job requires a quality gate or human wait, use [a loop](https://app.mensara.ai/how-it-works/build-loop-procedure).

Load `get_skill` with `{"name":"automation-composer"}` when available. Confirm the trigger, inputs, outside effects and connections within the user's authority.

## Submit the agreed composition

The following is a template, not an accepted example. Replace identifiers and args with a real palette entry and a trigger supported by the current schema:

```
{"name":"<agreed name>","description":"<bounded purpose>","trigger":{"every":"1d"},"steps":[{"app_id":"<installed app id>","action_id":"<declared action id>","args":{}}]}
```

Call `automation_compose`. Required fields are `name`, `description`, `trigger`, `steps`; each step needs `app_id`, `action_id`, `args`. Use prior-output bindings only where the live palette declares compatible outputs and bounds. For a replacement, use `supersedes` with the existing automation reference after reading it.

Read the returned automation id and proposed state. After a lost response reconcile the stored composition before retrying; the first call may have persisted it.

## Review and control the stored automation

An authorised person inspects the exact trigger and steps. If the client's `act` action allowlist supports them, lifecycle calls take the returned automation id as `item_id`:

```
{"action":"automation_approve","item_id":"<automation id>"}
```

Other supported lifecycle actions are `automation_reject`, `automation_pause`, `automation_resume`, `automation_retire`, subject to the current status. Approved automations are dispatch-eligible; do not describe approval as a shadow-only preview.

If the client excludes these actions, provide the automation reference and requested decision to an authorised operator or Portal. Do not bypass the client's allowlist.

## Inspect an actual run

Read the automation's state and normal scheduled/event run through the supported Portal or operator interface. Check per-step failure and output. The chain stops at a failed step, and installed app authority is checked again at dispatch. A held output needs ordinary review; read back the saved source after application.

Retiring stops future dispatch but does not undo prior effects. A lost action response must be reconciled before repeating an external-effect step.

## Related

- [Automate a routine task with installed actions](https://app.mensara.ai/how-it-works/automate-a-task)
- [Control agent autonomy, budgets and access](https://app.mensara.ai/how-it-works/control-agent-autonomy)

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