> ## 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. # The autopilot loop > Every morning the Daily win plan does up to three pieces of work toward the prompts you want to win, and event automations react when an answer or a page changes. Nothing leaves the workspace without your yes. ## What runs on its own Two kinds of [automation](/agent/automations) keep the work moving without you asking: * **The Daily win plan**, a scheduled automation every workspace has. Once a day it picks the next pieces of work that bring you closer to the prompts you track. * **Event automations**, which run when something happens to the workspace (you drop out of an answer, a competitor changes its pricing page) instead of on a clock. The built-in one is the **Event responder**. Both do the work and then wait. Every piece they produce lands in [Work](/agent/inbox) for your approval or review. The loop never posts, sends or merges on its own; what may go out unattended is set by your [approval mode](/agent/approval), and claims never do. To check that the loop is actually running, open [loop health](/agent/loop-health). ## The Daily win plan Every workspace has a **Daily win plan** automation that runs at **06:00 in the workspace's time zone**, an hour before the [morning brief](/agent/morning-brief). Each morning it reads the prompts you are losing and the ones you are winning, and does **at most three** pieces of work. Each one is one of: | Work | Where it lands | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | A GitHub pull request: a fix to a page, or a new blog post | A pull request on your connected [repository](/agent/github), opened as a draft by default | | A page rewrite suggestion | A before/after in Work, when no repository holds the page | | An article draft | Work, and a draft page in [Notion](/agent/notion) after your yes when a Notion blog is connected | | A directory listing | Work, prefilled from your business profile ([off-site](/agent/off-site)) | | A community thread reply | Work, as a draft for you to post ([community answers](/agent/community-answers)) | | An outreach draft | Work, for you to send from your own mailbox | All of it waits for your approval or review. A morning where you are winning everything you track is a legitimate outcome: the plan says so rather than inventing work. ### What it can reach The Daily win plan starts with this reach (tool groups): **Your own data**, **The open web**, **Remember what we learn**, **Your site's code on GitHub**, **Make things**, **Rewrite a passage on your site**, **Find who to contact**, **Answer questions where people already argue**, **Get listed on directories**, and **Notion**. A group whose connection you have not made yet (GitHub or Notion, say) is skipped until you connect it. You do not need to edit the automation afterwards: the next morning's run picks the new connection up. ### It replaced the Daily check-in Workspaces used to start with a **Daily check-in** automation that read the numbers each morning and reported them. The Daily win plan replaces it. Existing workspaces were given the Daily win plan once, in one of four ways: * **Created**, if the workspace had neither. * **Converted** from a Daily check-in you had never edited. Its run history is kept. * **Resumed**, if [detection](/agent/findings) had paused the old check-in. * **Added beside** a check-in you had rewritten in your own words, which is left as you wrote it. That was a one-time step. If you delete or pause the Daily win plan afterwards, it stays deleted or paused; nothing puts it back. ## Event automations An automation with the **On a change** trigger (`event` on the wire) runs when something happens instead of at a time. It listens for one or more of these events: | Event | When it fires | | --------------------- | ------------------------------------------------------------------------------------- | | `prompt_lost` | You drop out of an answer on an engine, or a rival is newly named on a prompt | | `citation_lost` | An answer stops citing a page of yours | | `new_deciding_source` | A new source starts deciding an answer (a new domain in an engine's top ten) | | `competitor_changed` | A tracked competitor changes a key page (see [Change monitoring](#change-monitoring)) | | `page_changed` | One of your own pages changes | An automation with an empty list listens for all five; over MCP and REST you name them explicitly (see [Creating one](#creating-one)). `prompt_lost`, `citation_lost` and `new_deciding_source` come from the hourly [detection](/agent/findings) pass. `page_changed` comes from detection and from the homepage monitor, and `competitor_changed` from competitor monitoring (see [Change monitoring](#change-monitoring)). An event is picked up within about **5 minutes** of being recorded. ### What an event run is given The run gets the automation's saved instruction plus the list of events that woke it. Each event is dated and described as something seen once, not as a trend: "an answer on Perplexity stopped citing /pricing on 2026-09-22", never "citations are falling". ### Limits * **One run covers up to 10 events.** More than that and the rest wait for the next run. * **At most 3 runs per automation per rolling 24 hours.** Events past that cap are recorded as skipped, with the reason, and are visible in [loop health](/agent/loop-health). * **One run at a time.** If a run of the same automation is still in progress, new events wait for it to finish. * **Events older than 48 hours are not acted on.** * **Out of credits:** the event is skipped and the reason says the balance is spent. ### Creating one Event automations cannot be proposed from a chat. Create one from the Automations page (the **Event responder** starter, or **New automation** with **On a change**), with `create_automation` over [MCP](/mcp/tools#create_automation), or with `POST /v1/automations` over the [REST API](/api/endpoints#post-v1automations). Over MCP and REST an `event` trigger needs a non-empty `event_types` list. ### The Event responder The built-in **Event responder** template (id `event-responder`) listens for all five event types and runs the same procedure as the Daily win plan, scoped to what changed. It takes **at most one action per event**: propose a fix, draft content, or raise a task. ## Change monitoring Two of the events need something to watch pages on a schedule. Attensira sets that up for you: * **Competitors.** When any automation listens for `competitor_changed`, Attensira watches up to **5** of your tracked competitors' pricing, feature and comparison or alternatives pages, once a day. * **Your homepage.** When any automation listens for `page_changed`, Attensira watches the workspace's homepage daily. Changes to navigation, the footer and cosmetic details are ignored. A detected change becomes a `competitor_changed` or `page_changed` event. Monitors are added and removed automatically as your competitors, automations and workspaces change: removing a competitor, or the last automation that listens for the event, stops the watch, and deleting a workspace stops all of its monitoring. ## Who gets this without asking Paid workspaces are enrolled in the [morning brief](/agent/morning-brief), hourly [detection](/agent/findings) and the [off-site](/agent/off-site) work streams automatically, the first time their subscription is active. New workspaces start in the **draft** [approval mode](/agent/approval): the loop does the work and waits for your yes before anything leaves the workspace.