Archetype A: Research and Synthesis Agents

The shape of the problem

You need to compress information no single human has time to read, hundreds or thousands of sources, into structured analysis that a human will then make a decision on top of. Competitive intelligence: what are fifty competitors actually doing? Regulatory scanning: what's changing across twelve jurisdictions? Talent mapping: who are the two hundred people working on a given problem? If your project is "go figure out the landscape of X," you're in this archetype.

What makes it hard isn't the volume. It's that the output drives decisions, which means hallucination here isn't a quality issue. It's a strategic risk. An invented number in a deck that a decision-maker acts on is worse than no number at all.

Why the naive pipeline fails

The obvious approach (a list of sources, a loop with Claude, a spreadsheet, handed to decision-makers) fails in a predictable order. Claude invents a CEO, a number, a relationship, and it looks exactly as confident as the real facts next to it. Some entries end up thorough and some are stubs, with no way to tell which from the output alone. The model's training cutoff means the "current" CEO left months ago. A decision-maker asks where a number came from, and there's no answer. Even with real sources, the model sometimes misreads them. And because there's no regression testing, re-running the pipeline gets you different answers with no way to know which run was right.

The result is plausible-looking, unreliable output, which is worse than obviously bad output, because nobody catches it until week fourteen, when someone finally asks where a number came from and the whole deliverable's credibility collapses at once.

The single highest-leverage decision: who assembles the input list

Here's the thesis of this lesson, stated directly: the biggest mistake in Archetype A is letting the AI generate its own input list. If the AI decides what to research, you have no way to know what it missed. You're optimizing on incomplete data without knowing it's incomplete. Everything else below (the manifest, the tool constraints, the verifier, the review queue) exists to make one discipline enforceable: the AI's job is to research items on a list you control, never to write that list itself.

The right approach is unglamorous. Spend day one assembling a curated list from authoritative sources:

Spending one day on a clean input list saves weeks of cleaning bad data downstream. Get the input list right in week one and the rest of the project is execution. Get it wrong and you spend the remaining weeks patching a foundation that should never have needed patching.

The five-component architecture

Five components, each small, each critical. Skip any one of them and the system degrades back toward the naive pipeline.

Component 1: structured input curation

Covered above: the list comes from authoritative sources, never from the model.

Component 2: the per-item manifest

Every researched item produces a manifest: one YAML file, every field carrying a value (or explicitly unknown), a confidence level, and sources.

item_id: "EU-CPO-DE-001"
researched_at: "2026-05-15T14:32:00Z"
researcher_session: "sess_a3f9c2"
researcher_model: "claude-sonnet-4-6"

fields:
  legal_form:
    value: "Federal procurement office"
    confidence: high
    sources:
      - url: "https://www.bescha.bund.de/about"
        accessed: "2026-05-15T14:30:00Z"
        excerpt: "Das Beschaffungsamt des BMI ist..."

  annual_spend_volume_eur:
    value: 8200000000
    confidence: medium
    sources:
      - url: "https://www.bescha.bund.de/jahresbericht-2024"
        accessed: "2026-05-15T14:31:00Z"
    notes: "2024 figure; 2025 not yet published"

Three things here are essential, not decorative. Every field with a value has a source attached, not optional: the verifier below rejects manifests that skip it. "Unknown" is a first-class, legitimate value: the agent can say it couldn't find something, and that's a correct output, not a failure to route around. And every claim cites a URL with an excerpt, so when someone eventually asks where 8.2 billion came from, the answer is one click away instead of a shrug.

Component 3: the constrained tool set

Don't give the agent free range over the internet. Constrain what it can touch:

The CLAUDE.md for this agent states the constraint in one line: every claim must come from a source you can cite; if you cannot find a source, mark the field unknown; hallucination is the only unforgivable error. mark_unknown is the tool most teams forget to add. Without a graceful way to admit ignorance, the agent has no alternative but to make something up. Give it the tool to say "I don't know," and it uses it, which prevents most hallucinations before the verifier ever has to catch them.

Component 4: the deterministic verifier

Roughly fifty lines of Python, no LLM calls, runs in CI on every manifest.

def verify_manifest(manifest: dict) -> ValidationResult:
    errors = []
    warnings = []

    for field_name, field in manifest["fields"].items():
        # Every claim needs a source
        if field.get("value") is not None and field.get("confidence") != "unknown":
            if not field.get("sources"):
                errors.append(f"{field_name}: claim without source")

        # Sources must be live URLs
        for source in field.get("sources", []):
            if not is_url_alive(source["url"]):
                errors.append(f"{field_name}: dead source {source['url']}")

        # Low confidence flags for human review
        if field.get("confidence") == "low":
            warnings.append(f"{field_name}: low confidence, needs review")

        # Optional: cross-field consistency rules
        # e.g. if 'annual_spend' > 1B, must have 'legal_form' set

    return ValidationResult(
        passed=len(errors) == 0,
        errors=errors,
        warnings=warnings,
    )

The verifier doesn't judge whether the data is correct. It judges whether the manifest is well-formed and provable, which is a different, easier, and fully solvable problem in about fifty lines. This is what "no manifest, no success" looks like in code: the agent can claim it's done all it wants, but the verifier decides whether that claim counts.

Component 5: the human review queue

The verifier sorts every manifest into one of three buckets.

Two rules make this queue actually work. The review interface shows only the flagged fields, never the whole manifest. Cognitive load determines whether reviewers catch real problems or skim past them, and showing everything guarantees skimming. And a human edit updates the manifest with confidence: human_verified, the highest tier any field can carry. In practice, a verifier that's doing its job flags roughly fifteen to twenty percent of fields, and a team of four people can review about a hundred flagged fields a day: that's your realistic throughput, not a number to guess at.

The trace: the deliverable behind the deliverable

Every research session writes JSONL, one event per line:

{"ts":"2026-05-15T14:30:00Z","event":"session.start","item_id":"EU-CPO-DE-001"}
{"ts":"2026-05-15T14:30:08Z","event":"tool.search_authoritative","query":"Beschaffungsamt BMI"}
{"ts":"2026-05-15T14:30:12Z","event":"tool.fetch_url","url":"https://bescha.bund.de/about"}
{"ts":"2026-05-15T14:30:25Z","event":"field.recorded","field":"legal_form","confidence":"high"}
{"ts":"2026-05-15T14:31:42Z","event":"field.marked_unknown","field":"ceo_name","reason":"register access denied"}
{"ts":"2026-05-15T14:32:00Z","event":"session.complete","fields_recorded":12,"fields_unknown":3}

A deliverable like this is judged partly on its content and partly on the rigor of the process behind it. The trace is that rigor made inspectable. When a stakeholder eventually asks how a number was produced, you show them the JSONL and let them read exactly what happened, source by source. Without it, the answer is a hand wave; with it, the answer is a log file.

Two failure modes from the coding-agent world

Archetype A runs long agent loops over many sources, which means two failure modes from coding-agent work apply directly here, both already named in the previous lesson.

Neither of these is a controlled study. Both are patterns two named practitioners have described publicly from shipping coding agents at scale, and they apply here because the underlying problem is the same: long-horizon agent execution with degrading attention, whether the agent is writing code or researching a procurement office.

Evaluating whether this is working

Archetype A can't be evaluated with one number. It takes three.

Decide upfront what accuracy rate you're willing to ship (95%, 99%) because that number changes the workflow. Sampling-based review is fine at 95%. At 99%, critical fields need full review, not a sample.

Cost reality

For a 200-item research run (roughly 30k input tokens plus 3k output tokens per session, with a 20% re-run rate), real Nebius EU pricing across four stacks:

The verifier costs nothing: deterministic Python, same for re-runs and the human review queue.

These are real Nebius EU prices captured at deck-authoring time, not a live or permanent price list — check current rates before citing these exact figures. What they illustrate matters more than the precise dollar amounts: the whole project costs under ten euros even on the premium stack, so your budget constraint in this archetype is iteration speed, not tokens. The same roughly six-times spread between premium and lean shows up here as it does in every archetype in this course: architecture matters more than model choice. And the practitioner move is to route by difficulty: use a premium model once, at the start, to design the manifest schema and extraction targets, then run the bulk of routine research sessions on balanced or lean, reserving premium reruns for the small fraction of items (often around 5%) where the verifier flags low confidence because evidence is scattered thin. The harness routes the spend; you don't have to guess.

Failure modes at a glance

Week one deliverable

By Friday of week one on an Archetype A project, you should have four things: an input list of fifty items assembled from authoritative sources, not AI; a frozen manifest schema in YAML, with fields, confidence levels, and source format defined; a verifier script, roughly a hundred lines of Python, running in CI on every manifest; and one end-to-end test: research a single item by hand, produce its manifest, run the verifier, watch it pass. Land those four artifacts by Friday and the rest of the project is execution. Skip any of them and you'll be patching the foundation later, under worse time pressure than you have now.