A PDF is a photograph of a document: final, read-only, nothing to change. Half the people we send one to want the opposite. They want to correct a number, add a row, cut a paragraph, and forward it. So we gave the fleet a small pipeline that returns real editable Word and Excel files instead, generated from data and validated against the Office schema before they go out.
What we built
The unit of work is boring on purpose: structured data in, editable Office
file out. You hand it a plain description of a document (title, sections,
tables) and get back a branded .docx. You hand it a list of
rows and get back an .xlsx with live formulas and a totals
line. Both open natively in Word, Excel, Google Docs and Sheets, and
LibreOffice. There is no Office install on the server, no headless suite to
babysit, and no PDF-to-Word conversion step that mangles the layout.
The demo in the kit builds two things an inclusion team would actually keep:
an editable placement decision pack, and a placements tracker where the
annual transport cost of each pupil is a live spreadsheet formula
(miles × trips × days × cost-per-mile), not a
number baked in at export. Change the mileage and the total moves, because
it is a real cell, not a picture of one. All the demo data is fictional, so
the kit runs standalone with nothing confidential in it.
Generate is not edit
The thing that prompted this was OfficeCLI, a single self-contained binary,
no Office install, that gives an agent a command line over Word, Excel and
PowerPoint. It is genuinely good, and it now sits in the fleet. But it is
built for the read side: open a file someone else made, inspect it, edit a
node, render it. When the job is to build a document from data,
driving it node by node is the long way round. For that, the native
libraries (python-docx, openpyxl) are simpler and
faster to write against.
So we split the work by which half of the problem it is. The libraries generate the file. OfficeCLI validates it against the OpenXML schema and renders the preview. Two tools, each doing the half it is good at, checking each other's work.
What the check caught
On the very first run, OfficeCLI's validate failed the Word
document. The table-cell shading we added to brand the header rows was
missing a required attribute (w:shd without its
val). Word renders it perfectly, so a screenshot would have
looked flawless and we would have shipped an off-spec file that could break
in a stricter reader. A schema check sees what the eye does not. One-line
fix, and it is exactly the kind of bug you want a machine to catch, not a
client.
There was a second, subtler catch, and it is the one gotcha in the kit. OfficeCLI keeps a document resident in memory after it opens one, for speed. If you then rewrite that file on disk with another tool, as this pipeline does, a read back through OfficeCLI serves the stale in-memory copy until you close the resident. The fix is to close it before you validate. Written down here so the next person does not lose ten minutes to a file that looks wrong on disk and right in the tool.
Why it matters
Most agent output today is either a chat message or a PDF, and both are terminal: the reader can read them and nothing else. The moment the reader is a colleague rather than an audience, that is the wrong format. Handing back an editable file changes the agent's role from author of a finished artefact to author of a starting point someone else finishes. For the sort of work we do, drafting the document that a human then owns and sends on, that is the format the work actually needs.
What's still off
This is deliberately narrow. It generates documents, workbooks and simple tables well; it does not do charts, embedded images, or PowerPoint yet, and the branding is one house style rather than a theme system. It also does not round-trip: it builds files, it does not merge an agent's edits back into a document a human has since changed. That is a real limitation for a collaborative loop and it is the obvious next piece. For now the claim is exactly the size of what shipped: agents can return an editable, schema-valid Office file built from data, and that alone closes the most common gap.
What's now in the stack
office_pack.py: the generator.build_docx(spec)renders a branded, editable Word document from a plain data structure;build_tracker(rows)renders an Excel workbook with live formulas and a SUM totals row.build_demo.py: builds the two demo deliverables, then closes any OfficeCLI resident, validates both against the OpenXML schema, and renders an HTML preview.- OfficeCLI wired in as the fleet's read, validate and render layer for Office files, alongside the generator.
- The kit on GitHub. Swap the spec and the rows for your own and you have a repeatable editable-file pipeline.