Turn Research PDFs into Decision Briefs with an AI Agent

PDF Summaries Are Not Research Outputs

Most research agents stop at the least useful artifact: a pile of summaries.

A user uploads papers, market reports, policy documents, or technical PDFs. The agent reads them and produces a fluent paragraph for each file. The output feels productive because it compresses a stack of documents into a few screens of text.

Then the real work starts. Which claim is supported by which source? Which number came from the paper’s results and which one came from the literature review? Which report contradicts the others? Which evidence is strong enough to affect the decision? Which uncertainty should block the recommendation?

Summaries do not answer those questions reliably. A research workflow needs structured evidence before it needs prose.

If you are building an AI research workflow, this is the difference between a file-chat demo and a research assistant someone can trust with product strategy, investment review, policy analysis, technical due diligence, or client research.

The Workflow Needs Two Representations

Research PDFs need two representations:

• Markdown for full-text comprehension.
• Structured fields for decision evidence.

Markdown helps the agent read the paper. It preserves section flow, tables, headings, references, and surrounding context. The same context problem shows up in RAG over public and internal documents: without a readable representation, an extraction step may pull a number without knowing whether it is a baseline, result, limitation, example, or citation from someone else’s work.

Structured extraction helps the workflow reason over evidence. It turns claims, metrics, methodologies, limitations, and quotes into fields that can be compared across sources.

The generated brief should come last. If prose comes first, the workflow is asking the model to compress and decide at the same time. That is where evidence disappears.

Start With the Research Question

Do not start with “summarize these PDFs.”

Start with the decision the reader has to make.

Examples:

• Should this product team prioritize enterprise security features or onboarding improvements?
• Is this market report strong enough to support an investment memo?
• Which policy option has the strongest evidence base?
• What do these technical papers imply for the architecture decision?
• Which client recommendation is supported by the source material?

The research question determines the extraction schema. A product roadmap review needs different fields than a legal-policy brief. A technical diligence workflow needs different fields than a customer research synthesis.

That is why generic summary fields are weak. They produce generic answers.

The Agent Workflow

Connect an MCP-compatible runtime such as Hermes Agent, OpenClaw, Claude Cowork, Claude Code, Cursor, or OpenCode to the Iteration Layer MCP server.

Then run the workflow in layers:

1. Document to Markdown converts each PDF into readable context.
2. Document Extraction extracts the evidence schema from each source.
3. The agent builds a cross-source evidence table.
4. The agent identifies agreement, contradiction, weak evidence, and missing information.
5. Document Generation creates the decision brief.
6. Sheet Generation creates an evidence workbook when the review needs one.

The agent is not trusted because it writes well. It is useful because the facts are structured before they become prose.

The Evidence Schema

For research-heavy workflows, extract the decision inputs directly.

A useful schema often includes:

{
  "fields": [
    {
      "name": "source_title",
      "type": "TEXT",
      "description": "The title of the source document."
    },
    {
      "name": "source_type",
      "type": "TEXT",
      "description": "Paper, report, policy document, technical spec, market analysis, or other source type."
    },
    {
      "name": "publication_date",
      "type": "DATE",
      "description": "The publication date or best available date from the source."
    },
    {
      "name": "main_claim",
      "type": "TEXTAREA",
      "description": "The primary claim relevant to the research question."
    },
    {
      "name": "supporting_metrics",
      "type": "ARRAY",
      "description": "Quantitative findings, percentages, ranges, or measured effects that support the claim.",
      "fields": [
        {
          "name": "metric",
          "type": "TEXT",
          "description": "The metric, number, percentage, or measured effect."
        },
        {
          "name": "context",
          "type": "TEXTAREA",
          "description": "Context needed to interpret the metric correctly."
        }
      ]
    },
    {
      "name": "methodology",
      "type": "TEXTAREA",
      "description": "How the source reached its conclusion: experiment, survey, benchmark, case study, analysis, or expert opinion."
    },
    {
      "name": "limitations",
      "type": "ARRAY",
      "description": "Limits, caveats, sample issues, missing context, or reasons the source may not generalize.",
      "fields": [
        {
          "name": "limitation",
          "type": "TEXTAREA",
          "description": "The limitation or caveat."
        }
      ]
    },
    {
      "name": "relevant_quotes",
      "type": "ARRAY",
      "description": "Short source quotes that support the extracted claim or limitation.",
      "fields": [
        {
          "name": "quote",
          "type": "TEXTAREA",
          "description": "The exact quote or near-exact source text."
        },
        {
          "name": "why_it_matters",
          "type": "TEXTAREA",
          "description": "Why this quote matters for the research question."
        }
      ]
    },
    {
      "name": "decision_implication",
      "type": "TEXTAREA",
      "description": "What this source implies for the research question."
    }
  ]
}

The schema is not a final report. It is the evidence table behind the report.

Once the evidence exists, the agent can compare sources, identify contradictions, and write a brief that points back to citations.

A Prompt That Produces Evidence, Not Summaries

The prompt should force the agent to separate evidence extraction from recommendation writing.

Read these research PDFs for the question: should we prioritize enterprise security features or onboarding improvements next quarter?

Use the Iteration Layer MCP tools for document-to-markdown conversion, structured evidence extraction, document generation, and spreadsheet generation.

For each source, convert the document to markdown first if full context is needed. Extract source title, publication date, main claim, supporting metrics, methodology, limitations, relevant quotes, and decision implication.

Do not write the final brief until the evidence table is complete. If a source makes a claim without supporting evidence, mark it as weak. If sources contradict each other, keep both positions and cite them.

After the evidence table is complete, generate a decision brief with:
- executive recommendation
- evidence table
- strongest supporting claims
- contradictions and weak evidence
- open questions
- source list

That prompt changes the agent’s job. It no longer produces a summary pile. It produces a reviewable decision artifact.

Source Evidence Needs a Policy

Source references are not optional in research workflows.

The brief should preserve:

• Source document name.
• Relevant quote or citation text.
• Page or section context where available.
• Confidence or evidence quality.
• Whether the claim is direct evidence, interpretation, or background context.

This matters because generated briefs are persuasive. A fluent recommendation can make weak evidence look stronger than it is. A citation policy gives the reviewer a way to challenge the output.

For example, a metric from a benchmark table should not be treated the same as a number mentioned in a related-work section. A market forecast from a vendor report should not be treated the same as observed customer behavior. The agent can help separate those cases if the schema asks for methodology and limitations.

Contradictions Are First-Class Output

Many research workflows hide contradictions because the user asked for a clean answer.

That is a mistake.

If two sources disagree, the brief should show the disagreement and explain why it may exist:

• Different populations.
• Different time periods.
• Different methodology.
• Different geography.
• Different definition of the measured outcome.
• One source is vendor-authored and another is independent.

Contradictions are not failures. They are often the most useful part of the research output because they show where a human decision is required.

A good agent workflow should produce a section like:

Contradiction: Enterprise buyers prioritize security review speed, but SMB evaluators abandon onboarding when setup takes more than one session.

Source A: Enterprise procurement survey, 2026, reports security review as the main blocker.
Source B: Product onboarding analysis, 2025, reports setup abandonment as the main conversion loss.

Interpretation: The evidence supports different priorities for different segments. The roadmap decision depends on which customer segment the team is optimizing for next quarter.

That is much more useful than a blended summary.

The Brief Is Not a Transcript

A decision brief should be structured for the person who owns the decision.

A useful format is:

• Executive recommendation.
• Decision context.
• Evidence table.
• Strongest supporting claims.
• Weak or conflicting evidence.
• Open questions.
• Recommendation options.
• Source list.

For product teams, the recommendation may end with roadmap implications. For agencies, it may end with client recommendations. For investors, it may end with diligence risks. For policy teams, it may end with options and tradeoffs.

The workflow is the same: context, evidence, synthesis, reviewable recommendation.

Human Review Still Matters

Do not let an agent turn research into decisions without review.

The agent should create the first structured pass: the evidence table, contradiction map, draft recommendation, and list of uncertainties. A human should review source citations, challenge weak evidence, and decide what the recommendation means.

Human review is faster when the agent has done the right prep work. The reviewer can inspect the evidence table instead of rereading every PDF from scratch. They can focus on whether the evidence supports the conclusion.

That is the real time saving: not skipping judgment, but moving judgment to the right layer.

When Not to Use an Agent

An agent is not always the right tool.

Use a deterministic pipeline when:

• The same document type is processed repeatedly.
• The output schema is fixed.
• The workflow runs unattended.
• The result updates production systems.
• Compliance requires a narrow, testable processing path.

Use an agent when:

• The research question changes.
• Source material varies widely.
• The agent needs to inspect context before deciding what matters.
• A human will review the output before it affects a decision.
• The workflow is exploratory or advisory.

This is the MCP first, REST later split. Use MCP to design and explore the workflow. Move stable, repeatable processing into REST or SDK calls.

Where Iteration Layer Fits

Iteration Layer is useful when the research workflow needs more than file chat.

The workflow usually needs multiple operations: convert PDFs to Markdown, extract structured evidence, generate a brief, and sometimes create an evidence workbook. Iteration Layer exposes those steps through one MCP server and the same APIs for production code.

If your only need is summarizing one text document, a model with file upload may be enough. If your research workflow needs citations, structured fields, generated documents, and repeatable handoff into code, a composable content-processing platform fits better.

The tradeoff is scope. A specialized academic search product may be better for literature discovery. Iteration Layer is for processing the documents you already have and turning them into structured, generated outputs.

The Research Agent Checklist

Before trusting a research agent output, check the workflow:

• Did the prompt start with a decision question?
• Were PDFs converted into readable context before extraction when needed?
• Does the evidence schema capture claims, metrics, methodology, limitations, and quotes?
• Are contradictions preserved instead of averaged away?
• Does the brief cite source evidence?
• Are weak claims labeled as weak?
• Are open questions visible?
• Is a human reviewing the evidence before acting on the recommendation?
• Which parts should move from MCP exploration into production code?

If the answer is yes, the agent is not just summarizing PDFs. It is building a reviewable path from source material to decision.