For agents and technical readers

Create, update and verify a task

Use the canonical task tools to keep one saved work record with a checkable outcome. Discover the intended Mind, project and authorisation before writing.

Contents

Find before creating

Call orient with {} and follow the task map and its task-authoring contract. Then call task_list with a bounded filter, for example:

{"text":"<distinctive job wording>","limit":20}

Read each likely match with task_get using {"id":"<returned task id>"}. A redacted or unavailable result is not a complete read. Use the returned canonical task rather than copying its title into a new file.

Create through the allocator

If there is no existing task and creation is authorised, call task_create. Obtain the prefix and project from the Mind's task contract; do not invent a complete task id.

{"prefix":"<permitted allocator prefix>","project":"<permitted project>","title":"<specific outcome>","status":"backlog","finish_gates":["<observable completion condition>"]}

Read the returned result and its minted id. If the response is lost, reconcile task_list and the creation result before creating again.

Update under current ownership

For an agent that will own the work, follow the session and claim procedure. Retain the current session id and returned claim generation. Call task_get immediately before a body or checklist replacement.

{"id":"<task id>","session":"<current session id>","claim_context":{"<task id>":{"session_id":"<current session id>","generation":1}},"expected_content":"<entire exact content from the latest task_get>","body":"<updated Markdown body, without frontmatter>"}

Replace generation 1 with the actual returned generation. A checklist update also supplies expected_checklist exactly matching the current checklist when one exists. Preserve unrelated fields and body content.

Verify the lifecycle result

Use supported states: backlog, active, in-progress, blocked, review, done, cancelled. A transition can use task_transition with id, status and current claim_context. Set done only after the recorded finish conditions have evidence. Read the task again and report its actual saved state.

On stale content or claim refusal, read the task and ownership again. Do not replay the old update or approve a held task proposal under an obsolete generation.

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.

---

# Create, update and verify a task

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

Use the canonical task tools to keep one saved work record with a checkable outcome. Discover the intended Mind, project and authorisation before writing.

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

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

## 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 before creating

Call `orient` with `{}` and follow the task map and its task-authoring contract. Then call `task_list` with a bounded filter, for example:

```
{"text":"<distinctive job wording>","limit":20}
```

Read each likely match with `task_get` using `{"id":"<returned task id>"}`. A redacted or unavailable result is not a complete read. Use the returned canonical task rather than copying its title into a new file.

## Create through the allocator

If there is no existing task and creation is authorised, call `task_create`. Obtain the prefix and project from the Mind's task contract; do not invent a complete task id.

```
{"prefix":"<permitted allocator prefix>","project":"<permitted project>","title":"<specific outcome>","status":"backlog","finish_gates":["<observable completion condition>"]}
```

Read the returned result and its minted id. If the response is lost, reconcile `task_list` and the creation result before creating again.

## Update under current ownership

For an agent that will own the work, follow [the session and claim procedure](https://app.mensara.ai/how-it-works/handoff-task-procedure). Retain the current session id and returned claim generation. Call `task_get` immediately before a body or checklist replacement.

```
{"id":"<task id>","session":"<current session id>","claim_context":{"<task id>":{"session_id":"<current session id>","generation":1}},"expected_content":"<entire exact content from the latest task_get>","body":"<updated Markdown body, without frontmatter>"}
```

Replace generation `1` with the actual returned generation. A checklist update also supplies `expected_checklist` exactly matching the current checklist when one exists. Preserve unrelated fields and body content.

## Verify the lifecycle result

Use supported states: `backlog`, `active`, `in-progress`, `blocked`, `review`, `done`, `cancelled`. A transition can use `task_transition` with `id`, `status` and current `claim_context`. Set done only after the recorded finish conditions have evidence. Read the task again and report its actual saved state.

On stale content or claim refusal, read the task and ownership again. Do not replay the old update or approve a held task proposal under an obsolete generation.

## Related

- [Track tasks and check their progress](https://app.mensara.ai/how-it-works/track-tasks)
- [Renew a task claim and hand work over](https://app.mensara.ai/how-it-works/handoff-task-procedure)

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