The most common failure mode in modern AI agent deployments isn’t hallucination or latency—it’s the export gap. Your agent generates a perfect, nuanced quarterly analysis, but the user stares at a chat window because they need a .docx for the board pack. A new technical deep-dive from the Head of SI Agents at Magnus argues that relying on server-side rendering for these file exports is an architectural antipattern. By shifting file generation entirely to the browser, developers can eliminate privacy risks, slash compute costs, and deliver the actual artifacts users demand.
The Golden Rule: Schema Over Syntax
The core engineering principle here is strict separation of concerns: never let the LLM generate the file format directly. Large language models are terrible at maintaining consistent XML, JSON, or binary structures over long contexts, leading to corrupted files. Instead, the agent should output structured JSON that conforms to a developer-controlled schema. This allows the frontend to map that data into four distinct rendering functions—Word, Excel, PowerPoint, and PDF—using mature libraries. If the model hallucinates a table structure, schema validation catches it before the file is even attempted, preventing the user from receiving a broken download.
The Client-Side Stack That Works
The article outlines a specific, battle-tested library stack for browser-based exports. For Word documents, the docx package handles the XML complexity, allowing developers to map JSON sections directly to Paragraph and HeadingLevel objects. Excel exports rely on SheetJS (xlsx), though the author warns that the npm registry version is outdated; developers must pull from the project’s own CDN to get current features. PowerPoint generation is handled by PptxGenJS, which is praised for its friendly API, while jsPDF serves simple report needs. A critical gotcha noted is that jsPDF’s default fonts fail on non-Latin scripts like Japanese or Arabic, requiring embedded font files to avoid post-launch disasters.
Why Your Server Should Stay Out of It
Beyond the code, the architectural argument rests on three pillars: privacy, cost, and simplicity. When file generation happens client-side, sensitive data—like quarterly financial numbers or internal deal logs—never touches your infrastructure. This simplifies compliance and privacy policies significantly. Furthermore, file rendering is CPU-intensive work; offloading it to the user’s laptop is the cheapest compute resource available. There is no need for job queues, storage buckets, or 'your file is ready' email notifications. The user clicks a button, the browser does the work, and the file downloads instantly.
Key Takeaways
- Never trust the LLM with file formats: Always output JSON and render files via code.
- Privacy by architecture: Client-side generation ensures data never leaves the user's machine.
- Lazy load your exporters: These libraries are heavy; use dynamic imports to keep bundle sizes sane.
- Validate your data: Ensure numbers are numbers, not strings like '12 days', so Excel columns remain sortable.
The Bottom Line
Stop forcing users to copy-paste chat logs into Word. Build the export pipeline in the browser using JSON schemas and client-side libraries, and you will deliver files that actually open, sort, and present correctly on the first try.