QueryBurst Answer Engine vs Prompt Tracking (Profound, Peec AI, PromptWatch)
Answer Engine is the investigation workspace within QueryBurst for modelling and investigating AI-mediated customer journeys. It starts with the person asking, the context they carry, and the multi-turn journey that gives each question meaning. Each turn inherits what happened before — including the assistant's previous answers — and journeys can branch as the buyer's priorities change. Answer Engine then exposes the process behind the response: the model's pre-retrieval position, fan-outs, evidence targets, retrieved passages, filtering, grounding, citations, and final answer.
Prompt trackers such as Profound, Peec AI, and PromptWatch work differently. They start with sets of isolated prompts, run them against AI systems, and record outputs such as mentions, citations, rankings, sentiment, or visibility scores over time. Answer Engine is not designed to track a prompt's movement. It is designed to investigate why an AI answer happened, where your brand entered or dropped out, and what changed along the way.
How is Answer Engine different from prompt tracking?
This is not a feature-by-feature comparison between QueryBurst and individual prompt-tracking platforms.
Profound, Peec AI, PromptWatch, and similar tools belong to a category built around observing and tracking AI outputs.
Answer Engine belongs to a different category. It is built for modelling and investigating AI-mediated customer journeys.
Prompt tracking asks whether an output changed.
Answer Engine asks what combination of person, conversation, research, retrieval, and evidence caused the output in the first place.
| Prompt tracking | Answer Engine | |
|---|---|---|
| Unit of analysis | Prompt | Person + journey |
| Primary purpose | Monitor outputs | Investigate outcomes |
| Model of context | None / static injection | Persistent + evolving state |
| Model of behaviour | Independent runs | Stateful conversations |
| Time | Repeated longitudinal tracking | Deliberate journey reruns |
| Intermediate process | Mostly unobserved | Exposed |
| Main output | Visibility metrics | Diagnostic evidence |
| Core question | “Did we appear?” | “Why did this happen?” |
Aren't both systems still using prompts?
Yes.
The difference is what the prompt represents.
In a prompt tracker, the prompt is usually the thing being measured.
In Answer Engine, the current message is one input within a larger state:
persona + conversation history + previous assistant answers + current branch + current message
The prompt matters.
It just is not the whole input.
Some prompt trackers have personas now. Isn't that the same thing?
No.
Some trackers attach a static persona description to each isolated prompt.
That usually looks like:
persona block + prompt → answer
Answer Engine separates:
persona = relatively stable background
conversation = evolving state
branch = alternative path
A persona tells us who the buyer is.
The journey tells us what has happened to them.
Adding the same persona block to every prompt does not create continuity between those prompts.
Why does that distinction matter?
Because context changes during a buying journey.
The buyer may:
- discover a product
- reject another one
- learn about a limitation
- become concerned about cancellation
- change their priorities
- narrow the shortlist
- ask a follow-up that only makes sense because of a previous answer
Those things should become context because they happened during the conversation.
They should not all be predicted in advance and injected into every prompt.
Isn't a fully developed persona more realistic?
Not necessarily.
A persona can become too detailed.
If you put the buyer's entire situation, shortlist, objections, preferences, and future decision criteria into the persona, you start encoding journey state as persona state.
Then every meaningful variation requires another persona.
Change:
- the budget
- the objection
- the shortlist
- the product already owned
- the concern raised in an earlier answer
and suddenly you need a new persona if those details were baked into the original one.
That does not scale well.
If you need a new persona every time the context changes, the persona is doing the job of the conversation.
But couldn't I just put all the context into one big prompt?
You can.
It may even produce a useful answer.
But it is not equivalent to a conversation.
A mega-prompt makes all context available at once.
A real multi-turn conversation creates state progressively:
user → assistant → user → assistant → user
The assistant's previous answers matter too.
They may introduce products, criteria, trade-offs, objections, or recommendations that directly cause the next question.
You cannot naturally reproduce that in one initial prompt unless you pre-script the entire conversation in advance.
A mega-prompt describes a scenario. A conversation lets the scenario develop.
Does the order of questions matter?
Yes.
Consider:
versus:
The same information appears across both conversations.
But it arrives in a different order.
In the first journey, the model may establish a shortlist before cancellation matters.
In the second, cancellation can influence the shortlist from the beginning.
Order is part of the context.
Isn't a buyer journey still hypothetical?
Yes.
So is a prompt set.
Neither system can know exactly what every real user will ask.
The difference is what gets modelled.
Prompt tracking usually models a distribution of isolated questions.
Answer Engine investigates people and plausible journeys.
Businesses have modelled customer behaviour this way for decades because exact future behaviour is unknowable.
The aim is not to predict every conversation.
It is to model the commercially important ones well enough to investigate how AI behaves across them.
What if the buyer takes a different path?
Branch the journey.
If a buyer could plausibly react differently at a particular turn, create another branch.
Both branches inherit everything that happened before the split.
After that, each evolves independently.
That makes it possible to model several plausible paths without creating a new persona or starting from scratch.
Isn't this just prompt tracking with multi-turn added?
No.
Even if a prompt tracker perfectly modelled personas and conversation state, it would still usually stop at:
final answer + citations + score
That still leaves the central diagnostic problem unresolved.
You still cannot see:
- what the model believed before retrieval
- why particular fan-outs existed
- what evidence each fan-out was looking for
- which sources were retrieved and rejected
- where your page lost
- whether your brand entered during retrieval
- whether the recommendation changed before or after grounding
So there are really two separate problems:
Input/state problem: who is asking, and what happened before?
Explanation problem: why did the system produce this answer?
Personas and buyer journeys address the first.
Answer Engine's research pipeline addresses the second.
Why does Answer Engine expose sources that lost?
Because retrieval and citation are not the same thing.
A page can be:
retrieved → selected → grounded → cited
or disappear at any stage.
A traditional tracker might tell you:
Answer Engine lets you ask:
Those are different problems with different fixes.
Why not just scrape ChatGPT's real UI?
Because the final UI answer is only the endpoint.
It is a real output.
But it does not expose most of what produced it.
Scraping can tell you:
It cannot generally tell you:
Answer Engine models the process forwards because most of that process is not observable from the final UI response.
Doesn't simulation make Answer Engine less "real"?
It makes it a different kind of system.
A scraped ChatGPT response is an observation.
Answer Engine is an investigation model.
Neither is a universal ground truth.
A real scraped answer belongs to one particular combination of:
- user
- account
- memories
- conversation
- location
- model state
- retrieval state
- time
- stochastic generation
Answer Engine instead lets you control those variables deliberately and inspect how changes propagate through the chain.
What about visibility tracking over time?
That is another major philosophical difference.
Prompt trackers are designed around continuous longitudinal measurement:
That becomes more complicated once persona context is introduced.
If a persona changes, the effective model input changes too.
Even if the visible prompt remains identical, the experiment is no longer identical.
So if the same visibility line continues uninterrupted, what exactly is being measured?
Answer Engine treats personas, journeys, branches, and reruns as explicit experimental state rather than pretending every change belongs to one seamless visibility series.
How often should I rerun Answer Engine journeys?
Usually when something meaningful might have changed.
For example:
- monthly
- after a meaningful site change
- after a product or pricing change
- after a major model or retrieval update
- when an important competitor changes
- when you want to test a new branch or persona assumption
The aim is not to watch a line twitch every day.
It is to understand what changed and why.
Is prompt tracking useless?
No.
It can be useful as an observation layer.
If you want to know whether a particular monitored output changed, tracking can tell you that.
The problem comes when an observation metric is treated as an explanation.
A prompt tracker can tell you:
what happened
Answer Engine is designed to investigate:
why it happened
Can I use Answer Engine alongside a prompt tracker?
Yes.
They answer different questions.
A prompt tracker can be useful for broad output monitoring.
Answer Engine can then investigate the journeys or changes that actually matter.
The two are not mutually exclusive.
But better prompt tracking is still prompt tracking.