Deep research
Most AI tools answer a question about your feedback by retrieving a handful of relevant messages and writing a confident paragraph about them. That's fine for "what are people saying about the new update?" It falls apart the moment the answer needs to be defensible — when you're about to move a deadline, reprioritize a sprint, or tell your CEO that 14% of players are hitting a bug.
Deep research is built for that second kind of question. Instead of retrieving some evidence and summarizing it, Kinn runs a bounded investigation: it defines a scope, measures what's actually in that scope before it retrieves anything, collects the complete matching set, classifies every record, and then calculates the numbers with ordinary arithmetic rather than asking a model to estimate them.
The short version: if the number matters, ask a question that needs a number. Deep research is what stands behind claims like "X% of reviews," "more common on Steam than Discord," or "this is the third most reported issue."
Why this is different
Four things separate this from a search-and-summarize answer.
The model never does the arithmetic. Counts, percentages, and per-source breakdowns are computed deterministically from the classified records. The model interprets language; it does not supply totals. This is the difference between a number you can put in a deck and a number that's a plausible guess.
Every source keeps its own denominator. A cross-source investigation builds a separate evidence ledger per platform, each with its own population and coverage, then rolls them up. Steam reviews and Discord messages are not the same kind of thing and never get averaged into one misleading figure.
It measures the source before it searches it. Before retrieval, Kinn computes how much content exists in your requested window, what languages it's in, and how much of it is actually indexed for semantic search. That's how you find out the answer is thin because there were only 40 messages, rather than concluding your players don't care.
It tells you what it couldn't see. Coverage gaps, incomplete collection, and failed sources are reported as first-class results, not quietly dropped. If a scope was too large to collect completely, you get an explicit incomplete result telling you to narrow it — not a confident answer built on a partial sample.
Nobody turns this on
There's no deep-research toggle, and that's deliberate. Kinn's main agent orchestrates the conversation, and when a question needs more than a direct answer it hands the work to a dedicated research subagent that runs the investigation and reports back.
What triggers that hand-off is the question itself — how much depth it demands, how much detail you've asked for, how intensive the ask is. "How did the patch land?" gets answered directly. "How widespread is this complaint across Steam and Discord, as a share of each source's feedback, broken down by platform?" is not answerable without an investigation, so one runs.
The practical consequence: you don't select depth, you ask for it. Everything in Writing good queries about being specific and naming what you want is also, in effect, how you get a more rigorous answer. A vague question doesn't just produce a vague answer — it produces a shallower process.
The three kinds of investigation
The research agent picks the shape that fits your question. You never name one, but knowing the three makes you much better at asking.
Prevalence — "how many, out of how many?"
Use it when you need a defensible number or a comparison between sources.
How widespread is the matchmaking timeout complaint across Steam, Discord and Reddit over the last 30 days? Break it down by platform and by whether people mention it happening on console or PC.
Prevalence collects the full candidate set using both meaning-based and literal matching, sorts every record into relevant / adjacent / not-relevant, and tags the relevant ones along whatever dimensions you asked about (platform, console vs PC, before vs after a patch). The output is counts and shares with representative quotes behind them.
Phrase for it with: how many, what share, how widespread, break it down by, compare X to Y.
Summary — "tell me everything about this specific thing"
Use it when the scope is already known and you want exhaustive coverage of it rather than a sample.
Summarize every piece of feedback on the new tutorial from the last two weeks — across all connected sources. I want the full picture, not highlights.
Summary exhaustively collects a filtered scope — or the records belonging to specific ranked groups — and reduces them without skipping. Large groups get broken into partitions and summarized hierarchically, so "everything" really means everything rather than the first fifty results.
Phrase for it with: summarize all, everything about, the complete picture, don't sample.
Discovery — "what don't I know to ask about?"
Use it when you want the unknown unknowns. This is the one teams most underuse, and often the most valuable.
Look across everything from the last month and find the recurring themes. I'm not looking for anything specific — show me what keeps coming up that I might not be tracking.
Discovery runs over the whole evidence pool and surfaces themes that recur, each with representative quotes, source coverage, and date ranges. A theme has to have at least two distinct pieces of cited evidence to exist at all, so you don't get themes conjured from a single stray comment.
Phrase for it with: what themes, what keeps coming up, what am I missing, what are people talking about that I'm not asking about.
Discovery counts are not prevalence. The support number next to a discovered theme is a grounded lower bound — "at least this many records cited this" — not a measurement of how common it is in your population. If a theme looks important, follow up with a prevalence question to size it properly.
How to read the answer
Check the denominators before the percentages. "18% of feedback" means something very different against 2,000 Steam reviews than against 30 Discord messages. The per-source breakdown is there so you can see which one you've got.
Read the coverage notes. If Kinn reports that a source was incompletely collected or that a chunk of your window isn't indexed, the honest read is "this is a floor, not a total."
Follow the citations. Every claim is backed by specific records with links. When a number is going into a decision, spend thirty seconds reading three of the underlying quotes — it's the fastest way to catch a question that was subtly mis-scoped.
Near-duplicates stay separate on purpose. Exact duplicates get removed, but two people describing the same crash in different words are deliberately counted as two reports. Merging them would require a guess, and a guess in the denominator is worse than a slightly conservative count.
When it won't run — and why that's right
Plenty of good questions don't get an investigation, and shouldn't:
- A quick read on the mood — "how did the patch land?"
- Exploring, when you don't yet know what you're looking for.
- Pulling up one specific thread or review.
- Iterating on phrasing to find the question you actually mean.
An investigation is slower and costs more, and none of those questions would be improved by one. Getting a fast, direct answer to a light question isn't Kinn declining to do the work — it's the right response.
This suggests a rhythm rather than a setting. Explore with light questions, then commit. Poke around until you know what you actually want to measure, then ask that question once and ask it properly — with the sources, the window, the breakdown, and the comparison spelled out. The depth follows the question.
Next
- Size how widespread something is — this capability applied end to end, from vague claim to defensible number.
- Triage bugs across platforms — prevalence applied to a real weekly routine.
- Writing good queries — the habits that make any query better.
- Example queries — a library to copy and adapt.