When an agent tries to write a PDF from scratch, it burns thousands of tokens reasoning about layout, fonts, and page breaks. There is a better division of labour ”” and it changes how you think about document generation in agentic workflows.
Most engineering teams building agentic workflows reach for the obvious solution: give the agent a tool that accepts some text, uses the model to produce styled HTML, and hands it to a headless browser. It works in a demo. In production, the economics are harder to ignore.
Generating a single formatted PDF this way requires the model to reason about the document's structure, select appropriate CSS properties, handle table layout, manage page margins, and produce valid HTML that a renderer will not reject. That reasoning costs tokens ”” typically 1,800 to 5,600 per document for the generation step alone. Add a system prompt that explains the brand's visual rules and rendering constraints, and the total lands between 3,000 and 8,000 tokens per PDF.
At current frontier model pricing, 8,000 tokens runs to roughly £0.06”“£0.24 per document depending on the model tier. Generate a hundred invoices in a monthly billing run and that becomes a meaningful line item ”” before factoring in the latency cost of asking the model to do something it was not primarily trained to do well.
"The model is good at deciding what data belongs in the document. It is not the right tool for deciding how a table row should look."
Token comparison
The cost difference is not marginal
Per-document token spend for a standard invoice, comparing direct HTML generation against delegating rendering to PDFox via the MCP server.
tokens per document
tokens per document
list_templates → get_template_schema → generate_pdfToken cost is measurable and predictable. Design drift is subtler. When the agent writes HTML directly, its output is a function of the model version, the system prompt, and the specific phrasing of the user turn. Any of those can change.
A model update in December might render column widths slightly differently. A prompt refactor in February ”” intended only to improve data extraction ”” accidentally changes the agent's description of the desired layout. A colleague adds two lines to the system prompt and the font-weight on invoice line items shifts from 500 to 400. None of these changes raise an error. They show up as visual regressions that reach customers before anyone notices.
Templates solve this by separating authorship. A designer or developer owns the visual definition, published through a review process. The agent owns only the data payload. The PDF that reaches your customer on the 1st of January looks identical to the one from the 1st of December ”” regardless of what changed in the model or the agent's system prompt between those dates.
Key insight
Templates are a versioning boundary. When you publish a new version of a template, it is an intentional, reviewable act. When a model updates its HTML generation behaviour, it is not.
MCP tool calls · JSON · ~420 tokens total
// MCP tool calls ”” agent sends data only
// 1. Discover available templates (~80 tokens)
{ "tool": "list_templates" }
// 2. Inspect schema for the selected template (~120 tokens)
{ "tool": "get_template_schema", "input": { "templateId": "tpl_invoice_standard" } }
// 3. Generate ”” agent fills data fields only (~220 tokens)
{
"tool": "generate_pdf",
"input": {
"templateId": "tpl_invoice_standard",
"data": {
"invoice": { "number": "INV-2026-0041", "date": "2026-05-26", "currency": "GBP" },
"client": { "name": "Ashwood Consulting", "address": "12 King St, Edinburgh" },
"items": [
{ "description": "API platform licence ”” June", "qty": 1, "unit_price": 950 }
]
}
}
}
// Total agent-side token spend: ~420 tokensPrompt-based approach · ~3,000”“8,000 tokens per document
// Prompt-based approach ”” agent writes the document itself
// System prompt must explain HTML structure, CSS rules, brand fonts,
// colour codes, table formatting, page-break behaviour, and more.
// Typical system prompt cost: 1,200”“2,400 tokens
// Per-document reasoning and HTML generation: 1,800”“5,600 tokens
// Total per document: 3,000”“8,000+ tokens
// Output is also volatile: a model update or prompt edit silently
// changes the rendered layout of every future document.Token estimates are illustrative ranges based on typical payload sizes at claude-3-5-sonnet and gpt-4o pricing tiers as of Q1 2026. Actual costs vary with model, prompt length, and document complexity.
Design consistency over time
What six months of production output looks like
Prompt-based rendering over time
Column widths in generated invoices shifted by ~4px across all output
Font weight on line items changed from 500 to 400 ”” noticed by a customer first
Page margins became inconsistent across document types for six weeks
Table borders appeared on some documents, absent on others, no clear pattern
Each change was invisible until a customer noticed.
Template via PDFox over the same period
Pixel-identical output for the same data and template version, regardless of model updates or agent prompt changes
Output changed on that date only, by design. Version history available in the PDFox dashboard.
One intentional change in six months. Zero unintended ones.
The practical boundary is clear once you see it. The agent is good at knowing which data belongs in the document: reading from a database, transforming records, applying business logic. It calls list_templates to confirm a matching template exists, get_template_schema to validate its payload, and generate_pdf to submit the job. Three tool calls. Under 600 tokens total.
PDFox handles everything after that ”” rendering, font loading, page layout, job queuing, and delivering a signed URL. The agent polls get_job and retrieves the download link. The PDF that comes back is the same one your design team approved, every time.
This is not an argument against capable agents. It is an argument for routing work to the right tool. Agents built on this pattern are faster, cheaper, and more predictable ”” and the document output is stable across every model update that will happen between now and whenever you next revisit the codebase.
Try it
Connect the PDFox MCP server to your Claude environment in under two minutes. The free tier covers 50 PDFs per month ”” enough to validate the pattern in your own agent before committing to the approach.
Free tier included. No card required. OAuth setup takes under two minutes.