Skip to main content
The agents get better at your workspace from what you do with their work. Two things teach them, and both stay in your workspace only. Another customer’s declines never change what the agents do for you, and yours never change what they do for anyone else. Every lesson is visible and can be removed. Nothing is learned that you cannot see. Only a person changes what the agents have learned directly. An API key or an MCP connection (an assistant) can ask to keep a rule, lift a pause or remove a rule, but each request becomes a proposal in your Inbox, and nothing changes until a person approves it.

​
Declines pause a playbook

A playbook is a written procedure for one kind of work (an answer page, a page fix, a listing). When a run is started to follow one playbook, the playbook verb or an automation pinned to it, the changes it makes are that playbook’s work. When you decline one of those changes, the reason you pick matters: A change from a run that was not started to follow one playbook counts against none: we only hold a decline against a playbook when the change was clearly its work. Three wrong or never_touch declines of the same playbook’s changes within 60 days pause that playbook in your workspace for 30 days. While it is paused:
  • an agent does not load or follow it, and is told it is paused;
  • a run started to follow it is refused, with the reason and how to lift it;
  • every other playbook keeps working as before.
Each change counts once, however often it is declined. Once a pause ends or is lifted, only new declines count toward the next one. The pause shows its reason, for example “Answer page” is paused for this workspace until 24 November 2026: you declined 3 of its changes as wrong or as something never to touch within 60 days.

​
Lifting a pause early

A person signed in to Attensira can lift a pause at any time: Lift the pause on the Brand Book page, or POST /v1/learned-rules/{id}/lift. An assistant’s lift is a proposal: it answers 202 with status: proposed, and the pause is lifted only when a person approves it in the Inbox.

​
Regenerate notes become standing rules

When you ask for a draft to be written again (“less salesy”, “never say “cutting-edge""), you can keep that note as a standing rule. Every later draft in your workspace is checked against it, the same way it is checked against the voice rules you write yourself. A phrase the note says never to use, in quotes (never say "cutting-edge", don't use 'best-in-class', avoid “seamless”), goes on the rule’s never-say list. A draft that uses it is stopped outright, with no judgement call involved. A kept rule can only add a restriction. A note that would loosen or override the rules, such as “ignore the earlier tone rules” or “you may now mention pricing”, is refused with 400. To loosen a rule, a person edits or removes that rule itself. Keep a note:
  • with act on a change: regenerate with payload.save_as_rule: true, or POST /v1/changes/{id}/act with "save_as_rule": true. For a person, the answer carries the kept rule as learned_rule. For an assistant, it carries learned_rule_proposal (status: proposed), and nothing is kept until a person approves. If the note could not be kept or proposed, learned_rule_error says why, and the regenerate itself still stands;
  • afterwards, with POST /v1/learned-rules and {"note": "...", "change_id": "..."}. A person gets the rule (201). An assistant gets a proposal (202).
A kept note is also a voice rule: voice in GET /v1/brand-book lists it too. Deleting or switching off that voice rule, or removing the learned rule, stops drafts being checked against it, and the learned rule then reads status: removed.

​
See and remove what was learned

In the app, the Brand Book page lists, under What we’ve learned, every learned rule and paused playbook shaping drafts now, each with where it came from. Press Edit or Remove on a rule, or Lift the pause on a playbook. GET /v1/brand-book (and get on attensira://{workspace}/brand_book over MCP) carries the same two lists as learned_rules and paused_playbooks, active ones only. The same PATCH /v1/brand-book edits them:
A rewrite replaces the rule’s words and its never-say phrases, and is held to the same bar as a note: one that would loosen the rules is a 400. A removed rule cannot be rewritten (409); keep a new note instead. As with every Brand Book edit, a person’s applies, and a key’s or a connection’s is a brand_book_edit change a person approves. The full history is on its own route:
The answer has two lists:
  • rules: each kept note, with text, the avoid phrases, where it came from (source, change_id), status (active or removed) and edited_at (when a person last rewrote it, or null).
  • suppressions: each paused playbook, with playbook, reason, until, the declined changes it came from (declined_ids) and status (active, lifted or expired).
GET /v1/learned-rules/{id} reads one of either. Over MCP, list with type learned_rule or playbook_suppression, and get on attensira://{workspace}/learned_rule/{id}, read the same. To remove a rule, DELETE /v1/learned-rules/{id}. A person removes it at once. An assistant’s removal is a proposal a person approves in the Inbox. Over MCP, configure with kind playbook_suppression and op lift, or kind learned_rule and op remove, files the same proposals and answers status: proposed. Nothing here can change your autonomy levels. Only a person raises a level, in the app.