On the Path to Autonomous Agents: Research Is the DIFFerence

In my last post I argued that memory is the foundation for autonomous agents. Without it, every session starts from zero and self-learning is impossible. But memory alone doesn’t solve a basic problem: you know what you know, and that’s it. You’re stuck with whatever your agent learned last time, plus whatever the model absorbed during training.

Folks using AI for coding have known this since the early days and found various ways to add documentation and context so that models could write code using modern patterns and frameworks. This can bite you in very trivial ways, so don’t underestimate it. I was building a simple parser for Claude Code session logs. Specs done, tests passing, code looking solid. I ran it. No data. But I’d been using Claude Code daily for months, so that made no sense. Turns out the model had used an old file path from a previous Claude Code version and never checked whether it was still correct. The whole thing failed because of a single stale fact that a thirty-second research step would have caught.

I really don’t think you can have any LLM doing useful work on problems that are even slightly non-trivial without some form of research. It’s as foundational as memory. Without it, agents are operating largely in the dark. Research, especially in autonomous form, can make this a lot better, and that’s why it’s building block number two of my autonomous agent project.

But it’s module two and not one because research doesn’t happen in a vacuum. Research without context of what you already know is wasteful. If I’ve spent three weeks reading about a topic and then ask an AI to “do deep research on an implementation,” I don’t want a summary of what’s already in my head. I want the difference. What’s new and relevant to this step? What have I missed? What contradicts the theory when it comes to implementation? The value isn’t in the knowledge alone. It’s in the delta.

I’ve started calling this the DIFF, borrowing the concept from version control. When you run git diff, you don’t get the whole file. You get what changed. That’s the mental model: research should surface the change between what you know and what’s out there. Not a dump of everything on the internet about your topic.

Like many tech workers, I’ve been doing heavy research for years. As an engineer, researching new technologies was part of the job. As a product manager, it was customers, markets, competitors. When AI research tools started appearing, I jumped in. Search and deep research were my primary AI use case even before coding.

Perplexity was my main tool for a long time. I still think it’s the best deep research product out there. The citation granularity is excellent, the speed is impressive, and it gets you to useful information fast. But every time I finished a research session, I had the same nagging feeling: I could see what it searched, but I had no idea how it evaluated what it found.

Then Google launched Gemini Deep Research, and something felt different. Before it starts searching, Gemini shows you an editable research plan. You can see the structure, adjust the scope, remove or add areas. I liked that. It was the closest any product had gotten to transparency.

But the plan was where the transparency ended. Once it started executing, I was back in the dark. How many links is it following? How deep is it going into each? Is it following sub-links or stopping at the first page? What does it consider authoritative versus not? Is it paying attention to whether a source is from 2024 or 2019? No way to know. Still a big black box, just one with a slightly more transparent lid.

ChatGPT Deep Research had similar opacity. Different execution, same pattern: here’s your answer, here are some links, verify your sources. Do I think I’m smarter than the engineers at Google or OpenAI? No. But they need to build something that fits certain constraints that aren’t necessarily my constraints. Their products serve millions of users. My research needs are specific, iterative, and deeply contextual.

The common thread across all of them: you can see what they searched but not how they evaluated what they found. And the evaluation is where real judgment lives. Deciding which sources to trust, which claims to verify, which perspectives to include and which to filter out. That’s the hard part of research. That’s where it goes right or wrong. And every product hides it.

This question started bothering me, so I did what I do: I researched it.

The term “deep research” emerged as a product category in early 2025. OpenAI launched first, in February 2025. Google Gemini and Perplexity followed shortly after. Now every major provider has a version: Claude, Grok, DeepSeek. Same label everywhere.

But there’s no consensus on what it actually means. Each vendor emphasises different strengths. OpenAI stresses analytical depth. Gemini stresses ecosystem integration with Gmail and Drive. Perplexity stresses speed and citation granularity. The underlying architecture is real enough: these are RL-trained agents that plan, execute, backtrack, and synthesise, rather than single-shot retrieval. Someone described the distinction well: “Deep Search is a skilled librarian who finds the best books; Deep Research is a scientist who reads them all and generates new insights.”

Fair enough. But in practice, “deep research” is a marketing label for “agentic web research.” The “deep” signals time investment and source breadth, not necessarily analytical rigour. Output quality is heavily prompt-dependent. A vague prompt yields a shallow report regardless of the branding. Free-tier implementations are often surface-level summaries with a few more citations than regular search.

There’s even an IEEE Spectrum finding that AI-assisted research may paradoxically narrow inquiry. Scientists using AI tools publish more, but cover less topical ground. The “deep” might mean “deeper into the same hole” rather than “broader and more original.”

That finding crystallised something I’d been sensing. If deep research just means following more links on the same trail, you’re not getting deeper. You’re getting more of the same. More confirmation of what you already suspected. More consensus. More average. That’s the anti-DIFF. It’s research that never surfaces the difference.

This binary framing isn’t helpful either. Real problems don’t fit into deep-or-nothing. A quick fact check needs three sources. A market analysis needs thirty, with link following and cross-referencing. A competitive landscape needs directory searches, investor relationship mapping, and deliberate contrarian queries. The right frame is a spectrum with tunables, not a feature toggle.

So if the standard approach to deep research is “search more, summarise more,” what should it actually be?

I keep coming back to the same answer: the fundamental value of research is the DIFF. Not summarisation. Not reduction of knowledge into a tidy report. The extraction of things that are important and unknown.

Think of it as Discover Weekly for the internet. Spotify’s Discover Weekly doesn’t play your favourite songs back to you. It surfaces music you haven’t heard that fits patterns you’d probably like. That’s the model. Not curating what’s already in your feed, but surfacing what you haven’t encountered.

This connects directly to memory. You need memory to know what you already know, so research can focus on what you don’t. They’re not separate building blocks that happen to sit next to each other. They’re two sides of the same coin. Memory provides the baseline. Research finds the delta. Without memory, research can’t know what’s new to you. Without research, memory goes stale.

There’s supporting evidence from the technical side as well. The Chroma team published a study on “Context Rot” showing that increasing input tokens actually degrades LLM performance. More context isn’t better. More relevant context is better. The DIFF is how you get there: instead of dumping everything into the prompt, you surface only what’s new and important relative to what’s already known.

If we set aside the marketing and think about what would make research genuinely deep, what would the components be? I’ll keep this at the design level here. In the next post I’ll walk through the actual implementation, the failures that shaped it, and the eight-step workflow I ended up building. But the ideas matter before the mechanics.

Goal clarity is the single biggest lever, and almost every product ignores it. When someone says “research phoneme models,” the naive approach is to search for phoneme models. But what’s the actual goal? In my case, I was building a voice analysis system for mispronunciation detection. Searching for “implementations of voice analysis systems that help users identify mispronunciation” produces radically different results than “phoneme models.” I don’t even know how you quantify the improvement. 10x? 100x? Understanding the real goal before searching is the PM discipline applied to research: understand the problem before jumping to solutions.

In my system, a separate interviewer step fires before any searching begins. It asks clarifying questions, surfaces hidden assumptions, and reframes the query around the actual objective. Most of the time, the reframed query is a completely different search.

Contrarian search. LLMs are trained to find the average, the most common answer. Default search reinforces this. You search for what you think is right and find confirmation. It’s almost a confirmation bias machine: you bake the answer into the question. Breaking this requires deliberately seeking disagreement. Who thinks this approach is wrong? What are the alternatives? What are the problems nobody talks about?

But this needs guardrails. You want credible dissent backed by authority and evidence, not clickbait contrarianism. You’re not trying to find one answer. You want a set of answers you can use to think through the problem yourself.

Source authority. Not all results are equal, and models are surprisingly bad at assessing this. Would you trust Guido van Rossum writing about Python more than a random blog post from someone who just finished a tutorial? Obviously. But without explicit guidance, an LLM treats them the same. A useful mental model is a tiered reputation system: authoritative sources at the top (primary research, official documentation, domain creators), established sources in the middle (major publications, industry databases), then emerging, questionable, and unreliable tiers below. The scoring doesn’t need to be perfect. It needs to exist at all.

Time and freshness awareness. Models are bad at thinking about time. A perfectly cited source from 2021 might be dangerously wrong in 2026. But staleness means different things for different research types. Job market data older than 30 days is suspect. Company facts older than 90 days need verification. Thematic research can tolerate a year or two. Without explicit freshness rules, the model treats a five-year-old blog post the same as last week’s documentation update.

Transparent reporting. The standard output format of “here’s your answer plus a flat list of URLs” is broken for trust. Nobody clicks fifty URLs to verify a research report. What actually builds trust: stack-ranked sources with brief descriptions of what each contributed. The queries that were used. The decomposition logic. Tensions between sources explicitly called out. Minority views presented rather than hidden. Show the process, not just the conclusion. I don’t just want to see the results. I want to see the whole research trail so I can verify the reasoning myself.

Each of these addresses a specific failure mode. Goal clarity fixes searching for the wrong thing. Contrarian search breaks the echo chamber. Source authority prevents treating all information as equal. Time awareness catches stale data. Transparency makes verification possible. Together, they define what “deep” should actually mean: not “followed more links” but “understood the goal, challenged its own assumptions, assessed what it found, and showed its work.”

Over the past several weeks I’ve iterated through five versions of a deep research skill that runs inside my development environment. Each version solved a specific class of failure, not a theoretical problem. A missed startup in a market analysis drove me to add directory search and entity graph traversal. A confident wrong claim drove me to add a verification cycle. A couple conversations with another founder drove me to rethink how vocabulary ceilings create blind spots. The skill has run hundreds of times across everything from competitive landscape analysis to technical architecture research to relocation planning.

The DIFF concept isn’t just the framing. It’s the operational principle. The skill takes what I already know (loaded from memory files and existing research) and focuses its energy on what’s new, changed, or contradictory. When I run it on the same topic twice, it produces a research diff showing only what’s new since the last pass. The concept made concrete.

And it’s not a standalone tool anymore. Deep research has become embedded in every phase of my autonomous development workflow. Before creating any specifications, broad research grounds the design. When validating a specific feature, targeted research checks the approach. Before implementing each chunk of code, focused research finds current best practices and libraries. Research fires at every zoom level, each pass more focused than the last, each building on what the previous pass established. It’s fractal: the same pattern, repeating at every scale.

This is what makes autonomous development actually work. The agent isn’t coding from stale training data. It’s researching current reality at every decision point. Memory tells it what it knows. Research tells it what it doesn’t. The DIFF connects the two.

Next, I’ll walk through the actual skill: the eight-step workflow from PLAN through SYNTHESISE, the Yutori miss story that reshaped how I think about discovery, the wrong claim that forced me to add verification, and how deep research became fractal infrastructure in my autonomous development pipeline.

If any of this resonates, or you think I missed something important, or you’re building something similar, I’d rather have a conversation than a subscriber. Feel free to find some time to chat.

Take care,