Coverage Annotations in Synthesis: Flagging Gaps in Agent Output

What coverage annotations in synthesis are

Coverage annotations in synthesis are the notes an agent attaches to its final output describing how complete and well-supported each part of it is. When a coordinator merges findings from several subagents into one report, some parts will rest on solid, multi-source evidence and others will be thin, partial, or entirely missing because a source could not be reached. A coverage annotation makes that variation explicit. Instead of a uniform-looking report that implies every section is equally researched, the reader sees exactly where the confidence is and where the holes are.

This is an apply-level knowledge point: the exam expects you to take a situation with partial coverage and produce the right annotated output. It builds on two hard prerequisites. From the workflow termination anti-pattern you learned to continue with partial results rather than abort; coverage annotations are the obligation that makes continuing honest. From structured error context you learned to capture why a piece failed; the annotation is where that reason surfaces in the human-readable output.

Why an unannotated gap is a silent lie

The hazard is the same one that powers the silent suppression anti-pattern, arriving at the level of the final report. When a section is simply left out, the reader has no way to distinguish "this topic was researched and there was little to say" from "this topic was never covered because the source was down." Both produce a report without that section. The omission reads as a deliberate editorial choice rather than a gap, so the reader trusts a document that is quietly incomplete and makes decisions on it accordingly.

Anthropic's guidance on reducing hallucinations makes the underlying principle concrete: you should explicitly allow the model to admit uncertainty, to say "I do not have enough information to confidently assess this", and to mark where a claim could not be supported rather than inventing one. A coverage annotation is that principle applied to a multi-source synthesis. The same engineering write-up of Anthropic's multi-agent research system shows the system grading its own output on completeness, are all requested aspects covered, which only works if incompleteness is something the system is willing to surface rather than paper over.

How to write a useful annotation

A good coverage annotation does three things: it identifies the affected section, states that it is limited or missing, and gives the reason in concrete terms. Compare two ways of handling a research report whose geothermal-energy section could not be completed because a key journal was paywalled. The unhelpful version simply has no geothermal section, leaving a five-topic brief looking like a complete four-topic brief. The helpful version keeps the heading and writes: "Coverage note: the geothermal-energy section is limited because the primary journal source was unavailable; findings here are based only on secondary summaries." That single sentence tells the reader precisely how much weight the section can bear.

Crucially, the annotation distinguishes the kind of gap, which is where the access failure versus valid empty result distinction pays off. "We searched and found no relevant studies" is a valid-empty finding and a legitimate, complete answer. "We could not reach the source" is an access failure and a genuine gap. A precise annotation says which one it is, because the reader will act very differently on "there is nothing to find" than on "we could not look."

Where annotations live in the pipeline

Annotations are assembled from information that has to be preserved all the way through the pipeline, which is why this knowledge point depends on the ones before it. When a subagent hits an access failure, it returns structured error context. The coordinator, rather than discarding that context once it decides to continue, carries it into the synthesis as a coverage note. So the chain is: capture the failure as structured context at the leaf, continue past it instead of terminating, and then surface it as an annotation in the output. Drop the context at any link and the annotation becomes impossible, which is how well-intentioned partial-results handling quietly degrades back into suppression.

There is also a discipline question about when to annotate. The honest answer is that the decision is made continuously, not at the end. Each time the coordinator chooses to continue past a failure rather than retry it to success, it is incurring a coverage debt that the final output has to repay with a note. Treating annotation as an afterthought, bolted on while formatting the report, is how gaps get forgotten, because by then the failure may be several steps in the past and its details lost. Recording the annotation at the moment the decision to continue is made keeps the note accurate and removes any temptation to quietly tidy the gap away once the report starts to look finished.

This also connects to provenance more broadly. Knowing which claims are well-supported requires knowing where each claim came from, which is the concern of attribution and source-mapping elsewhere in Domain 5. Coverage annotations are the reliability-facing half of that same discipline: provenance answers "where did this come from," and coverage annotations answer "what is missing and how sure are we." Together they let a synthesis be trusted not because it looks polished but because its boundaries are stated.

Designing a consistent annotation format

Applying this knowledge point well means having a repeatable format rather than improvising a caveat each time, and a good format captures four fields. The first is the location: which section, claim, or topic the annotation refers to, stated precisely enough that a reader knows exactly what is affected. The second is the status: whether that location is complete, partial, or missing. The third is the reason: a concrete explanation such as a source being unreachable, a document being paywalled, or a query returning too little to draw conclusions. The fourth is the gap type: whether this is a genuine no-data finding or a true gap where the source could not be consulted, since those carry very different weight for the reader.

Placement matters as much as content. An annotation buried in a footnote or stacked at the very end of a long report is easy to miss, and a missed annotation is functionally the same as no annotation. The strongest convention is to put the note at the top of the section it describes, so a reader encounters the caveat before the content it qualifies rather than after. Sections that are fully supported get no annotation at all, which keeps the signal meaningful: a caveat appears only where confidence is genuinely reduced, so its presence carries real information.

It is also worth deciding whether annotations are prose, structured data, or both. A human-readable sentence serves the reader directly, but a small structured record, location, status, reason, gap type, lets a downstream system or a reviewer aggregate coverage across many sections and flag a report that is too thin to act on. In a pipeline that already carries structured error context from each subagent, producing the structured annotation is nearly free, because the information needed is exactly what the failing nodes already reported. Building the format once and reusing it everywhere is what turns honest degradation from a good intention into a dependable property of the system.

Prompting the model to surface gaps

Coverage annotations only appear if the system is actually instructed to produce them, and Anthropic's prompting guidance offers two concrete levers for that. The first is to tell the model to report every issue or gap it finds, even low-severity or uncertain ones, because at the synthesis stage the goal is coverage rather than filtering. A model left to its own editorial judgement tends to tidy weak or partial findings away so the output reads cleanly, which is exactly the silent omission this knowledge point exists to prevent; an explicit instruction to favour coverage over polish reverses that default.

The second lever is to have the model ground its claims in quotes from the source material before it synthesises. Separating the evidence it actually found from the prose it writes makes unsupported areas visible: a section with no quotes to stand on is one the model can flag as thin rather than pad with confident-sounding generalities. Combined with the documented practice of allowing the model to admit uncertainty, these prompt-level controls are what turn coverage annotation from a hope into a dependable property of the output, because the model is told to surface gaps instead of being trusted to volunteer them.

Common misconceptions

How it shows up on the exam

Expect an apply-style item built on the Multi-Agent Research System or Structured Data Extraction scenario: a synthesis step has partial coverage and you must choose how the output should represent it. The distractors will favour a tidy, complete-looking report or a silent drop of the weak section. The correct answer keeps the gap visible with a specific, reasoned annotation. If you can write the annotation yourself, section, status, reason, and which kind of gap, you have the applied competence this knowledge point assesses, and you are ready for the full strategy design that combines it with everything else in the task statement.

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

Discover AI

Anthropic's Secret: How we Build Multi-Agent AI

Why watch: Covers how Anthropic's research orchestrator synthesizes subagent findings and continues with partial results, motivating why synthesis output should annotate which areas are well-supported versus where coverage gaps exist rather than silently omitting them.

More videos for this concept

Anthropic's Secret: How we Build Multi-Agent AI

Discover AI

How We Build Effective Agents: Barry Zhang, Anthropic

AI Engineer

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

AI Engineer