Skip to main content
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: 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.