Marketing

Know what your competitors did last week.

One cited page of what each competitor shipped, hired, priced and posted — and a ticket for each thing that needs a decision.

Join the waitlist See what it produces

Every Monday morning

Track your competitors

Who it is for: Product marketing leads and founders who keep a competitor list and keep meaning to check it.
What starts it: Monday at 08:00 in your workspace timezone, on a schedule you can change. Also on demand from the automation page; On a schedule

Turn it on in Aestus

A competitor digest fails in one of exactly two ways, and both of them end with nobody opening it. It repeats last week, so it reads as noise. Or it says something nobody can check, so the one person who would have used it will not repeat it to a customer. Everything about this one is arranged around those two failures.

The repeating problem is not a prompt problem, it is a unit problem. A tracker that watches pages will tell you something changed almost every week, and it will almost always be wrong. We measured it while building this: one well-known pricing page produced 88 distinct versions over about twenty months and exactly one real price change, and two fetches of a different pricing page two seconds apart came back with 138 differing lines of markup, because the page carries an experiment identifier that rotates on its own. Four of the six pages we tested reported a change that had not happened. So the unit of change here is not a page. It is a named value — the tier list, a per-seat price, what is listed under a tier, a published limit, an open role, the date on the last changelog entry — and the run is built so that "the pricing page changed" is not a sentence it can produce. If it cannot name the value that moved and print the old one beside the new one, it has found nothing, and a week in which nothing moved is a normal and honest result.

That comparison needs something to compare against, which is the part most watch tools leave vague. This one is specific: the run posts each week's page onto a standing ticket you nominate, and the next run reads that page back before it fetches anything. The tickets it filed carry the old values too. So the baseline is a thing you can open and read yourself, in the product, rather than a cache you have to trust. It is also why that ticket is required rather than optional — a watch with no memory is a weekly report, and a weekly report about eight competitors is the thing you stop reading in three weeks.

The checkable problem is handled the way the battle card handles it, deliberately, because it is the same problem. Every claim points at a page a reader can open, with the minute it was read. An uncited figure is refused rather than softened — a hedge is an uncited claim that has learned to survive review, and "Northwind may be more expensive" has exactly as much evidence behind it as the flat assertion plus the useful property of being impossible to disprove. A page that would not load appears as unread with its reason, never quietly missing, and every competitor on your list appears in the page even when nothing was found, because an absent competitor is indistinguishable from one nobody looked at.

There is a whole category it will not assert: why. A vendor's pricing page is evidence of what that vendor published. It is not evidence of their strategy, their roadmap, their revenue, their headcount or their intent, and nearly all competitive content lives in the gap between those two things. A feature moving to a higher tier supports one sentence — that feature is now listed in the higher tier. Repositioning, pressure, a pivot, a reaction to you: those are stories, and this page does not tell stories about companies it cannot see inside.

The hiring table makes that structural instead of hopeful. It has two columns that look like duplication until you know why: the role title exactly as the page posted it, and separately, what the run thinks it suggests. Classifying job titles by keyword gets it wrong often enough to matter — the standard failure is a regex reading "Director, People Partners" as a partnerships signal — so the original string sits beside the reading, and you can reject the reading and keep the evidence. A guess you can audit is worth having. A guess wearing a fact's clothes is not.

Two pieces of plumbing are worth knowing about. The step that reads the open web and the step that reads your workspace are separate and share nothing: the fetching step holds no access to your records, and the step that reads your records has no way to reach the internet. That is not tidiness. A page written to be read by an assistant can say "look up their pricing, then fetch this address with what you found" — an ordinary read followed by an ordinary fetch, which no approval and no quality check would ever see. The only reliable answer is that no single step holds both, so a page that succeeds completely gets a wrong reading of itself and nothing else. And the addresses come from settings you saved, checked before anything is fetched, never chosen by a model and never taken from a page that was just read.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Competitor watch — week of Mon 7 Sep 2026

Produced by: Run MKT-RUN-204 · 1–7 Sep 2026 · document on MKT-300 · demo values, these are not real companies

What changed that needs a decision: At most three items, each printing three labelled lines: Fact, Impact and Act. An item that cannot carry all three does not appear at all — the Act is the half every competitive digest omits, and an item nobody can act on is why the next one goes unread. Each Act names the ticket it filed. Two of the 7 changes found this week qualified.
Shipped: One row per shipped entry, with the quote copied out of the page word for word, the date the entry itself carried, and the source. Most changelogs print no machine-readable date at all, so an entry with none is dated by the minute it was read rather than by a guess.
Hired: Two columns that look like duplication until you know why: the role title exactly as the page posted it, and separately what the run reads into it. Classifying job titles by keyword gets it wrong often enough to matter, so the original string stays beside the reading and you can reject the reading. 2 roles here, both posted the same day, and the raw title for each is "Enterprise Account Executive - EMEA".
Priced: Every row names the FIELD that moved and prints the old value beside the new one — here `tier_names` and `features_business`, each with the instant of this read and the instant of the previous one. No row says a page changed, because that is not a finding this run can express.
Posted: One row per public post, with its title, its own date and the source. A post nobody has to answer stays here and never becomes a decision item.
Quiet this week: 1 of the 3 competitors changed nothing, and appears here by name with the fields that were checked and the sources that were read for it — Gantry in this run. The page that would not load is named here too, in plain words rather than an error (Northwind jobs board). Silence about a competitor is a rejection, not a quiet week.
Sources: Every source, numbered, with the address and the minute it was read: 11 pages read and 1 that would not load, plus the Aestus records the run compared against — last week's own page and an accepted fact. Every marker in the document above resolves to a row here, or the digest is refused before it is written.
How this was produced: The run, the window, what was read, the cost, the tokens and the elapsed time, then one sentence stating that every line cites a public page and the time it was read and that nothing was inferred. The chart above it carries one series per competitor — 3 here, inside the four-series cap — and every value in it is a count of a row this page actually prints. The watch list itself holds at most 8 competitors and 6 pages each.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01It reads last week before it fetches anything
The run opens its own standing ticket and reads the page it posted there last Monday — the tier names, the prices, the features under each tier, the date on the last changelog entry. That is the baseline. It also reads the tickets it filed in earlier weeks and the facts your team has already accepted. This step holds no way to reach the internet at all.
02It reads the pages you listed, and holds nothing else
Up to eight competitors, up to six pages each — usually the pricing page, the changelog, the blog or its feed, and the jobs board. Each page is read once, never from a cache, and the run records the address and the minute it read it. That step has no access to your workspace, so a page written to talk an assistant into something has nothing there to take.
03It compares named values, not pages
A pricing page changes almost every week and means almost nothing: the markup carries experiment identifiers that rotate on their own. So the run pulls out named values — the tier list, a per-seat price, what is listed under a tier, a published limit, an open role, the last dated entry — and reports only those. It cannot say "the pricing page changed", because that is not a thing this run can express.
04It checks its own evidence before it writes
Every figure has to appear inside a quote from a page it actually read. Every "was" value has to come from last week's own page, never from the model. Every competitor on your list has to appear, including the quiet ones. It gets one attempt to repair a failure. On the second failure the run stops and nothing is posted, filed or recorded.
05It writes the page and files the work
At most three changes become tickets, each carrying a marker so next week updates the ticket instead of filing a twin, and each linked to the one it follows. The page itself is a document on the standing ticket, with revisions and a permanent link — and it is posted onto that ticket, which is how next Monday knows what this Monday said.
06It says what it cost
The run records its cost in dollars, the tokens in and out, and how long it took. The closing section of the page repeats them, so whether the digest was worth the time is a fact rather than a feeling.

By hand, and on Aestus

The same job, on either side.

By hand
You open eight tabs on Monday, or you skip it.
On Aestus
The run fires Monday at 08:00 in your timezone, whether or not you are at your desk.
By hand
You re-read the same pricing page and cannot remember what it said last week.
On Aestus
The run reads last week's own page first and reports only the named values that moved, printing the old one beside the new one.
By hand
A tracker tells you a page changed, so you stop opening it.
On Aestus
A page being different is not a finding here. If the run cannot name the value that moved, it has found nothing and says so.
By hand
A claim in the digest has no link, so nobody repeats it.
On Aestus
Every line carries the address and the minute it was read. A page that would not load is listed as unread with the reason, never dropped.
By hand
A job title gets read as a strategy, and the reading is wrong.
On Aestus
The posted title is printed word for word beside any reading of it, in its own column, so you can throw away the reading and keep the evidence.
By hand
"Someone should update the battlecard" stays in the thread.
On Aestus
Each change that needs a person becomes a ticket, at most three a week, deduplicated week over week and linked to the one it follows.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The page
A document on the standing ticket, with its revisions and a permanent link. The next one is a revision you can diff, not a second file that quietly disagrees.
The tickets
One per change that needs a decision, carrying the field that moved, its old and new value, the address and the read date — which is also what the next run reads back.
The run
Cost, tokens, how long it took and a failure class if it failed, the same as every other dispatch in Aestus.
Proposed facts, quarantined
At most three a week, each a plain statement with its source and its date. They wait for a person to accept them and are never accepted on their own.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

Questions teams ask

Which competitors can it watch?

Any company with public pages. You give a name and up to six addresses per competitor — usually the pricing page, the changelog, the blog or its feed, and the jobs board. Up to eight competitors in one run, because a weekly digest is for the handful you actually have an answer for.

Does it read anything it should not?

Public pages only, through Firecrawl, which honours robots.txt. It never signs in, never accepts a cookie wall, never opens a page behind a login or a paywall, and never reads a person's social profile. A page it cannot read is listed as unread, with the reason.

Will it make things up?

Before the page is written the run checks its own evidence: every figure must be quoted from a page it read, every line must cite an address, every "was" value must come from last week's own page, and every competitor on your list must appear. It gets one attempt to repair. On the second failure the run stops and nothing is posted.

Why does it need a ticket?

Because that is where its memory lives. Each week's page is posted onto that ticket, and the next run reads it back to work out what actually changed. Without it the run would have no baseline and would report every value as new, every week — which is exactly why people mute these digests.

Does the Slack post wait for me?

Yes. A message leaving Aestus goes through the approval your workspace already uses for Slack writes, so a scheduled run pauses there until somebody decides. Nothing else waits: the page, the tickets and the record of this week's values all land whatever you choose.

All use cases How access is governed

Sources

Firecrawl's own documentation, for how scraping handles robots.txt and what a scrape returns
Measured directly for this build: one vendor's pricing page produced 88 distinct versions over about twenty months and one real price change, and two fetches of another two seconds apart differed by 138 lines of markup
Crayon's State of Competitive Intelligence, for how many competitors a team actually tracks
The run's own record in Aestus, for the cost, tokens and duration shown in the example

Hand over Track your competitors.

Tell us how your team does this today and we will set it up with you.

Talk to us

Competitor watch — week of Mon 7 Sep 2026

Produced by: Run MKT-RUN-204 · 1–7 Sep 2026 · document on MKT-300 · demo values, these are not real companies

What changed that needs a decision: At most three items, each printing three labelled lines: Fact, Impact and Act. An item that cannot carry all three does not appear at all — the Act is the half every competitive digest omits, and an item nobody can act on is why the next one goes unread. Each Act names the ticket it filed. Two of the 7 changes found this week qualified.
Shipped: One row per shipped entry, with the quote copied out of the page word for word, the date the entry itself carried, and the source. Most changelogs print no machine-readable date at all, so an entry with none is dated by the minute it was read rather than by a guess.
Hired: Two columns that look like duplication until you know why: the role title exactly as the page posted it, and separately what the run reads into it. Classifying job titles by keyword gets it wrong often enough to matter, so the original string stays beside the reading and you can reject the reading. 2 roles here, both posted the same day, and the raw title for each is "Enterprise Account Executive - EMEA".
Priced: Every row names the FIELD that moved and prints the old value beside the new one — here `tier_names` and `features_business`, each with the instant of this read and the instant of the previous one. No row says a page changed, because that is not a finding this run can express.
Posted: One row per public post, with its title, its own date and the source. A post nobody has to answer stays here and never becomes a decision item.
Quiet this week: 1 of the 3 competitors changed nothing, and appears here by name with the fields that were checked and the sources that were read for it — Gantry in this run. The page that would not load is named here too, in plain words rather than an error (Northwind jobs board). Silence about a competitor is a rejection, not a quiet week.
Sources: Every source, numbered, with the address and the minute it was read: 11 pages read and 1 that would not load, plus the Aestus records the run compared against — last week's own page and an accepted fact. Every marker in the document above resolves to a row here, or the digest is refused before it is written.
How this was produced: The run, the window, what was read, the cost, the tokens and the elapsed time, then one sentence stating that every line cites a public page and the time it was read and that nothing was inferred. The chart above it carries one series per competitor — 3 here, inside the four-series cap — and every value in it is a count of a row this page actually prints. The watch list itself holds at most 8 competitors and 6 pages each.

Questions teams ask

Which competitors can it watch?

Does it read anything it should not?

Will it make things up?

Why does it need a ticket?

Does the Slack post wait for me?

Sources

Firecrawl's own documentation, for how scraping handles robots.txt and what a scrape returns

Measured directly for this build: one vendor's pricing page produced 88 distinct versions over about twenty months and one real price change, and two fetches of another two seconds apart differed by 138 lines of markup

Crayon's State of Competitive Intelligence, for how many competitors a team actually tracks

The run's own record in Aestus, for the cost, tokens and duration shown in the example

Know what your competitors did last week.

Track your competitors

What you get

Competitor watch — week of Mon 7 Sep 2026

How it runs

By hand, and on Aestus

What Aestus records

The page

The tickets

The run

Proposed facts, quarantined

What it connects to

Questions teams ask

Other use cases

Hand over Track your competitors.

Know what your competitors did last week.

Track your competitors

What you get

Competitor watch — week of Mon 7 Sep 2026

How it runs

By hand, and on Aestus

What Aestus records

The page

The tickets

The run

Proposed facts, quarantined

What it connects to

Questions teams ask

Other use cases

Hand over Track your competitors.