System Prompts for Competitive Intelligence

A task prompt is written for one conversation, by the person who will read the answer. If it misfires, they see it and try again. That feedback loop is doing more work than the wording is.

A system prompt has none of it. It governs conversations you will never see, started by people who did not write it, about questions nobody anticipated, sometimes forty turns in. Nothing reports back. So the question stops being “does this produce a good answer” and becomes “what must still be true when nobody is checking”.

A twenty-rule prompt feels thorough. What it produces is an AI assistant that hedges when somebody asks for a pricing page URL. Every answer now has to clear twenty conditions, and most of them were written for cases that never arrive.

There is a cheap test for whether a rule has earned its place. Name a sentence it would have stopped. Not a category of sentence, an actual one somebody could have received. Rules that pass that test are usually about what an answer contains. Rules that fail it tend to be about what kind of thinker the model should be.

Format rules hold, judgement rules drift

“Every factual claim carries its source” is visible on every line of every answer. A breach is a claim with nothing after it, which anybody can see without knowing the rule existed.

“Be balanced” and “be rigorous” describe a disposition. Nobody can point at the sentence where they failed, so nobody ever does, and compliance drifts without anybody being able to say when. Both kinds of rule cost the same on every turn. Only one of them can be shown to be working.

Two inputs, and the second is a list most teams have never written down. It is also the one that decides which rules belong in the prompt and which ones are decoration.

Write rules against failures you have actually had. Somebody quoted a price that was two tiers off. A battlecard claimed a feature that does not exist. A brief said a competitor was moving up-market on the strength of nothing. Three real examples produce a better prompt than any amount of thinking about what could go wrong. Where the requests come from other teams, a request brief is where those failures get noticed in the first place.

Three blocks, and only the first is the prompt itself. The other two are how you find out whether it works, and they are the part almost nobody runs.

The third one is the important one and it feels perverse to run. You are asking a model to defeat your own rule while technically obeying it. That is exactly what will happen in production, thirty turns into a conversation, when somebody asks a question the rule was written for. Better to see it now.

Most teams already have the human version of these rules written down somewhere. A competitive intelligence programme charter already commits the function to what it will and will not claim. A system prompt is those same commitments, in a form a model can apply on every single answer.

The prompt above used to carry a different version of one rule. We asked it the question that rule exists for, and the answer is why the wording on this page now reads differently.

The exception clause was the hole

The original rule read: you never assert what a competitor will do next, you describe what they have done and what it would imply if continued. Two sentences. The first forbids a forecast. The second supplies a grammar for delivering one.

And that is what came back. A refusal, then a direction, then the likely next moves, all under “if that direction continues”. Nobody broke the rule. A reader taking notes writes down the forecast, because the conditional is a wrapper and not a qualification.

The general shape is worth more than this instance. A prohibition that names a permitted alternative will be satisfied by the alternative, and the alternative is often the same claim in a softer grammar. The repair was not a stronger prohibition. It was removing the alternative and saying what to do instead: give what they have done, with dates, and stop.

Two of the six ways an ungrounded answer goes wrong are best caught here rather than in any single request. Reading a competitor filing is the clearest case: a company’s stated competitive factors are evidence about where it intends to fight, and turning that into what it is building is one inference too far.

The no-disparagement rule earns its place the same way. Anything drafted under this prompt may be read aloud, so answering an objection has to survive a buyer who likes that competitor. And where the rules are holding, the thing that moves is competitive confidence: whether anybody trusts an answer enough to use it without re-checking.

A standing prompt decides how an AI assistant behaves. It cannot decide what that assistant knows. Every rule above assumes somebody has put current material in front of it, and the rules are at their most dangerous when that assumption quietly fails.

A well-written prompt refuses when the material runs out, which is the correct behaviour and is also invisible. Nobody reports a refusal, and a scheduled run makes that worse by removing the one person who might have noticed. An assistant with good rules and an empty context window produces a stream of polite non-answers, and the team concludes the tool is not very useful.

The prompt also has no owner and no expiry. Put a date and a name inside it, on the first line, because it will outlive the person who wrote it, the competitor set it assumed and the category it described. Nothing else prompts anybody to re-read it.

Flares keeps a current, dated record of what competitors publish across pricing, product, documentation and messaging. The material behind a standing prompt then stays recent without anybody remembering to refresh it. What the prompt does with that material is still your design, and it still needs attacking before anybody relies on it.