Skip to main content

​
What is an automation?

An automation is an instruction you write once and the agent carries out on a schedule. 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 cadence 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.

​
Writing the instruction

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 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.
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 and Business. 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.

​
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. 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.

​
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:
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.

​
Managing automations over MCP

The MCP server exposes list_automations, get_automation, create_automation, run_automation, and delete_automation. delete_automation is marked destructive and removes the automation; run_automation is the only one of the five that costs credits. No tool takes a workspace id. The API key you authenticate with names the workspace.