How often should an automation run?

No more often than the data changes. Each Prompt × Model × country is measured at most once per workspace-local calendar day, so an hourly automation over daily-sampled data re-reads identical measurements and spends credits doing it. Weekly is a good default for reporting, daily for a watch on something moving.

What happens if my script retries a run?

Nothing is double-billed, provided you send an idempotency key. Over MCP, run_automation takes an idempotency_key argument that is sent upstream as the Idempotency-Key header; over REST you send the header yourself. The same key resolves to the first run rather than starting a second.

Does creating an automation cost credits?

No. Creating is free. Executing is not: every run is metered agent work, and a scheduled run costs the same as one you trigger by hand. Cost scales with how much the run actually does, so one that fans out across many prompts and pages costs more than a narrow one.

What happens when a scheduled run fails?

It is raised in your Inbox rather than left in a log. If the same failure happens every night it does not produce a row per night — the Inbox recognises the repeat and updates the existing row with a count, so “14 times” tells you the problem has been there for two weeks.

Can an automation publish something without asking me?

No. Anything irreversible — publishing, sending mail, spending with a third party — stops for your explicit yes, wherever it happens. If the approval goes unanswered for 7 days the run closes without doing the thing and nothing is changed.

Can I manage automations from my own tooling?

Yes. The MCP server exposes list_automations, get_automation, create_automation, run_automation and delete_automation, and the REST API mirrors them. No tool takes a workspace id — the key you authenticate with names the workspace, so a request cannot be pointed at someone else's data.

Automations

Standing instructions the agent carries out on a cadence

An automation is an instruction you write once and the agent runs on a schedule. Every execution is a stored run you can read back and compare. Manual and API-triggered runs take an idempotency key, so a retry resolves to the first run instead of billing a second one.

Get Started Book A Demo

Written like a task
Name the window, the scope and the shape of the output you want.
A run history
Every run records when it fired, what the agent did and what it produced.
Idempotent by key
The same idempotency key twice does not start a second billed run.
Manageable over MCP
List, get, create, run and delete — the key names the workspace.

By Karl-Gustav KallasmaaLast updated September 3, 2026Behaviour on this page is checked against docs.attensira.com

What an automation is

An automation is the same kind of request you would type into a chat — “summarise which prompts gained or lost citations this week and name the pages involved” — attached to a cadence, so you stop having to ask. Each execution is a run, and runs are stored, so the automation accumulates a history you can compare week over week.

This is the surface that turns a one-off answer into an operating rhythm. It is also the surface most of the jobs people want from an AI visibility tool actually live in: a weekly citation report, a watch on one topic, an internal linking pass. Those are things you ask for, not modules we shipped — which is exactly why they are automations rather than separate features.

The agent can offer one, and nothing is created until you confirm

You do not have to build an automation from scratch. Ask the agent for something recurring in a chat — “check this every week”, “let me know when this slips” — or let it notice that an answer it just gave is only useful if somebody re-reads it later, and it will offer to save the work: a name, a cadence, the tools it needs, and the instruction it would run.

That offer is a card in the chat, not a saved automation. Nothing exists until you confirm it, and confirming drops you into the same automation you would have written by hand — editable and deletable afterwards like any other. The agent proposes; you decide what gets a schedule and a budget.

Writing an instruction that produces comparable runs

Write it as a task, not a topic. “Weekly visibility” gives the agent nothing to do. “Compare mention rate for the Pricing topic against the previous 7 days, list every prompt whose change was significant, and say which were not measured” tells it what to produce and how to handle gaps.

Be explicit about the window, the scope and the output shape. The automation reads the same workspace data a chat does, under the same rules: null still means not measured, and a delta below the 95% significance threshold still means no change we can prove, not zero.

Pin the window to the cadence. A weekly automation that reads the last 7 days produces comparable runs; one that reads “recently” does not.
Say what to do when a number is missing, so an unmeasured cell is reported rather than silently dropped.
Attach a skill (on Growth and Business) when you want the same structure every week.

Cadence, and what actually bounds freshness

The cadence sets how often the automation runs. Set it against how fast the underlying data can change — and that is bounded by measurement, not by scheduling.

Each Prompt × Model × country is measured at most once per workspace-local calendar day. Sampling depth is n=1 on Starter and n=3 on Growth and Business. So an hourly automation over daily-sampled data is a recurring bill for the same answer: repeated runs over identical measurements, each spending credits.

Match the cadence to the sampling, not to your reporting habit. This is the single most expensive mistake available on this screen, which is why the documentation says it in a warning box and why this page repeats it.

Runs, run history and what a boring run means

Every run records when it fired, what the agent did, and what it produced. Open the history to compare this week's output with last week's, or to check whether a gap in a report came from missing measurements rather than from the agent.

A run that reports no significant change is doing its job. It is telling you the movement was below the noise floor — which, at n=1 sampling in particular, is the honest answer far more often than a tool with a blended score will admit.

A scheduled run that fails does not vanish into a log. It is raised in your Inbox, because a chat that fails is failing in front of you and a 3am run is not.

Idempotency: the reason a retry is safe

Manual and API-triggered runs accept an idempotency key. Send the same key twice and the second request does not start a second billed run — it resolves to the first one. That is what makes a retry safe when a network call times out or a script re-fires.

Over MCP, run_automation takes an idempotency_key parameter, sent upstream as the Idempotency-Key header. Over the REST API you send that header directly. Derive the key from the thing you mean to run once — the automation id plus the period — so a repeat of the same intent reuses it and a genuinely new run does not.

MCP tool	What it does
list_automations	Read-only. Does not spend credits
get_automation	Read-only. Does not spend credits
create_automation	Creates the automation. Creating is free
run_automation	The only one of the five that spends credits
delete_automation	Marked destructive — it removes the automation

A real weekly instruction

This is an instruction that produces runs you can put side by side, and a trigger that is safe to retry.

Instruction: “Compare mention rate for the Pricing topic against the previous 7 days.

List every prompt whose change clears the 95% gate, name the cited pages,

and say explicitly which Prompt × Model pairs were not measured.”

Cadence: weekly (the data refreshes at most once per day, so weekly is honest)

curl -X POST https://api.attensira.com/v1/automations/aut_7f3c/runs \

-H "Authorization: Bearer atn_live_<your key>" \

-H "Idempotency-Key: weekly-pricing-2026-09-01"

Fire that curl three times because your CI retried and you get one billed run, not three. Change the period in the key and you get a new one, because you meant a new one.

What it does not do

An automation is a schedule around the agent. It inherits every limit the agent has, and adds a couple of its own.

It cannot make data fresher than the measurement allows. Each Prompt × Model × country is read at most once per workspace-local calendar day.
It cannot report a movement it cannot prove. A delta below the 95% two-proportion threshold comes back as no change we can prove, not as a small number with an arrow.
It cannot run for free. Creating an automation costs nothing; every execution is metered agent work, and scheduled runs cost the same as manual ones.
It cannot bypass approvals. Anything irreversible inside a run still stops in your Inbox for an explicit yes, and an approval left unanswered for 7 days closes the run having changed nothing.
It is not a workflow builder with branches and conditions. It is one instruction, on a cadence, carried out by the agent.

Which plans include it

Included on every plan — Starter $129/mo, Growth $349/mo, Business $699/mo.

Automations are on every plan. Creating one is free; every run is metered agent work. What differs by plan is how much there is to read: prompt slots, sampling depth and history retention.

Plan facts on this page are read from the same ladder that prices /pricing, so they cannot drift from what you are actually charged.

Read further

Documentation

Automations — cadence, run history and the idempotency key

Documentation

MCP server — the five automation tools, and which one costs credits

The agent

The thing carrying out the instruction, and the rules it works under.

Inbox

Where a failed 3am run and a waiting approval both surface.

Credits

Why cadence is a budget decision, not just a scheduling one.

Knowledge and skills

Attach a named skill so every weekly run comes out the same shape.

FAQ

Questions people actually ask

Answers here match the product documentation. Where the product cannot do something, this says so.

Still deciding? Compare plans or talk to us.

Standing instructions the agent carries out on a cadence

Written like a task

A run history

Idempotent by key

Manageable over MCP

What an automation is

The agent can offer one, and nothing is created until you confirm

Writing an instruction that produces comparable runs

Cadence, and what actually bounds freshness

Runs, run history and what a boring run means

Idempotency: the reason a retry is safe

A real weekly instruction

What it does not do

Which plans include it

Read further

Questions people actually ask

How often should an automation run?

What happens if my script retries a run?

Does creating an automation cost credits?

What happens when a scheduled run fails?

Can an automation publish something without asking me?

Can I manage automations from my own tooling?

What an automation is

The agent can offer one, and nothing is created until you confirm

Writing an instruction that produces comparable runs

Cadence, and what actually bounds freshness

Runs, run history and what a boring run means

Idempotency: the reason a retry is safe

A real weekly instruction

What it does not do

Which plans include it

Read further

Questions people actually ask

How often should an automation run?

What happens if my script retries a run?

Does creating an automation cost credits?

What happens when a scheduled run fails?

Can an automation publish something without asking me?

Can I manage automations from my own tooling?