Show & Tell: Deep Research and Asking the Tool How to Use the Tool

The commercial deep research tools are genuinely good. Perplexity, GPT Deep Research, Claude Research: they index hundreds of sources, synthesize with depth, and return results in minutes. They also send your query, your context, and everything they crawl to someone else's infrastructure. For most questions that's fine. For questions about your own systems, your own security posture, your own infrastructure topology, or for questions you just don't want to put out in the open, it's less fine.

That was the starting point for my exploration. I had no grand thoughts about building something better because, really, there's no way that I can. This was much more about being able to do this on my own hardware, with my own inference, in the privacy of my own environment, and I'd like to understand what it takes to get to a reasonable outcome.

Start With the Tool Itself

The first thing I did was ask Qwen what I was about to ask Qwen to do.

Let me unpack that a bit. I wasn't being clever in the least; the LLM knows what it is and its own limitations and who better to ask than the source itself? Before I even started to build anything, I wanted to understand, from Qwen directly, what would be the best prompting frameworks for deep research queries when asking it to handle the task. I wanted to understand from its knowledge of itself what constraints matter the most when working with it and how I should structure a research question to get the most useful results from it.

Qwen handed back a set of research frameworks, each suited to a different kind of question, and explained which search strategies would focus the results most effectively given the constraints of local inference. What I keep coming back to is this: there isn't just one kind of deep research question, and treating them all the same is where most approaches fall short.

Before building the intake, I used Qwen to help me design the intake. Before I started writing the prompts to get to the results I wanted, I asked it what prompts would work best for the desired outcome.

This is the same instinct as interviewing users before designing for them, only the user is the model I was about to deploy.

And make no mistake here, I don't think I did user research in the way we do user research - not by any stretch of the imagination. I don't know what the hell this was, however, I know that I was given information that I could use to fuel the next steps and the insight allowed me to do something that I wouldn't have considered otherwise. That was a bit of a level-up moment for me.

The frameworks Qwen identified weren't invented for this project. They come from research methodology: SPICE* for comparative questions, PICO for causal ones, PICo + Entity Extraction for exploratory ones, step decomposition for procedural ones.

Each maps to a different kind of question and drives a different decomposition strategy. A question like "should I use Tailwind CSS for this project" is a comparative question that needs setting, perspective, comparison criteria, and evaluation dimensions. A question like "how do I deploy SearXNG" is procedural and needs prerequisites, steps, and validation criteria. Treating them the same way produces mediocre results for both.

*SPICE: Setting, Perspective, Intervention, Comparison, Evaluation; PICO: Patient/Problem, Intervention, Comparison, Outcome; PICo + Entity Extraction (Population/Problem, Intervention, Comparison, Outcome)

The Intake Is the Work

Every commercial deep research tool has the same weakness: the intake is a text box. The human types a question, the robot generates sub-queries, it searches, it synthesizes. There's no question classification, no framework mapping, and no understanding of what kind of answer the question actually demands. To be fair, I suspect the commercial tools do some version of this behind the scenes; that black box is bigger than I have the ability to crack.

I built the intake as a design problem. The form is your standard text area input asking for the research question. I added another text area for context - Why are you asking this? That's good to know, no matter what, and we're not always driven to over-share like that, so this is a reminder. When the query gets submitted, Qwen classifies the question type and selects the appropriate prompt framework for the best results from the query.

And here's the cool part: Qwen asks for a contextually-relevant clarification or additional details for each part of the framework that could use bolstering to get the best results.

I mean, c'mon. How cool is that?

Qwen also recommends how many rounds of research are needed to get the best results and aligns the query to a research strategy that winnows our 100+ search engines down to the most-focused and best-suited for the query so as to not burn extra cycles on sources likely to give us repeated results or those that are not even in the same ballpark.

Qwen tells me: Here is what I understood. Here is what I inferred. Here is what I still need from you.

That read-back pattern changed everything. It moved the quality gate from the output end to the input end, which is where it belongs.

Working Within Constraints

Qwen 3.6 at 27 billion parameters is not a frontier model. (What's a frontier model? It's a model that is the most advanced, large-scale, and right out there at the bleeding edge) It has a practical context window, occasional quirks with output formatting, and it performs better with focused single-purpose prompts than with multi-constraint instructions. I don't see those as challenges to overcome when they're more like the constraints within the design brief.

Every decision in the pipeline was shaped by working with those constraints rather than against them. Query optimization transforms natural language sub-questions into search-engine-optimized queries before they hit SearXNG (a free, open-source, and privacy-focused metasearch engine for aggregating results from a variety of search engines), because a 20-word conversational question is a terrible search query.

Confidence scoring runs after each round so the system knows which sub-questions have enough evidence and which need another pass. Ongoing summary compression keeps context bounded across rounds while preserving citations and topic-relevant specifics. The research stops when confidence is met, instead of running a fixed number of rounds regardless of what the evidence says.

The benchmarking against commercial tools was humbling in the right ways. Their breadth is better, their model reasoning is deeper, and they index more sources faster with more sophisticated content extraction. And I will still use the heck out of them when the need calls for it.

And what I've managed to build that they don't have is full pipeline transparency, per-sub-question confidence scoring, privacy, and the ability to run 9-12 Qwen calls per session without a cost review. And for good measure, I added a Research Analyst that allows for semantic querying of the results (full transparency: this is a pattern I've invoked multiple times across a variety of projects and products so it's not like this is some great feat; more like a light-touch humblebrag, I suppose).

When inference is free, you optimize for quality instead of efficiency.

What It Produces

After 41 completed research sessions (which for what it's worth, took anywhere from about 8-20 minutes each and is an awful lot of time watching paint dry), the output is focused rather than exhaustive. A typical session returns a 2,000-word synthesis with 10-15 sources, per-sub-question confidence scores, a full audit trail from claim to source, and explicit evidence limitation disclosures where the research came up short. It flags unsourced claims, notes where sources disagree, and qualifies vendor-reported data as vendor-reported. And if you'd like, it'll show every aspect of the pipeline log for verification; no black box.

It's not trying to be GPT Deep Research. It's trying to be the best research a 27-billion-parameter model can produce on a single GPU without sending a byte to anyone else's infrastructure. Within that constraint, the design goal is the same as any other research tool: get the most useful, honest, well-sourced answer possible, and make every step of the process visible.

This started by asking Qwen how to get the best out of Qwen. It turned out that insight ended up levelling-up everything else I did in the whole project.