Competitor Monitoring

How change detection works

Most pages worth watching carry no publish date, so recency cannot do the filtering. Each competitor record therefore holds a last_snapshot: the facts the workflow recorded last run. A pricing page is compared field by field against it, and a plan moving from $19 to $29 is a reportable change. Dated changelogs skip the comparison and use their dates instead.

Two consequences worth knowing:

1. The first run reports "baseline recorded" rather than changes. There is nothing to compare against yet, and claiming otherwise would be a guess.
2. The snapshot only advances after the brief is written. If the brief step fails, the old snapshot stays, so next week still catches the change instead of silently swallowing it.

The example rows

Both are placeholders: replace them with your own competitors. The one requirement is that the page renders in plain HTML, because fetch_url does not execute JavaScript. Several well-known changelogs are client-rendered and return an empty page, so check that a new row returns real content on its first run.

What keeps it honest

• A page that fails to fetch is reported as failed. The agent is told never to substitute what it already knows about a company for a page it could not read.
• Every reported change carries the wording on the page that shows it, so a claim can be checked without refetching.
• Competitors that were checked and did not move are named, so a short brief cannot be confused with a brief that skipped the work.
• Every brief is created as a draft, and the workflow never publishes.

Step 1 prompt

Check each competitor page and report what changed since the last run. Do not write the brief and do not create any objects in this step.

Scope for this run:
1. Read the competitor-watch type and take every object where active is true. Each one gives you a watch_url, a what_matters describing which facts to track, and a last_snapshot holding what you recorded last time.
2. Fetch each active page with fetch_url. Read only the page you were given. Do not follow links to other pages: the record names the page that matters, and wandering makes the run unbounded.
3. Decide what changed, using whichever of these the page supports:
   - When the page carries dates, treat entries from the last {{lookback_days}} days as new.
   - When it does not, compare what you see against last_snapshot field by field. A plan that went from $19 to $29, a tier that gained a limit, a headline claim that was reworded: those are changes.
   - When last_snapshot is empty, there is no baseline yet. Record the current facts as the baseline and report this page as "baseline recorded", not as a change. Saying a competitor changed on the first run would be a guess.
4. Keep at most {{max_changes}} changes across all competitors. When there are more, keep the ones that affect positioning, pricing, or what a customer can do.
5. If a page errors, returns almost no text, or clearly needs JavaScript, record it as failed and move on. Never fill the gap with what you already know about that company. An unread page contributes nothing to this brief.

Return a single JSON array and nothing else before it. One entry per competitor you fetched:
{ "competitor", "slug", "url", "status", "changes", "snapshot" }

- status is "changed", "unchanged", "baseline recorded", or "failed".
- changes is an array of { what_changed, from, to, evidence }. Leave it empty unless status is "changed". from and to are what the page said before and now; use null for from when the page carries dates rather than a comparable value. evidence is the wording on the page that shows it, not your paraphrase.
- snapshot is the current facts for this page in the same shape you would want to compare against next week: plan names and prices for a pricing page, the newest dated entries for a changelog. Keep it compact, since it is stored and read back every run.

Finally, set last_checked to today on each competitor-watch object you fetched successfully. Leave last_snapshot alone: the next step advances it once the change has actually been written down.

Step 2 prompt

Write this week's competitor brief from the previous step, save it as a draft, then advance each snapshot.

Scope for this run:
1. Work only from the JSON you were handed. You did not read the pages in this step, so the facts available to you are the changes and evidence recorded there.
2. Write the brief:
   - Open with two or three sentences on the through-line. If the week was quiet, say so plainly rather than inflating a wording tweak into a strategy shift.
   - One short section per competitor that changed: what moved, the before and after, and a link to the page. Two to four sentences each.
   - Where a change has an obvious implication for your own pricing, positioning, or roadmap, say it in one sentence. Do not manufacture an implication for every item.
   - Close with one takeaway sentence.
3. Name competitors that were checked and did not move in a single closing line. A brief that only lists movement leaves the reader unsure whether the rest was even looked at.
4. Create exactly one object in the competitor-briefs type with status draft:
   - title: "Competitor Brief: <Month D, YYYY>"
   - brief_date: today
   - content: the body as HTML, using h3 subheads, paragraphs, and inline links
   - takeaway: the closing sentence on its own
   - change_count: how many changes you reported
   - competitors_checked: JSON array of { competitor, status } for every competitor from the previous step, failures included
5. Only after the brief exists, write the snapshot from the previous step onto each competitor-watch object whose status was "changed" or "baseline recorded". Change nothing else on those objects.

Step 5 is last on purpose. The snapshot is the memory of what you have already reported, so advancing it before the brief is written would lose the change if this step failed: the page would look unchanged next week and nobody would ever hear about it.

Leave the brief as a draft. Whether this goes to the team, and with what framing, is a human call.