How do you let AI edit an existing DOCX without breaking the formatting?

Short answer: never ask the model to produce a new Word file. Ask it for a short list of changes, each tied to an exact place in the original (a paragraph, a table cell, a placeholder), apply those changes to the original file with a library that edits in place, and show a person a before-and-after view before the file is saved or sent.

A recent r/AI_Agents thread asked exactly this: an agent updates a clause and a few table cells in an existing DOCX, so where does the human review happen, and how do you catch formatting changes, especially when the user has already made their own edits? (thread)

Why AI edits break Word files

A DOCX is a zip of XML. Text that looks like one sentence is often split across several "runs", each with its own font, bold or tracked-change markup.
When a model regenerates the whole document from plain text, everything it did not see (styles, numbering, headers, comments, the user's own edits) is lost.
Replacing a whole paragraph to change three words resets the formatting of the other words in it.
Reviewers who only get a new file cannot see what changed, so they approve by trust.

The pattern: propose, locate, apply, review

Extract, don't convert. Read the document into a list of addressable pieces: paragraph number and text, table and cell position and text, and any placeholders such as {{client_name}}. Keep the original file untouched.
Ask the model for a change list, not a document. Require JSON like {location, old_text, new_text, reason}. old_text must match the current text exactly.
Reject anything that does not match. If old_text is not found at that location, the user probably edited it since extraction. Skip the change and flag it; do not guess.
Apply changes at the smallest level possible. Replace text inside the existing run where you can, so the surrounding formatting stays. For table cells, write into the existing cell rather than rebuilding the table.
Save as a new version, never over the original. Keep both files, so a bad edit is one click to undo.
Show a redline before it goes anywhere. Either write the changes as tracked changes, or produce a simple comparison (Word's own Compare feature works) and send it to the document owner for approval.

Where the human review fits

Put the approval between step 5 and anything that sends, signs or publishes the file. The reviewer should see three things: the list of proposed changes with reasons, the redline, and any changes that were skipped because the text had moved. That last list is what catches the "user already edited it" case from the thread.

Tools that fit this pattern

Python (python-docx) in an n8n Code node or a small service can read paragraphs, runs and table cells and edit them in place.
Template engines (for example docxtemplater in JavaScript) are a better fit when the document is a template you control: the AI fills placeholders and never touches layout.
Google Docs is easier if the team can work there: Make and n8n both have Google Docs modules that replace text in an existing document, and Docs keeps version history for you.

Quick test

Take a contract where the user has bolded one word inside a clause, then ask the workflow to change a different word in the same clause. If the bold disappears, your apply step is replacing the whole paragraph instead of the run.

Doing it in Make

A Make scenario can run the change list through an iterator, skip items whose old text does not match, and route the rest to a Google Docs "replace text" step and then an approval message, all without code. You can try it on the free plan: Make free plan.

Disclosure: Some links are affiliate links — I may earn a commission at no extra cost to you.