Build your competitor as an agent — then find out what you told them
Ground an agent only on what an outside analyst could actually assemble about you, then point the same collection at your own company.
EXECUTIVE SUMMARY
Build an AI agent that models a competitor using only publicly observable information — filings, pricing pages, job postings, product announcements — and nothing an insider would know. The constraint is what makes the result mean anything: you stop guessing what a competitor would do and start measuring what they can conclude.
Then point the same collection at your own company. The output is your observable surface as an outsider assembles it, with every conclusion traced to the specific published thing that permitted it. That turns "what do they know about us" from a standing debate into a list of findings with owners attached.
Two requirements make it trustworthy rather than merely impressive. The collected material lives in the warehouse as ordinary data, so it can be audited with the same tools you point at revenue, and only public material ever reaches an outside AI assistant — internal numbers never leave. And every collection run is counted against an expected volume before anything reasons over it, because an empty collection reads exactly like a quiet quarter.
Without that last check, the output is not intelligence. It is a strategy memo with no evidence underneath it, written in a confident voice.
Most people who simulate a competitor with AI give it everything they know. That's why it tells them nothing.
An agent grounded on your own internals reasons like you with a different logo on. It has your assumptions, your numbers, your read on the market, and it hands them back with the confidence of an outside opinion. You've built a mirror and called it intelligence.
The useful version inverts the constraint. Ground the agent only on what an outside analyst could actually assemble about you — and nothing else. The limitation is the instrument. You stop asking what a competitor would do, which nobody can know, and start asking what a competitor can conclude, which is a question with a checkable answer.
THE CORPUS IS THE METHOD
Everything that determines whether this works happens before the model is involved. An agent's conclusions are a function of what it was given, so the corpus is the experiment and the prompt is close to irrelevant. Most of the effort in this field goes into the instructions, and the corpus is the part that decides.
Which means the discipline is source selection. What could a competent analyst at a competitor actually assemble about you? Public filings. Your pricing page. Job postings. Release notes and product announcements. Support documentation. Your public code repositories. Conference talks. Review sites. Anything else is contamination, because the moment the corpus contains something only an insider could know, the output stops being a model of an adversary and becomes a model of you.
HOW IT IS ACTUALLY BUILT
Apify runs on a schedule against the predictable sources — job boards, product announcements, review sites. Bright Data handles the pages that have to be requested from a particular country to show what a local customer actually sees, and that matters more than it sounds. A price page that quietly differs between the US and Europe is a segmentation decision, and you can read it months before anyone announces it. From one location you cannot see it at all.
Each run appends to a table rather than overwriting one. This is the detail that turns collection into intelligence, because the signal is almost never in the current state. It is in the change. What the careers page said in March, what it says now, and which team grew in between. A pricing tier that existed in the first quarter and doesn't now. A support article that quietly changed its recommended migration path. Overwrite the table and you have thrown away the only part that was worth having.
The corpus lands in the warehouse alongside everything else. Sigma reads those tables directly, which means the corpus, its record counts and its collection history are ordinary data — queryable, joinable, auditable with the same tools you already point at revenue. There is no separate intelligence product to trust and no export to reconcile against reality.
TWO RULES THAT MAKE IT AN INSTRUMENT
First: every conclusion must cite something that was actually captured. Collected records carry a source and a timestamp, so this is checkable rather than honour-system. If a claim cannot be traced to something in the corpus, the model reasoned from general assumptions about your industry rather than from evidence about this company. Those two outputs read identically. Only one is safe to act on.
Second: the definition of the corpus is itself data, not an instruction. Which sources, how often, what to collect — written down in a table that can be reviewed, versioned and compared against last month's. Adding a source is a row. What the agent is allowed to know becomes something a colleague can audit, rather than a paragraph of guidance everyone hopes the model is honouring.
THE ASSISTANT IS NOT THE AGENT
Two things look alike — asking an AI a question — and confusing them undoes everything above.
A general assistant built into a tool exists to help whoever is doing the building, and broad reach across the model is the right design for that job. While I was building on Sigma, its assistant volunteered its own reach unprompted: it offered to query across departments, users, roles, permissions, assignments, resources and scopes, and to tell me who had access to what and who had granted it. That is a helpful authoring assistant behaving exactly as intended.
An agent is a different object. It is grounded on a defined, named set of data and it cannot reach past it — and that is the entire property this method depends on.
So the mistake isn't using either one. It is putting your competitor questions to a broad-reach assistant, getting back a fluent answer drawn from everything you happen to have access to rather than from the corpus you defined, and then treating it as though it came from the instrument. You will have no way to tell which parts of it came from where.
Know which surface you are on before you trust the answer. They are not interchangeable, and only one of them has a boundary.
WHERE THE INFERENCE RUNS
This is the question anyone sensible asks first, and it deserves a real answer rather than a reassurance. There are three arrangements and they are not equivalent.
Inference inside the warehouse — Snowflake Cortex, Databricks model serving. The question and the data are evaluated within the same governance boundary you already audit. This is the only arrangement where "the data never leaves" is literally true. Worth confirming which models are available in your own region, and whether cross-region processing is switched on, because that crosses the line the story assumes it doesn't.
Inference mediated by the platform — Sigma's own agent. You pick the model, and there are several to pick from, Claude and Gemini among them. That choice matters more than it first appears, because it lets you route the work to a provider whose terms you already hold and have already had reviewed, rather than inheriting whatever default someone else chose.
Mechanically it is an external fetch. The question and the result go out to the model, the answer comes back. That is the same shape as the AI features in every business tool your company already runs, over a contracted path with terms you can read. The distinction from in-warehouse processing isn't safe versus unsafe. It is that the boundary sits somewhere different, and the only real mistake is not knowing which side of it a given piece of work is on.
Two things make it comfortable in practice. What leaves is the answer to one question rather than the table behind it, so a well-scoped starting point means very little travels. And because you choose the provider, this is a decision you can take to whoever owns vendor review, with a named counterparty and terms attached, instead of a property of the tool you simply have to accept.
Inference in a third-party assistant — Sigma's new interface for agents that run outside the workbook, used from Claude or Codex. In this design that is where the competitor corpus goes, and only the competitor corpus.
Which is the whole point of routing by sensitivity rather than by whichever tool is pleasant to use. The competitor material is public by construction: things they published themselves. No internal data is in that agent's context at any point. That isn't leakage mitigated by policy. It is leakage that isn't structurally possible, because the rows were never there. Anything touching your own numbers stays behind the boundary, with the processing happening there.
RUN IT BACKWARDS
Here is where the exercise earns its cost. The valuable output was never the competitor's predicted move.
Point the same collection at yourself. What comes back is your own observable surface, assembled exactly the way an outsider would assemble it. Not a guess about what you are leaking — a capture of it, with each conclusion traced to the specific thing that permitted it.
Five job postings for one specialised skill announce a rewrite. A quietly retired pricing tier announces a segment exit. A support-doc edit announces a discontinued product before your roadmap does. A conference talk abstract announces a partnership that hasn't been signed.
That converts "what do they know about us" from a recurring conversation into a finding with an owner and a decision attached: stop emitting it, or emit it deliberately.
COUNTERFACTUALS
Because the corpus is a pipeline rather than a folder someone assembled once, you can rerun it against a changed input. Two agents, each grounded only on what it can observe of the other, iterating. Publish the case study or hold it. Post the job listing or don't. Then rerun and read the difference.
A strategy offsite produces an opinion. This produces a difference you can point at.
THE FAILURE MODE, WHICH DESERVES MORE ATTENTION THAN THE TECHNIQUE
A competitor redesigns a page. The collection returns nothing. Nothing is not an error.
The agent fills the gap from general assumption and confidently reports a hiring freeze that is really a page redesign. Nothing in the output looks wrong, because the output is articulate, plausible and internally consistent. Its only trace is an absence, which makes it the hardest kind of failure to catch by reading — you cannot review your way to noticing something that isn't there.
I learned to take this seriously the hard way, in my own tooling. Nemo iudex in causa sua — no one may be judge in their own cause. It is a principle from law, and it is the whole premise of a tool I build: the thing being assessed must never be the thing doing the assessing.
So I turned it on itself. It gave itself a perfect score and a zero score in the same report — two numbers that cannot both be true. Underneath that single impossible figure sat six separate faults, and not one of them announced itself. The report was formatted, articulate and confident throughout. The only reason I caught it is that the two numbers happened to contradict each other. Had they agreed, I would have believed the whole thing and moved on.
So the corpus gets a record count and an expected value before anything reasons over it. Forty job postings yesterday and zero today is an alert, not a finding. The collection history is kept rather than overwritten, so a collapse in volume shows up as a number rather than being inferred from a strange conclusion three steps downstream.
A competitive intelligence pipeline without that check is a strategy memo generator.
THE SAME PROBLEM AS ACCESS CONTROL
I spent last month building an application-level role-based access control model on Sigma and publishing it, and the finding that transferred was this one: an agent grounded on a scoped view cannot reason about rows that were never in its results. Nothing gets refused. There is no guardrail to argue with, because there is nothing to argue about.
Defensively that is containment — you cannot talk your way into data that was never in the query. Offensively it is measurement. Same principle, opposite direction, and both of them live in the data rather than in the instructions.
Worth being precise about what that demo proves and what it doesn't. It is published on Sigma's free tier so anyone can open it without an account, and the same model runs unchanged in a plain SQL database. Together those establish the only claim it makes: scope can be expressed as data rather than as an instruction, and that holds anywhere.
It is not the deployment target, and I would rather say so than let anyone read it as one. The free tier reads from uploaded files, so there is no warehouse behind it and no real write path — the entry form demonstrates the boundary rather than doing the work. Everything the method above depends on sits on the subscription side: writable tables backed by the warehouse, a history your own queries can reach, and the boundary expressed as a governed view rather than as something assembled inside one page. That last one is the difference that matters, because a view is inherited by every consumer — including agents that never open a page at all.
HYGIENE
Respect robots.txt, rate limits and terms of service. Take care with personal data appearing in reviews and job listings, which is more common than people expect and carries obligations that do not disappear because a collector picked it up incidentally.
And keep the outputs framed internally as your model of a competitor. Never as their position, their analysis or their words.
Construct the corpus honestly, then refuse to help the agent past it. That is most of what adversarial agent testing turns out to be.