The last mile is mostly solved. Modern language models write LaTeX fluently from pretraining, and a compile step turns that source into a typeset PDF. But there is a moment between "the agent writes LaTeX" and "here is your PDF" that almost nobody instruments: the agent gets it wrong on the first try about half the time. What happens in the next few seconds decides whether it finishes the document or quietly falls back to a screenshot of an HTML table.
We sit at the compile step, so we see that moment for real traffic. This is an early look - the first few hundred documents through a compiler built for agents, not a large sample - but the patterns are already clear, and they are more useful than a benchmark.
What agents actually get wrong
The failures are not exotic. They cluster into a short list of predictable seams where an LLM's LaTeX meets a real compiler.
Markdown fences. The single most common failure we see. The agent wraps its LaTeX in a code fence - the format it emits everything in - so the output starts with three backticks and the word latex. The document underneath is usually fine, but the fence lands on line 1 and LaTeX dies with "Missing \begin{document}". In our logs it shows up literally as the first source line being a lone backtick.
Undefined commands and missing packages. The agent reaches for \toprule or \href without loading booktabs or hyperref. Pressa ships a fixed TeX Live set, so the fix is to name the package, or to rewrite without it.
An \item with no list around it. Common in CV and resume templates, where the entries are not wrapped in the list the template defines.
Font Awesome 6 names under Font Awesome 5. \faMapMarkerAlt is undefined even with the icon package loaded, because that is the Font Awesome 6 name and the shipped package is version 5, which calls it \faMapMarker. "Add the package" would be a confident wrong answer here.
The wrong engine. A resume that uses fontspec compiled with pdflatex instead of xelatex. No amount of editing the document fixes it; the source is correct and the engine is wrong.
A raw TeX log is useless to an agent
When a compile fails, the classic response is the raw log: hundreds of lines of font-loading banners with the real error buried in the middle, marked by a single exclamation point. A human skims for the exclamation mark. An agent handed 400 lines of TeX output has to guess, and a wrong guess costs a round trip. An agent that needs four guesses to produce one PDF picks a different tool next time.
So alongside the raw log, Pressa returns a structured diagnosis: the error class, a suggested fix written to be acted on, and whether the same request is worth retrying. For the wrong-engine case above, that looks like this:
{
"status": "compilation_failed",
"diagnosis": {
"error_class": "wrong_engine",
"summary": "Needs the xelatex or lualatex engine, got pdflatex.",
"suggested_fix": "Retry the SAME source with compiler xelatex.",
"retryable": true
}
}The agent does not have to parse the log. It flips one field and retries. The one rule the diagnosis holds to: say nothing when unsure. A confident wrong suggestion is worse than silence, because it sends the agent down a dead end and still costs the round trip.
The loop closes in seconds
The reason this matters shows up in the recovery data. Of the agents that hit an error, five of six went on to produce a PDF. And they recover fast: the fixed retry lands in seven, nine, sixteen seconds and corrects exactly the error that was diagnosed. Nobody strips a markdown fence and resubmits in seven seconds. That is an agent reading a machine-readable fix and acting on it, not a person reading a log.
About half the agents get a valid PDF on the very first attempt, and most of the rest converge in one or two more. One workflow took nine tries before it settled - the honest tail of a real distribution. The shape of that curve, not the compile success rate, is the number that decides whether an agent comes back.
Why we treat error messages as a product surface
For an agent tool, the metric that matters is not "did it compile." It is how many attempts stand between the request and the first usable PDF. A compiler that returns an exit code competes with every free option the agent already has. A compiler that returns the fix is infrastructure. The error response is not stderr for a human to read later; it is an input to the agent's next action, and it is where an agent-native tool is quietly built or lost.
Getting Started
Pressa is free to start. The free tier includes 50 compilations per month, enough to wire up an agent workflow and watch it converge.
1. Create a free account and get your API key.
2. Install the CLI or configure the MCP server from the documentation .
3. Ask your agent to generate a document. It already knows LaTeX - and when it slips, it gets a fix, not a stack trace.