May 2025·6 min read

How AI Actually Generates a Research Document

Most people think of AI document generation as a prompt going in and a wall of text coming out. That mental model is wrong, and it explains why most people are disappointed with the results they get. The output is only as good as the process behind it, and a well-designed process looks nothing like a single API call.

The problem with one-shot generation

If you hand a language model a topic and ask it to write a comprehensive document, it does its best. But it is optimizing for plausibility, not accuracy. It has no mechanism to notice when it is drifting off-topic, no way to verify claims against recent sources, and no quality gate at the end. You get confident prose that may be structurally coherent but factually thin.

The documents that actually hold up under scrutiny are built differently. The work is split across multiple specialized steps, each with a narrow job and a clear output format that feeds into the next.

Planning before writing

The first step is structural analysis, not writing. A planning agent takes the topic and thinks about what kind of document this should be — technical reference, market analysis, historical overview — and produces a granular outline. Not four broad headers. Twelve to fifteen specific, substantive section titles that already tell you something about the content.

This matters because the outline becomes a constraint. The writing agent cannot meander or pad. Every section has a job, and the structure of the document is decided before a single paragraph is written.

When to search, when to use internal knowledge

Some topics need real-time data. Current interest rates, recent legislation, last quarter's earnings — anything time-sensitive will be wrong if the model relies on training data alone. The planner is responsible for deciding when a web search is necessary before producing the outline.

For topics where training data is sufficient — a deep dive into Raft consensus, an explanation of second-price auctions, a history of the transistor — no search is needed. The model already knows enough. The judgment about which category a topic falls into is itself a meaningful part of the pipeline.

The writing stage

Once there is an outline and, where needed, scraped source material, the writing agent takes over. It receives the topic, the planned structure, and any external data, and its job is depth. Three to four dense paragraphs per section. Specific claims. No summaries, no throat-clearing.

The output is structured JSON — not raw prose. Each component has a type: heading, paragraph, callout, code block, table. This enforced structure means the document can be rendered consistently and the next stage can inspect it programmatically.

Verification as a separate pass

The verifier agent gets the completed document and the original topic, and its only job is to find problems. Is the JSON valid? Does every section have enough content? Are the component types used correctly? Does the document actually address what was asked?

A human editor would catch these issues in review. The verifier does it automatically, and a failed verification surfaces the specific problems rather than silently passing substandard output downstream.

Why this architecture works

Each agent is focused on one thing. The planner does not write. The writer does not verify. The verifier does not rewrite. This separation means failures are isolated and diagnosable. If the document is bad, you know whether the failure happened in planning, writing, or validation.

It also means the quality bar is enforced at multiple points in the process, not just at the end. A document that makes it through all three stages has been examined from three different angles. That is a meaningfully different result from a single model doing all three jobs at once.