Why AI Document Workflows Are Broken

Part 1 of 3 in a series on AI-native document formats

Every AI tool that works with documents treats formatting as disposable. Feed a Word document in, get edited text back, and accept that the heading styles, brand fonts, and table alignment won't survive the round trip. Rebuild it yourself.

For a single document, that's annoying. For an organization running hundreds of documents through AI editing pipelines, it's a structural cost that nobody is tracking and everybody is paying.

The Formatting Death Spiral

The pain isn't one bad round-trip. It's what happens when documents go through multiple AI interactions.

A document gets touched by AI four, five, six times over its lifecycle. Each round, someone converts the content to a format the AI can work with, feeds it in, gets the output, and reconstructs the original. Every cycle loses something.

Heading styles drift. Custom fonts revert. List numbering resets. Table formatting degrades.

By the fifth round, the document barely resembles the original template. Someone (usually the most junior person on the team) spends an hour or two restoring what the AI destroyed. This happens on every document, every cycle, across the entire organization.

The teams that feel this hardest are the ones where formatting isn't cosmetic. Consulting firms producing branded client deliverables. Legal teams editing contracts where numbered clause indentation carries meaning. Compliance departments maintaining document libraries that need to look exactly right.

For these teams, formatting is part of the deliverable. Breaking it isn't an inconvenience. It's rework that eats margin and delays delivery.

Why "Just Convert to Markdown" Doesn't Fix This

The standard answer is: extract the text, let the AI work with it, put it back. That's what every tool in the space does.

Pandoc is the workhorse. If you've used Claude or any other LLM to read or create a Word document, Pandoc was probably doing the conversion under the hood. It converts beautifully in either direction. But the round trip is lossy.

Your heading styles come back as generic defaults. Your custom fonts vanish. Your branded template is gone. Pandoc was designed for format conversion, not format preservation. Those are different problems.

The rest of the landscape doesn't even attempt the round trip. Microsoft's MarkItDown extracts text from docx files into markdown for LLM consumption. One direction only. Tools like Pactify and MassiveMark go the other direction, converting AI-generated markdown into new Word documents. Also one direction.

So you have Pandoc, which can go both ways but loses formatting, and everything else, which only goes one way. No tool in the current landscape maintains a persistent link between the formatted document and its AI-editable representation.

The real issue isn't conversion. Conversion is a solved problem. The issue is that conversion is lossy and the loss compounds. Run a document through Pandoc's round trip once and you might not notice the damage. Do it five times and the document is unrecognizable.

The Gap Nobody Owns

I've spent most of my career in the space between complex systems. Twenty-plus years of cloud architecture, enterprise integration, making things work together that weren't designed to. This problem has the same shape as every integration gap I've seen: two communities building excellent tools that don't connect.

The AI tooling community is focused on agents, RAG pipelines, function calling, model orchestration. Documents are an input they need to consume, not a first-class concern. The assumption is that someone else handles the messy business of getting content in and out of Word files.

The document processing community is focused on conversion fidelity, format support, rendering accuracy. They've been building converters and processing libraries for decades. But they're optimizing for human workflows: author a document, convert it, deliver it. The idea that a document might pass through an AI editing loop dozens of times wasn't a design consideration for any of these tools.

Nobody is building the bridge between "AI needs cheap, clean text" and "humans need formatted, branded documents." Both sides have good tools. The round-trip between them is where everything falls apart.

This pattern should look familiar to anyone who's worked in enterprise integration. Two systems work fine in isolation. The interface between them is where the value leaks out. And the longer the gap persists, the more workarounds accumulate, each one adding friction and fragility.

The Complexity Tax

There's a reason this hasn't been fixed, and it isn't lack of effort.

The OOXML specification that underpins .docx files is enormous. I didn't fully appreciate this until I started digging into the format internals. A single paragraph in a Word document isn't just text with a style attached. It can carry dozens of formatting attributes: font family, size, weight, color, spacing, indentation, style references, and run-level overrides that vary at the character level.

A heading that appears as 24pt Montserrat Bold in the rendered document might inherit its font from a named style, its size from a direct formatting override, and its color from the document theme. Three separate sources for what looks like one simple heading.

Preserving all of that through a markdown round-trip means understanding how Word's style inheritance actually resolves, storing every layer of formatting separately from the content, and reapplying it correctly on rebuild. That's not a weekend project. It's a format design problem.

Most tools don't attempt it because the effort-to-reward ratio looks bad. If you're building an AI tool, your value is in the AI, not in rebuilding Word's formatting engine. If you're building a document converter, your users want fast, accurate conversion, not indefinitely repeatable round-trips. The problem sits in the overlap of two domains and is fully owned by neither.

What Would Actually Solve This?

Strip the problem down to fundamentals, and a real solution needs four things.

Two representations of the same document. One optimized for AI: small, clean, cheap to process. One optimized for humans: formatted, branded, familiar. Markdown and docx, respectively, because those are what each audience already uses.

A persistent link between them. Not a one-time conversion, but a maintained mapping so changes to either representation can propagate to the other. The formatting metadata has to live somewhere separate from the content, where it can be reapplied after each edit without degrading.

Indefinite repeatability. The tenth round-trip has to preserve formatting as faithfully as the first. No cumulative degradation. This is the requirement that kills most approaches, because it demands that the format metadata be complete enough to reconstruct the original formatting from scratch, every time.

Minimal overhead. If the solution adds significant complexity or cost, teams will keep doing what they're doing now: eating the formatting loss or absorbing the manual repair time.

This is the problem I've been working on. The idea actually came from an unexpected direction, which I'll get into in Part 3 of this series.

The short version: I started building a document format that treats content and formatting as separate concerns, synced through a shared structure map. The AI works with clean markdown. The formatting lives in metadata. Changes flow in both directions without loss.

In the next post, I'll walk through the architecture, the design decisions, and the data showing that the approach works.

Three Questions for Your Team

If your organization uses AI to edit Word documents, these are worth asking:

• How many round-trips does a typical document take? Count the number of times a document passes through AI editing before it's done. That number is your multiplier on every cost and fidelity problem described above.
• How many hours per week go to formatting repair? Track the time spent manually restoring formatting after AI edits. This cost doesn't show up in API bills, but it shows up in your team's capacity.
• What's your actual token cost per document? If your pipeline sends raw document XML to the model (some do, and the waste is staggering), compare that to the token count of just the text content. The gap is pure overhead.

The AI document problem grows with adoption. The more content your organization pushes through AI pipelines, the more you pay the formatting tax. The question isn't whether this needs a better solution. It's how long you absorb the cost before finding one.

This is Part 1 of a three-part series on AI-native document formats. Part 2: The Design Decisions Behind an AI-Native Document Format covers the architecture and the data. Part 3: What I Learned Building a Document Format from Scratch covers the builder's perspective.