Skip to main content

​
What is an automation?

An automation is an instruction you write once and the agent carries out on a schedule, or when something happens. It 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 trigger so you stop having to ask. Each execution is a run. Runs are stored, so an automation accumulates a history you can read back and compare. Every workspace has one automation from the start: the Daily win plan, which does up to three pieces of work toward your prompts every morning. See The autopilot loop.

​
Re-plans when a goal falls behind

When a goal falls behind its pace line, the agents can run the Daily win plan once more, focused on that goal. That run is a re-plan: it plans at most three pieces of work toward the goal and files them under your approval mode, like any other work. It is not an automation you create or pause; it comes from the 05:00 goal check. It happens at most once per goal per week. The run says why it started: Because “your goal” is behind pace. In Ask mode nothing starts, and a row in Work offers the re-plan instead. See Goal re-plans for when the check fires.

​
Creating one

The Automations page has one New automation button, which opens a dialog. Five starter cards open the same dialog pre-filled: A starter you already use shows Running or Paused and links to your automation instead. Other built-in templates include the Monthly client report, the Quarterly client review and Write the quarter in review; see Client reports.

​
When it runs

The trigger picker offers Every day, Every week, On a change and When I ask. Monthly and quarterly schedules come with the client-report templates; a missed monthly or quarterly fire catches up later in the same period. Once is no longer offered for new automations; existing run-once automations keep it, and one that has run shows as Finished. Over MCP and the REST API, trigger takes daily, weekly, event, manual or once. The default trigger setting under Settings → Autopilot does not offer On a change. Times are in the automation’s time zone. Created over MCP or the API with no time zone, an automation uses the workspace’s zone (UTC only if the workspace has none), and with no trigger it runs daily at 09:00.

​
The agent can offer one

You do not have to build an automation from scratch. When you ask the agent for something recurring in a chat — “check this every week”, “let me know when this slips” — or when it judges that an answer it just gave is only useful if somebody re-reads it later, it will offer to save the work as an automation: 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 is created 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. A chat cannot propose an On a change automation. Create those from the Automations page, the API or MCP.

​
Writing the instruction

Write it as a task, not a topic. “Weekly visibility” gives the agent nothing to do; “compare share of voice for the Pricing topic against the previous 7 days, list every prompt whose change was significant, and say which were not measured” tells it exactly what to produce and how to handle gaps. Be explicit about the window, the scope, and the shape of the output you want. The agent reads your workspace’s Prompts, Topics, Models, Answers, and citations — the same data as a chat, under the same rules. Null still means not measured, and a delta below the 95% threshold still means no change we can prove, not zero. Whatever the automation writes outward from the workspace — publishing, sending, spending — is still governed by your workspace’s approval mode, the same as a chat. An automation in a project runs under the stricter of the workspace’s mode and the project’s.
Pin the automation’s window to the cadence. A weekly automation that reads the last 7 days produces comparable runs; one that reads “recently” does not.

​
Cadence, and what actually bounds freshness

The cadence sets how often the automation runs. Set it against how fast the underlying data can change, which 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, Business and Agency. Running an automation more often than the data is refreshed produces repeated runs over the same measurements and spends credits doing it.
An hourly automation over daily-sampled data is a recurring bill for the same answer. Match the cadence to the sampling, not to your reporting habit.

​
The automations list

Each row shows:
  • Last result: the newest run’s summary, its failure reason, or “Waiting on your approval”.
  • Prompts moved: the tracked prompts the automation’s runs worked on in the window, shown as “N worked on”, or an em dash when the runs have not reported what they touched. Whether an answer actually moved is confirmed on the prompt after its next reading and its re-reads, never inferred here.
  • Next run: the next scheduled time. Event automations show “On the next change”.
Runs, credits and failures are on each automation’s own page. Paused and finished automations are listed too; filter for them with Paused and Finished.

​
The automation page

The Configuration tab uses plain labels: What it does (the instruction), When it runs (the trigger, and the event types for an event automation), Speed (how soon a run starts once it is due; we pick the models and tools), What it can look at and What it can change (its tool groups), How much it does alone (the workspace’s approval mode), and Monthly spending limit. For an automation in a project, Instructions takes the place of What it does at the top and shows the instruction word for word, because it is the crew’s standing work and is written to be read and edited. How much it does alone then says it is the stricter of the workspace’s setting and the project’s. Outcomes are read at topic level, and the summary row is labelled All models.

​
Automations in a project

A project’s crew does its standing work through ordinary automations. Each one belongs to one project, for good, and carries an author:
  • By Attensira: created when the project was set up, one for each thing that wakes a crew member. The project’s Chief of staff may change these when you steer the project, and every change it makes is posted to the feed as Plan updated.
  • By you: written by a person. The Chief of staff never changes one of these on its own; it proposes the change and you confirm it.
Either kind is yours to edit, test, switch off or delete. The workspace’s Automations page lists every automation; once the workspace has a project, a Project column says which project each belongs to, and a project’s automation opens inside its project. A project’s automations do not run while the project is paused or archived, or once the project has reached its monthly cap.

​
Testing an automation

Test on the automation’s page runs it once, now, so you can see what it does before you rely on it. A test is a real run: it does the work, it is paid for like any other run, and it meets the same approval mode and caps. What a test does not do is count as the automation having run. Test runs don’t count as this week’s run:
  • the schedule is untouched, so a test this morning does not stop today’s scheduled run;
  • a run-once automation is not used up by a test;
  • a test works on an automation that is switched off, so you can try it before turning it on. A run-once automation that has already run is finished and cannot be tested.
Test runs are marked Test in the run history, and their Because line says they were started as a test. Over MCP and the REST API there is no test mode: run_automation and POST /v1/automations/{id}/runs start an ordinary run.

​
Runs and run history

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. Replay on a run opens it watched back step by step. Run history is also where you look when an automation seems to have stopped saying anything interesting. A run that reports no significant change is doing its job — it is telling you the movement was below the noise floor.

​
Why a run started: “Because…”

Every run of an automation, and every run a finding starts, carries one sentence saying why it started, beginning Because. It shows at the top of the run’s replay and, for a run in a project, on its post in the project’s feed. The sentence is built from facts we recorded: the automation’s schedule, in its own time zone, or the event that woke it. It is never a model’s summary. For an event run it names the oldest event in the batch and counts the rest. It never quotes what a competitor’s page said; that goes to the run as material to read.

​
When a run does not happen

A scheduled run that did not happen is not silent. A paused, retired or manual automation, a run skipped for credits, and a run still waiting on your answer each show up in loop health with the reason. So does an automation whose project is paused or archived (work_area_inactive) or has reached its monthly cap (work_area_cap). An event automation can also skip a competitor’s change as not worth a run. Before a competitor’s page change wakes the automation, a decision asks whether the change is worth a run of this automation, given its instruction, its project’s direction and its recent runs. A confident no closes that event as skipped, with the reason “not worth a run:” and the event, and the other events in the batch still fire. When every event in a batch is skipped, nothing runs, and loop health records the skip as not_worth_run. A skip starts no run, so it spends no credits and does not count toward the automation’s three event runs in 24 hours. Every other kind of event wakes the automation as before, and so does a competitor’s change when no decision can be made. If a scheduled run needs an integration that the automation’s tool list does not include, nothing is added to your Inbox, because connecting the integration would not help that run. It is recorded on the run’s transcript instead. To fix it, add the tool to the automation.

​
Runs cost credits — and the idempotency key

A run spends Credits, because it runs a model and the tools it needs. Scheduled runs and manual runs cost the same. Credits are the workspace’s unit of metered agent work; creating the automation is free, executing it is not. 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. This 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, which is sent upstream as the Idempotency-Key header:
MCP
Over the REST API you send the header directly:
REST
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.

​
When the credits run out

With a spent credit balance, scheduled automations do not run, and nothing is charged for runs that did not start. The workspace gets one Inbox row and one email until it is topped up; see Credits. A workspace’s monthly credit cap pauses scheduled runs the same way; see Monthly credit cap. A project’s own monthly cap pauses that project’s runs; see Project monthly cap.

​
Managing automations over MCP

The MCP server exposes list_automations, get_automation, create_automation, update_automation, run_automation, and delete_automation. delete_automation is marked destructive and removes the automation; its past runs are kept as sessions. run_automation is the only one that costs credits. list_automations and get_automation always include paused and retired automations. When the product paused one on its own, it carries retired_reason and retired_at. No tool takes a workspace id. The API key you authenticate with names the workspace.