# A research update that knows what changed. Reviewed: 2026-09-12 Canonical: https://clankercloud.ai/templates/recurring-research-brief Use this template to test one research-update run against a saved baseline. It separates documented changes from unchanged sources and retrieval failures, then drafts a notification only for the rule you defined. Configure a Loop or Schedule separately after reviewing the one-off result. ## What you are working toward A dated change brief, coverage register, and proposed notification text. ## Start with - A narrow topic and a dated baseline that can be revisited - Current evidence with retrieval status for every source - A material-change rule, review destination, and cost-aware run frequency ## Make the first run a controlled comparison Start in a Session with the supplied snapshots and ask for one saved result. The example has three sources and two cutoff dates. One source adds a private-preview capability, one current retrieval fails, and one remains unchanged. The expected output demonstrates the distinction before any recurring job consumes credits. A baseline is a dated record of what was observed, not a permanent truth. Keep the source references and scope beside each claim. For real research, record page title, URL, retrieval time, and the relevant content so the next run can compare like with like rather than reconstructing yesterday’s evidence from memory. ## Define material change before checking the sources The example’s notification rule flags newly documented capabilities and access-policy changes. A newly documented weekly-export private preview qualifies, but it should retain the selected-account limitation. The Agent must not summarize it as a general launch for all users. A useful rule distinguishes consequential changes from wording edits, navigation changes, and repeated announcements. Write down the threshold in the task instructions and test borderline examples. If every tiny page edit is treated as actionable, the resulting stream makes it harder to notice the changes the team actually needs to review. ## Treat missing evidence as incomplete coverage Harborlist’s current access guide was unavailable. That does not prove its access policy changed, disappeared, or remained the same. Keep the baseline statement as historical context and mark the current check incomplete. Report that only two of three current sources supplied usable content. A failure rule can specify when to retry or when to alert a reviewer about persistent missing coverage. Keep that separate from the product-change rule. The fictional prompt asks only for a note about the failure; it does not authorize retries, alternate account access, or a real network action. ## Save a brief that supports the next review Request a change table, unchanged-source list, coverage register, and draft notification text. Each entry should cite both baseline and current source IDs when available. The unchanged Meadowdesk row matters because it proves the source was checked rather than silently omitted. Keep the previous verified baseline until the new result has been reviewed. Do not replace an available historical source with an empty error response and call that the new baseline. When the review accepts a new observation, record which source and date became the reference for the next comparison. ## Configure recurring execution only after the test works Use a Schedule for a fixed time and a Loop for work that repeats after the previous run and a delay. Select the intended Project, Agent, goal, timing, and notification behavior in Workspace. Copying this template or opening a Session does not create that worker automatically. Review the current model and usage rates before choosing the frequency. Loops use 10× model tokens, and computer usage is charged separately. Hosted workers can run in the cloud; a task that depends on a connected computer still needs that machine available. Enable unattended computer jobs only when both the task and Agent permit them. ## Check the worker history before trusting silence An absence of notifications can mean no material change, but it can also mean a failed run, inaccessible sources, or missing output. Inspect progress, job results, files, and run history. A useful recurring task records its coverage even when the notification rule says to stay quiet. Pause or stop a worker when its topic is no longer useful, its sources change, or repeated failures need attention. Before rerunning a failed job, verify whether it already saved an output or delivered any notification. Reconcile that state first so a retry does not create duplicated briefs or repeated messages. ## Sample files Fictional inputs. Download and add to your Project. - [research-snapshots.md](https://clankercloud.ai/templates/recurring-research-brief-files/research-snapshots.md): Fictional baseline/current pairs showing a preview launch, a failed retrieval, and no change. ## Try this prompt Copy into a Workspace Session. Opening Workspace does not send it automatically. ```text Run one offline research comparison from the fictional snapshots below and save research-change-brief.md in this Project. Do not browse, configure a worker, send a message, or publish. Use sections: Scope, Material changes, Unchanged sources, Coverage gaps, Proposed notification, Baseline-review actions. Cite baseline/current IDs for each comparison. Preserve preview and account restrictions. A failed current retrieval means unknown current status, not unchanged or removed. Report usable current sources out of all expected sources. Keep historical baseline evidence when current content is unavailable. Draft notification text only for the stated material-change rule and list the coverage gap separately. # Fictional recurring research packet Topic: export documentation changes for a product team. Baseline cutoff: 2026-09-08. Current cutoff: 2026-09-10. All sources below are fictional supplied snapshots, not live websites. ## B1: Cedarboard guide, baseline snapshot 2026-09-08 Manual CSV exports are available. Scheduled exports are not documented. ## C1: Cedarboard guide, current snapshot 2026-09-10 Manual CSV exports are available. A scheduled weekly export feature is in private preview for selected accounts. ## B2: Harborlist access guide, baseline snapshot 2026-09-08 Private board links require recipients to sign in. ## C2: Harborlist access guide, current snapshot 2026-09-10 Source unavailable: retrieval returned a temporary error. No page content was obtained. ## B3: Meadowdesk export guide, baseline snapshot 2026-09-08 Manual exports support CSV. ## C3: Meadowdesk export guide, current snapshot 2026-09-10 Manual exports support CSV. Notification rule for this sample: flag newly documented capability changes or access-policy changes. Record an unavailable source as incomplete coverage; do not call it a product change. Draft the notification text only. No recipients or delivery channels are authorized. ``` ## Illustrative result Fictional sample; your result depends on your inputs and needs review. ```text Fictional expected run — 2026-09-10 Material change: Cedarboard now documents scheduled weekly export in private preview for selected accounts (B1 → C1). General availability is not established. Unchanged: Meadowdesk still documents manual CSV export (B3 → C3). Coverage: 2 of 3 current sources readable. Harborlist current status unknown because C2 has no retrieved page; preserve B2 as historical evidence. Draft notification: “Cedarboard documents a selected-account preview for weekly CSV exports. Review eligibility before treating this as generally available.” Baseline review: consider C1 and C3 after review; do not replace B2 with the failed C2 retrieval. ``` ## Before using the result - The preview change preserves its selected-account limitation. - The failed source is a coverage gap, not a product change or an all-clear. - Coverage is exactly two usable current sources out of three. - The unchanged source and retained historical baseline are documented. - No worker, notification delivery, or automatic baseline replacement was created. ## Common questions ### Should I use a Loop or a Schedule? Use a Loop for work that repeats after the previous run and a delay. Use a Schedule for work at set times. Test the task in a Session first, then choose its Project, Agent, goal, timing, and notification rule. [Read more in the FAQ](https://clankercloud.ai/faq#loops-schedules) ### Can it work while my laptop is closed? Hosted Loops and Schedules can run recurring work in the cloud. Tasks using a connected computer still need that computer to be online and available. Simply starting a browser conversation does not turn it into a recurring background task. [Read more in the FAQ](https://clankercloud.ai/faq#background-work) ### Can recurring work run scripts while I am away? Allow computer jobs lets a Loop or Schedule run scripts and commands while your browser is closed. Its Agent must permit unattended work; Answer only, Research, and Always ask Agents cannot run unattended computer jobs. Review progress and job results in the worker history. [Read more in the FAQ](https://clankercloud.ai/faq#unattended) ## Sources - [Workspace guide: recurring execution and costs](https://workspace.clankercloud.ai/#page=faq&tab=articles&article=loops-and-schedules) - [Workspace guide: keep research evidence](https://workspace.clankercloud.ai/#page=faq&tab=articles&article=files-and-knowledge) - [Current rates and allowances](https://clankercloud.ai/pricing) ## Related - [Test it once. Give it a rhythm.](https://clankercloud.ai/learn/loops-and-schedules) - [Check what the worker did, then decide what runs next.](https://clankercloud.ai/learn/review-recurring-worker-results) - [Check the claim. Open the source.](https://clankercloud.ai/learn/verify-ai-research) - [A competitor brief your team can challenge.](https://clankercloud.ai/templates/competitor-research-brief) [Open Workspace](https://workspace.clankercloud.ai) [Current pricing and usage](https://clankercloud.ai/pricing)