AI Agent Prompts for Competitor Monitoring

Work somebody reviews fails loudly. They read the output, something looks wrong, they ask. Work that runs on a schedule has none of that, and the failure mode changes shape completely.

The dangerous case is not a wrong answer. It is a report that arrives on time, reads normally, and was built on an input that stopped carrying anything three weeks ago. Nobody investigates a quiet report, because a quiet report is exactly what a quiet week produces.

So the most important instruction in a recurring brief is not about analysis. It is: tell me what you read. Not what you found, what you read, one line per input, every single run. Four lines nobody looks at until the week one of them changes. How long a broken input goes unnoticed is also measurable: time to insight lengthens quietly when the collecting half has stopped.

A model begins every run knowing nothing about the last one. There is no continuity to draw on, so “what changed” is only answerable if the earlier state is handed over as text. The agent has to write that text itself, at the end of each run, for a reader that is only ever the next run.

Which makes it the one output nobody ever looks at and everything depends on. And it is usually written in the wrong form. The natural thing to record is a summary of the run, and a summary is exactly what destroys the next comparison.

Carry forward what an input stopped telling you

When an input comes back empty, the baseline for it should not be overwritten and should not be deleted. Carry the last known values forward, stamped with the date they were captured.

That one rule is what lets a later run say something useful: this figure was last seen on 1 September, and the input carrying it has been empty for three weeks. Without it, an input that breaks quietly erases its own history on the first run after it breaks. Pricing is the input where that hurts most, because competitor pricing changes in weeks and a lost baseline cannot be reconstructed from the live page.

Three inputs, and the middle one is the agent’s memory. The third is the one teams leave as a sentence about judgement, which is the one thing a scheduled job cannot apply consistently.

List the inputs in a fixed order and keep that order. It sounds like housekeeping. It is what lets somebody skimming the fourth report in a row notice that the fourth line has stopped appearing. That register is the whole difference between competitor tracking and a weekly email that happens to arrive.

Four blocks, and only the first is the brief. The other three are additions to it, and each one exists because of something that goes wrong when nobody is in the conversation.

Notice what the register forbids rather than what it requires. Writing “no changes” about an input that carried nothing is the specific sentence being banned, and banning a sentence works where asking for care does not.

The fourth block is the two-state problem that every comparison job has. Two saved copies of one page differ in far more ways than anybody expects, and only one kind of difference is news. A pricing page diff turns on sorting those kinds apart before anything gets reported.

We ran a scheduled brief against three connected inputs and a baseline recorded three weeks earlier. One input was a real developer changelog. One was a job board export. One was a saved copy of the vendor’s own pricing page, and that page is the interesting one: 74 KB of HTML containing no prices and no tier names at all.

An empty file reads exactly like an unchanged one

The first report found both real changes, dated them correctly and ranked them sensibly. Then it wrote: no pricing changes this run.

That sentence was written about a file with no prices in it. Nothing could have changed, because nothing was there. And the sentence is the most reassuring one in the report, so nobody would ever query it. A reader now believes a competitor’s pricing was checked on 24 September, and it was not.

The saved page was not doctored for this run, which is the part worth dwelling on. Plenty of real pricing pages build their tables after the page loads, so a saved copy is a large, complete-looking file with the figures missing. An input like that never errors. It just quietly agrees with whatever the baseline said.

The second run found the broken instrument first

With the register required, two new items appeared, and neither was about the competitor. The pricing input was reported as empty, with the three figures the baseline held and the note that none of them appear in the current capture. And the job board came back with zero postings against 137 three weeks earlier.

The first run had described that as no changes in hiring. Going from 137 open roles to zero is either the most dramatic hiring news of the quarter or a broken export, and a report has to make somebody look. Anybody who has read a competitor’s job board knows which of the two it is, which is the argument for a human seeing the register. Both of these matter more than either real change: a competitor shipping a deprecation costs you one decision, and a monitoring input that stopped working costs you every decision after it.

Most briefs say something like “report what matters” or “only things that need a decision”. Both sound right and neither is a rule. They get re-interpreted on every run, so the bar moves, and two consecutive reports stop being comparable even when the world did not change.

An operable threshold names triggers instead. A figure moving. A capability crossing a tier boundary. A competitor named in a job title. A claim appearing on a homepage that was not there before. Each of those can be applied identically every week by anything, including a person.

Deduplicate on the change, not on the wording

One competitor change routinely shows up in three inputs at once: a changelog entry, an edit to a pricing page, and a press release. Three items in a report, one event in the world.

The fix is a rule about identity rather than about length, and it is the third block above. Group by the underlying change, list the inputs that showed it, and report the earliest date. The later dates are worth keeping for a second reason: they tell you which of your inputs are slow.

The same rule handles the across-runs case, which is the more common complaint. A change reported last week arrives again this week because a second input has only just caught up with it. Deduplicating on the event rather than on the wording catches both, and asking the run to say how many findings it merged is what makes the rule visible.

Everything above is about the brief, and the brief is the easy half. A scheduled run is only as good as what somebody connected to it, and the inputs are where this work actually breaks. Saved pages go stale, exports change format, a board stops returning anything.

There is no version of this where the reading solves itself from a prompt. A brief cannot connect to a source, cannot notice that a saved copy has lost its figures, and cannot tell you that an export has been empty since the first of the month. Those are properties of the plumbing rather than of the instruction.

Which is also the honest limit on what any of it delivers. An agent can tell you what changed and when it was visible. Whether it matters depends on your roadmap and your pipeline, and a competitor tracking sheet is what turns a stream of reports into something anybody can look back through.

Flares is the connected half of this. It follows competitor pricing, product, documentation and messaging, dates every change, and keeps a record of what was checked and when, so an unchanged competitor and an unchecked one never arrive as the same line. What to do about a change is still a decision somebody has to take.