Asking a model to write a forty-page report in one call invites drift: sections that repeat, a table of contents that promises chapters that never arrive, formatting that wanders. The assembly pattern splits the job. Your application defines the document skeleton — sections, their inputs, their acceptance criteria — and makes one focused model call per section. Code then assembles the pieces. The result is repeatable, individually retryable, and much easier to review.
Skeleton first, prose second
Represent the report as a template your code owns: an ordered list of sections, each with a heading, the source data it draws on, target length, and any fixed boilerplate that is injected verbatim (legal disclaimers should never pass through a model at all). The table of contents is constructed by code from the skeleton, never generated — same for page numbering, cross-reference anchors, and section numbering. If a reader can diff two months' reports and see structure change, that change should trace to a template commit, not to model variance.
Generate sections with a shared, cached context
Each section call sends the same foundation — report-wide instructions, style guide, and the common source material — plus that section's specific data and brief. Structure the prompt so the shared part is a byte-identical prefix and mark it with cache_control: {"type": "ephemeral"}: the first call writes the cache at 1.25x input price and every subsequent section reads it at 0.1x, which is what makes per-section generation affordable rather than wasteful. Follow the long-context guidance while you're at it: source material at the top, the section brief and question at the end (this ordering can improve response quality by up to 30%). One warning from the caching docs applies directly to fan-out: a cache entry becomes readable only after the first response begins streaming, so generate section one, then fan out the rest — parallel-firing all sections at once pays full price on every one.
For scheduled reports where nobody is waiting on a screen, run the fan-out through Anthropic's Message Batches API at 50% of standard prices, using each section's ID as the custom_id so results map back to skeleton slots; most batches finish within an hour, and the docs recommend the 1-hour cache TTL for shared context in batches. Current models leave generous headroom per section — up to 128K output tokens on Opus 4.8 and Sonnet 5 class models.
Validate each section before assembly
Between generation and assembly, run a per-section gate in code: required subsections present, length within bounds, no placeholder text, every figure it cites present in its source data. A failed section is regenerated alone — the other nineteen are untouched, which is the operational payoff of this pattern. See output validation and self-correction loops for the retry-versus-escalate rules.
Producing the final document
If the deliverable is HTML, Markdown, or PDF-via-your-toolchain, plain code concatenation finishes the job. If you need native Office formats, Anthropic's pre-built Agent Skills generate real files: request the docx, pptx, xlsx, or pdf skill via the container parameter (beta headers code-execution-2025-08-25 and skills-2025-10-02, with the code execution tool in tools). Generated files come back as file IDs you download through the Files API; long-running generation can return stop_reason: "pause_turn", which you continue by sending the response back within the same container.
Platform availability
| Capability | Claude API | Claude Platform on AWS | Bedrock | Vertex AI | Foundry |
|---|---|---|---|---|---|
| Prompt caching | GA | GA | GA (explicit breakpoints) | GA | GA |
| Message Batches API | Yes | Yes | No (S3-based batch instead) | No (BigQuery/GCS batch instead) | No |
| Agent Skills + code execution | Beta | Beta | No | No | Beta |
| Files API (download outputs) | Beta | Beta | No | No | Beta |
On Bedrock and Vertex AI, the document-file step moves into your own code (an Office-generation library consuming the model's Markdown), while section generation and caching work natively. That split — model prose everywhere, file rendering where skills exist or in your toolchain — keeps the pipeline portable.
Where to go next
See Agent Skills for the skills mechanics, the summarization pipeline for the input side of many reports, and scheduled batch jobs for the cron wrapper. The feature matrix covers availability.