Approval modes

​

One setting, every automation and chat

Approval mode is a single workspace setting: Ask, Draft, or Act. It applies to every automation run and every chat session in the workspace — there is no per-automation override. A project can make its own crew stricter than the workspace, never looser; see Projects can be stricter. When the Chief of staff hands work to a project, the hand-off is gated too. See Handing work to projects.

​

Ask

The agent stops and asks before anything that leaves the workspace — publishing a page, sending mail, spending with a third party. A card shows exactly what it wants to do. The run then waits for you, for up to 7 days. You can answer it on the card in the run, or from its row in your Inbox: Approve once lets the run make that one call, and Decline takes a reason and an optional note, which the run reads before it carries on without the call. If nothing is decided in that window, the run closes without doing the thing, and files a row in your Inbox saying so. See what the agent shows you.

​

Approvals are answered as asked

An approval cannot be edited, in the Inbox, the API or MCP. Your yes is bound to the exact call the run asked about, down to every argument, so a changed argument would be a different call that nobody approved. If the call is not quite right, decline it and say what to change in the note; the run reads your note before it decides what to do instead. This is different from a proposed article, post or rewritten passage, which you can edit before approving. An edited change always counts as a claim, so it waits for your yes in every mode and never goes out on its own. See Editing before you approve. In Ask, a goal that falls behind its pace line does not start a re-plan run on its own. One row in your Inbox offers the re-plan instead. In Draft and Act the re-plan run starts, and the work it plans follows the mode like any other work. See Goal re-plans.

​

Draft (default)

The agent does everything inside the workspace on its own, and files everything else as work awaiting your approval. Nothing is published, sent, or written outside the workspace until you approve it. This is the mode every new workspace starts in.

​

Act

The agent carries safe changes through on its own, without stopping. Safe means hygiene work: structured data, meta descriptions, alt text, internal links, heading structure. Anything touching a claim — a number, a price, a product or competitor name, a commitment — is filed for your approval in every mode, Act included. A change you edited before approving is always a claim. Code blocks and code samples are never edited, in any mode. A safe change goes ahead on its own only when the draft check passes it. A change the check holds waits for you, whatever the mode.

​

Projects can be stricter

Each project has its own setting, On its own, with the same three modes under the names its settings use: Ask first (Ask), Leave drafts (Draft) and Act. Every run in the project works under the stricter of the project’s setting and the workspace’s: So a project can hold one area of work to a tighter rule, such as a project that writes about pricing in an otherwise Act workspace, but it can never loosen the workspace. In the project’s settings, the options looser than the workspace are shown switched off, with the reason: “Your workspace is set to Ask first; a project can be stricter, not looser.” If the workspace is tightened after a project was set, the project shows what it was saved as and that the crew now works at the workspace’s setting. If the project’s setting cannot be read when a run starts, that run works as Ask: a fault never gives the crew more freedom than you set. Everything else on this page holds inside a project too: the classes below, the change caps, and anything that cannot be undone, like sending an email or spending money, asking first whatever either setting says.

​

What Attensira changes on its own, and what it always asks about

Every proposed change is put into one of three classes before anything happens to it. The class is worked out from the change itself — the before-and-after of the file, and where it lives — never decided by the agent about its own work. Editable directories default to /docs/** and /content/**, plus any content roots you named when connecting the repository, plus llms.txt, robots.txt and sitemaps at the root. Changeable in project settings. Every change is recorded with who and when. Every decision carries the rule that decided it, in plain words — the same rule you see above, not a paraphrase of it. The rules are scored against a set of 42 adversarial changes on every change to the classifier; the current miss rate is 0%.

​

The draft check

Every draft the agent writes in your name is checked against your rules and ours before anyone can approve it. The agent does the checking and the rewriting. You write a rule once, and every draft after it is held to that rule.

​

What is checked

​

Which rules

• Your compliance rules (Customize → Guardrails → Compliance): what may never be said in your name. A draft that clearly breaks one is stopped. One that may break it goes to review.
• Your voice rules (How agents write): how the agents should sound. A voice rule never stops a draft. One that may not follow it goes to review.
• Words to avoid: phrases listed on a rule of either kind, forbidden outright. They are matched exactly, ignoring case, on whole words. One hit stops the draft, wherever it appears in what is read.
• Our house rules: run on every draft in every workspace, on every plan, whether or not you have written any rules of your own.

A rule applies to every kind of draft unless you pick where it applies: pages, articles, emails, community replies, social posts or ads. Only rules that are switched on are checked. Some house rules have a certain part that needs no judgement, such as an internal field name in an article. It is matched first, on the words a reader sees. Code blocks, inline code and link addresses are set aside, because in a tutorial they are the subject, not a leak.

​

The verdict

The check gives each draft one verdict, recorded on the draft with the exact text and the exact rules it was checked against. N counts your rules and our house rules together. A draft that could not be checked is never treated as passed, because a draft nobody checked is not a draft that is fine. The check says why it could not finish:

• your rules could not be read;
• the check did not answer for every one of your rules;
• the draft is too long to check in one go. Split it, then check it again.

One row in your Inbox says We could not check N drafts against your rules. Its Retry opens the draft, and approving it checks it again. The row clears itself once no draft in the workspace is still waiting on a check. If a stop was already found before the check broke off, the stop stands. Our house rules work differently when the check cannot answer. A house rule it could not answer is left out of N and does not change the verdict, and its certain part still runs. Before the house rules existed, a draft was not checked against them at all, so a gap in the check does not hold every draft in every workspace.

​

When the agent hits a stop

• An article that is stopped is not filed at all. The agent is told which rule it breaks and revises it once, and the revision is checked again. If the same article is stopped a second time, it is never filed for approval. The agent asks you instead, in your Inbox: what the article should say instead, or what source backs it. You can also tell it to leave that part out and write it again, or to drop the article. The draft is in the conversation beside the question.
• Any other draft, and an article that is not stopped, is filed with its verdict. A stopped one cannot be approved or sent until it is revised.
• On a review, the agent revises once if it can keep the rule without losing the point. Otherwise it says which rule and why.

​

Where the verdict is enforced

• Approving. A stopped draft is refused, and so is one that still cannot be checked. The draft is checked once more first; when neither the draft nor the rules changed, the last verdict answers. An edited draft you approve, in the dashboard or with edited_value over MCP, is checked as your words before it is saved. This holds wherever the yes comes from: the dashboard, the MCP server or the REST API. A refusal is a conflict (409) whose message names the rules.
• Publishing. What was approved is what was checked. A draft whose verdict is stopped or not checked is refused. So is a draft that changed after its verdict, with “this draft changed after it was checked against your rules”. Check it again, then approve it.
• Sending. An outreach email is checked once more just before Attensira sends it from your mailbox. A stopped email, or one that still cannot be checked, is not sent. An email edited between that check and the send is not sent either.
• Act mode. A safe change goes ahead on its own only on a passed verdict. Anything else waits for your approval, with the note “Held by the draft check:” and the rules it is held on.
• Notion. An article whose verdict is anything but passed is kept as a draft row in Notion, even in Act mode, with the same note. Your team publishes it by changing its status.

The check only ever adds a stop. It never makes a change safe, never approves anything, and never changes which class a change is in. A passed draft still needs every yes it needed before. Changing a rule changes the verdict for every draft after it. A verdict given under the old rules is checked again when the draft is next approved. Something approved before drafts were checked has no verdict. It publishes under the rules it was approved under.

​

Handing work to projects

When the Chief of staff hands work to a project, the hand-off itself is an action and is gated like one:

• Ask: an approval card first. No task is filed until you approve the hand-off.
• Draft and Act: filed without asking. A task stays inside the workspace, and cancelling its session undoes it.

Work you hand off yourself is your own action and is not put through the gate. That covers only the filing. Each task’s work runs in its own session, under the stricter of the workspace’s mode and the project’s, and every change it proposes is classified and gated exactly as below. Routing a line to a project never approves anything and never changes a mode.

​

Articles and social posts

A new article the agent writes is filed in your Inbox for approval, and goes where your connections allow, in this order: a pull request in a connected repository with a blog directory; a draft in your connected Webflow or Shopify site (WordPress cannot take new articles yet); a draft page in Notion; otherwise a copy you paste yourself. Approving it creates the draft. Attensira never publishes a new article in your CMS: it stays a draft until you publish it there. A LinkedIn post is never posted by Attensira, in any mode. It waits in your Inbox to copy, with its image and alt text when it has one. The time it is planned for, the time you asked for or the first of three suggested weekday mornings, brings a reminder back to your Inbox; you post it from your own account and mark it shipped with the post’s link.

​

Google Ads spend

Google Ads changes are classed by the same idea, applied to money: what each change does to the campaign, read from the campaign’s state before and after it, never from what the agent says about it. Two rules apply to Google Ads alone:

• Spend is approved in the app. A claim is approved only by a person signed in to the Attensira app. An API key, an assistant over MCP and a client reviewer link all get 403 Forbidden with the reason spend_approval_in_app. Safe changes can be approved from anywhere you approve other work.
• The spend guard pauses without asking. When a campaign’s spend this month nears the monthly budget you approved, the spend guard pauses it, in every mode, with no approval behind it. It can only pause, never turn anything on.

Ad spend is paid to Google from your own Google Ads billing. It is not our fee, and it does not count toward the credit cap below.

​

What no mode changes

These hold regardless of the mode you pick:

• We merge a pull request only when you press Merge in your Inbox, or when you switched on auto-merge for safe changes, and then only safe changes. Approving a change opens its pull request; it never merges it. A pull request is a proposal; closing it undoes it.
• We never delete anything irreversibly without an explicit yes.
• We never send mail from your domain on your behalf without one.
• A draft the draft check stopped is never approved as written. One it could not check is never approved, published or sent.
• We never start or raise Google Ads spend without a signed-in person’s yes in the app.

​

Changing your mind is retroactive

Mode is checked again when the work actually runs, not only when it was proposed. If you tighten the setting between a chat suggesting something and an automation acting on it, the tighter rule applies at run time. Your own approval of one specific change still goes ahead even if you have not changed the mode — approving an action and changing the workspace default are different decisions. Every change to the setting is recorded: who changed it, and when.

​

Why your workspace is in Draft

New workspaces start in Draft: the agent does the work and waits for your yes before anything leaves the workspace. Workspaces created before September 2026 had a setting with this same name, but it was only a default applied to new automations — it did not govern outward writes. When it began to govern real permissions, every existing workspace was moved to Draft and its owner was emailed once about the change. Workspaces created since do not get that notice. If you want the agent to carry hygiene changes through on its own, choose Act — Draft does not change on its own.

​

Auto-merge for safe changes

auto_merge_safe_changes is off by default. When you switch it on, a safe change (structured data, meta tags, alt text, internal links) that went out unattended under Act and within the weekly caps is squash-merged by Attensira, at exactly the commit Attensira pushed, once GitHub reports the pull request mergeable with every required check and review satisfied. Titles and headings are claims and never auto-merge. The pull request is handed back to you, with a note on the work item, and not merged if any of these happens:

• anyone else pushes to the branch;
• it is converted to a draft;
• it conflicts;
• a check fails;
• GitHub refuses the merge;
• the setting is switched off;
• it has waited more than 14 days since it opened.

The pull request’s body says whether it will auto-merge.

​

Change caps

Act mode is not unlimited. Each kind of change carries its own limits, and they are yours to set under Settings → Autopilot (at /settings/agents). Only changes we made without you count. A change you approved yourself is not rationed; the caps exist to bound what happens while you are not looking. Limits are set per change class. Hygiene changes (structured data, meta descriptions, alt text, internal links, heading structure) can be set to act on their own. Claims, anything asserting something a customer could hold you to, never act on their own, whatever the workspace default is set to. There is no setting that changes that.

​

When a cap is reached

The change stays approved and waits:

• it shows in your Inbox as Waiting: weekly cap, on the in-flight tab rather than in “needs you”; you already said yes, and we will not ask twice;
• one item appears in your Inbox that week, and one message reaches you, however many changes are waiting behind the cap;
• it goes out on its own once the week rolls over or you raise the cap. Nothing has to be un-paused by hand and nothing is thrown away.

A cap is never a silent stop. If your agent has gone quiet, the Inbox says why.

​

Weeks and months

A week starts on Monday in your workspace’s own time zone, and a month on the first, also in your workspace’s time zone. The credit cap is set per change class but counted per workspace: it counts what this workspace was charged this month, less refunds, and nothing another workspace in the organisation spent. That is agent work and the reads of your own pages that monitoring makes, the same spend Costs shows for the workspace. One credit is one cent. This cap is not the workspace’s monthly credit cap, which pauses the workspace’s automations and counts a UTC month. Both count the same spend; only where their month starts differs.