> ## 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 the agents learn from you > What your declines and regenerate notes teach the agents in your workspace, where to see every lesson, and how to undo one. 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: | Reason | What it teaches | | - | - | | `wrong` | The work itself was bad. Counts against the playbook. | | `never_touch` | Never touch this. Counts against the playbook. | | `not_now` | Right idea, bad timing. Teaches nothing here. | | `already_done` | We duplicated work. Teaches nothing here. | 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](https://docs.attensira.com/brand-book/overview.md#what-weve-learned), 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](https://docs.attensira.com/brand-book/overview.md#what-weve-learned) 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: ```json theme={null} { "learned_rule": { "id": "", "text": "Never say \"cutting-edge\". Keep it plain." } } { "learned_rule": { "id": "", "remove": true } } { "playbook_suppression": { "id": "", "lift": true } } ``` 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: ```bash theme={null} curl https://api.attensira.com/v1/learned-rules \ -H "Authorization: Bearer atn_live_..." ``` 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.