A competitive intelligence pipeline where every claim has a source

Most competitive intelligence efforts start with a burst of energy and a shared folder, and end a few months later as a channel full of links nobody reads. The problem is rarely a lack of information. It is that nobody decided which questions matter, where the answers live, how often to look, or who checks a claim before it reaches a sales deck. Agents make the collection part cheap. That makes the other parts more important, not less. This guide describes a workflow for running competitive intelligence continuously with agents, and the components you need if you are building it as an internal platform.

Start from the questions people keep asking

A competitive intelligence program is a set of standing questions with owners and audiences. Write them down before choosing any tool. A good standing question is specific enough that you could tell whether its answer changed:

• Has any tracked competitor changed its pricing, packaging or free tier?
• What did each competitor ship this month, and does any of it close a gap we sell against?
• Are competitors hiring in regions or functions that signal a new market?
• Which segments do their customer pages, webinars and job ads target now?
• Have their terms, security pages or data handling statements changed in ways buyers will ask about?

For each question, name who consumes the answer (sales, product, leadership) and what they do with it. A question with no consumer is a candidate for deletion. A question with an urgent consumer, such as a sales team losing deals on price, deserves a faster cadence.

Map sources to questions

Each question has a handful of places where its answer first appears. Mapping them explicitly keeps agents from wandering across the whole web and makes it obvious when a source goes quiet.

Two rules keep collection on the right side of the line. Respect each site's terms and robots rules, and never treat a login wall as something to get around: if a page needs an account, it needs a decision about whether you may use one. Collection itself can use search APIs, scrapers or feeds; the guide to choosing a scraping API covers the trade-offs.

Set a cadence per signal, and a baseline first

Checking everything daily produces noise; checking everything quarterly misses the moments that matter. Match frequency to how fast each answer changes and how costly it is to learn late.

• Frequent: pricing pages and changelogs of the few competitors you meet in most deals.
• Weekly: careers pages, documentation, newsrooms.
• Monthly: positioning pages, terms and policies, the long tail of smaller competitors.
• Quarterly: a deliberate deep dive per major competitor, run as a separate piece of work.

Before the first scheduled run, capture a baseline: the current state of every source, reviewed once by a person. Without it, the first run reports everything as new and the team learns to ignore alerts in week one. Set a baseline before you monitor explains why. For the product-change slice specifically, see competitor product change alerts.

Turn changes into claims with evidence attached

A detected change is raw material. What people consume is a claim: “Competitor B removed its free plan.” Every claim should travel with the evidence that supports it, in a shape a reviewer can check quickly.

claim:        Competitor B no longer offers a free plan
competitor:   Competitor B
question:     pricing and packaging
type:         observed            # observed | inferred
source:       https://competitor-b.example/pricing
retrieved:    YYYY-MM-DD
evidence:     "Plans start with Team. Contact us for a trial."
previous:     "Free: up to 3 users, forever."  (baseline YYYY-MM-DD)
so_what:      expect more trials of our free tier from their small accounts
confidence:   high for the change, low for the so_what

The type field does the most work. An observation (“the pricing page no longer lists a free plan”) can be checked against a page. An inference (“they are moving upmarket”) is an opinion built on observations, and should say which ones. Keeping them apart is what stops a speculative line in an agent's summary from turning into a fact on a battlecard. When the agent looked and found nothing, that is recorded too, as an open question rather than a silent gap; see missing evidence is an open question.

Review before anything is distributed

Competitive claims travel fast and far. A wrong price on a battlecard costs credibility in front of a buyer; an unfair characterization of a competitor can become a legal problem. So distribution is the step where a person decides, not the agent.

1. Claims accumulate in a review queue, grouped by competitor and question.
2. A reviewer checks each claim against its evidence, edits the wording, downgrades weak inferences, or rejects it with a reason.
3. Only accepted claims flow into digests, battlecards and briefings, each still linked to its source.
4. Rejections are kept, so the same false alarm does not come back next week.

GoCux is built around this shape of work. Pulse runs a recurring question over the sources you pick. Before it runs, its definition, including cadence, timezone, what counts as a material change and whether anyone gets an email, is approved as one exact version. Every run then comes back as a set of changes that a person reviews one by one, and nothing a run detects acts on its own. Sending something out of the workspace is one of the actions that pause for a person, who can approve it, edit it safely or reject it; a rejection is recorded and does not release the item. Review monitored changes before they travel covers the reasoning in more depth.

If you are building it as a platform

Teams that outgrow spreadsheets often build an internal platform. Whatever you build or buy, the same components show up:

Agents fit into collection, change description and first-draft claims. They should not own acceptance or distribution. If you are weighing build against buy for the search layer, a research and monitoring stack lays out the building blocks.

Keep the program honest

A competitive intelligence program decays quietly. Every so often, ask each consumer what they used and what they ignored, then prune. Retire questions nobody acts on. Drop sources that produce only false alarms, and add the ones that would have caught the last surprise. Read a sample of rejected claims: a cluster of rejections from one source or one type of inference shows where the agent's instructions need tightening. And keep deep dives separate from the stream; a structured one-off study like the one described in competitor analysis with AI agents answers different questions than daily monitoring does.

Launch checklist

• Standing questions are written down, each with an owner and a consumer.
• Every question has mapped sources, and each source has a cadence.
• A reviewed baseline exists before the first scheduled run.
• Claims carry source, retrieval date, quoted evidence and a type: observed or inferred.
• Searches that found nothing are recorded as open questions.
• Nothing reaches a digest, battlecard or briefing until a person accepts it.
• Rejections are logged with a reason and feed back into instructions and sources.
• Collection respects site terms and never works around a login.