It is a fair question and a good tool
Paste a competitor's domain into a model with browsing and you will get a useful summary in thirty seconds. Positioning, rough product range, the tone of their marketing, who they seem to sell to. For a first look at a company you have never heard of, it is excellent, and we would rather you used it than guessed.
We use models ourselves. A large part of what we measure is what the answer engines say about a category, because that is now a place buyers make decisions. So this is not an argument that models are bad at reading.
It is an argument about three specific things they cannot do, and one thing they will do that causes real damage.
One: it has no copy of last week
A model can tell you what a pricing page says right now. It cannot tell you that a fourth tier appeared on Tuesday, because nothing kept the version from Monday.
This is the whole difficulty, and it is not a limitation of intelligence. It is a limitation of custody. To say a discount moved from 22% to 20% you need the 22%, taken on a date, stored somewhere. No amount of reasoning recovers a page that nobody saved.
And almost everything worth acting on is a difference rather than a state. An ad that has run for two hundred days matters because it was ninety at the last check. A complaint theme matters because it is new. A competitor's ad count matters when it goes from four to twenty in a week. Ask a model for any of those and it can only describe the present, which is the least interesting half.
Two: a lot of it is not readable to a fetch
"Public" and "reachable by a script" are different sets, and the gap between them is wider than most people expect.
An ad library renders in a browser after the page loads, so a plain fetch sees an empty shell. A checkout shows a currency only once a country is chosen. Some sites answer automated requests with a security challenge that a person clicks through in two seconds and a machine cannot pass at all. We measure one brand where twelve of our collectors hit that same wall and all fail together.
None of that stops a model from producing an answer about those sources. It just means the answer was assembled from whatever else it could find, and the fact that the primary source was unreachable does not appear anywhere in the reply.
Three: it will answer anyway, and that is the dangerous part
Ask how many ads a competitor is running and you will get a number. It will be formatted like a measurement, phrased with appropriate hedging, and it will be plausible.
You cannot tell from the sentence whether it came from a page that was read, a page that was cached months ago, or a reasonable inference from company size. A missing measurement and a real zero look identical in prose, and prose is very good at hiding the difference.
This is the failure we spend most of our engineering on, and we spend it there because it is the one that survives review. A number that is obviously wrong gets caught. A number that is quietly wrong gets quoted in a meeting, and then it gets acted on.
So our rows carry the date they were taken and the window they cover, a first measurement is labelled as a first measurement rather than dressed up as a change, and a source we could not reach is named as unreachable rather than left as a blank that reads like calm.
The verification problem
Suppose you ask the model and get ten claims about a competitor. To use any of them in a decision you have to check them, which means opening the sources yourself, which is the work you were trying to avoid.
Checked, the answer was a helpful index. Unchecked, it is a confident story. The saving only exists if you skip the checking, and the value only exists if you do not.
That is why we store the evidence rather than the summary. Every claim links to the page or the listing it came from, so verifying is a click instead of a repeat of the research.
And you would have to ask again
The last problem is the most boring one. Even if a single answer were perfect, you would need it again next week, and the week after, for every competitor, and you would have to remember what it said the previous time in order to notice anything had moved.
Seven competitors, twenty sources each, every week, with last week's answers kept in a form you can subtract from. At that point you have not avoided building the tool. You have started building it by hand, and the first thing that slips on a busy week is writing down what you did not manage to check.
Where a model genuinely is the answer
For reading and summarising a page you already have, models are better than anything else and we use them for exactly that. For judging tone, grouping complaints into themes, or turning forty reviews into six recurring problems, they are excellent.
And there is one place where the model is not the researcher but the subject. What the answer engines themselves say about your category is now a market position in its own right. Whether you are named, named first, or not named at all, is worth measuring on a schedule, with the raw prompt and the raw answer stored so you can read the sentence.
Ask a model to summarise. Do not ask it to remember.
Pick one competitor. See what we find.
Your first benchmark is free. One domain, measured against you, no card and no call.