> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attensira.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How a workflow remembers its last runs

> Each mission and automation keeps a short retro of every run that delivered work: what it tried, the verdicts so far, and what to do next time. The next run reads it before it plans.

> [!WARNING]
>
> **Not on `api.attensira.com` yet.** Workflow memory is live: runs write retros and read them before they plan. The routes on this page (`GET /v1/missions/{id}`, `GET /v1/missions/{id}/retros`, `GET /v1/automations/{id}/retros`, `PATCH /v1/retros/{id}` and `DELETE /v1/retros/{id}`) are served on `webapp.attensira.com`. `api.attensira.com` does not serve them yet and answers `404`, and no MCP tool lists retros on their own yet.

## One memory per workflow

A **mission** (a project with a goal) and an **automation** run again and again. Each keeps its own memory: a list of short **retros**, one per milestone.

A retro has three parts:

| | |
| - | - |
| **Tried** | The changes filed since the last retro, by name and id, including work the run handed to a sub-task |
| **Results** | The verdicts those and the workflow's earlier changes hold so far |
| **Next time** | What to do differently, decided from those verdicts |

The next run of the **same** mission or automation reads its last three retros before it plans. A chat, another automation, or another mission never reads them.

## When a retro is written

* **An automation** writes one each time a run completes. A run that filed nothing and found no new verdict writes none, because it would only repeat the last entry.
* **A mission** writes one each time a run completes having filed work: that is a milestone. A long thread that files work over several turns gets one retro per milestone, each naming only what was filed since the one before. A reply that delivered nothing is not a milestone.
* A run that failed or was stopped writes none.

## Built from records, never guessed

A retro is written from what is on record, not from a model's impression of how it went:

* **Tried** lists the changes actually filed.
* **Results** counts the verdicts on each change's receipt, and cites the receipt it came from. A change still being checked is counted as still being checked; it is never reported as a result.
* A result inside the sampling noise is written as **too close to call**, never as a change. Fewer mentions is written as fewer mentions, never as moved.
* **Next time** follows from those verdicts: build on what moved, do not repeat what was followed by fewer mentions, and after two or more changes that showed nothing we can prove, try a different kind of change.

If nothing is on record to cite, no retro is written.

## Read over MCP and the API; edited or deleted by a person

Retros belong to the workspace that ran the workflow and are never read from, or shown to, any other workspace.

* **Read**: retros come with the mission or automation over MCP (`get` on a mission or an automation) and over the API: `GET /v1/missions/{id}`, `GET /v1/automations/{id}`, and the lists at `GET /v1/missions/{id}/retros` and `GET /v1/automations/{id}/retros`.
* **Edit**: a person signed in to Attensira can rewrite what was tried and what to do next time (`PATCH /v1/retros/{id}` with `tried` and/or `next_time`). The verdicts and the receipts they cite cannot be edited: they are the receipts'.
* **Delete**: a person signed in to Attensira can delete one (`DELETE /v1/retros/{id}`). A deleted retro is not read by any later run.

An API key or an assistant's connection can read retros but cannot edit or delete one, because what a workflow remembers shapes every later run.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.