[Alan Yahya](https://www.linkedin.com/in/alan-yahya/)4 min read
Using AI makes it easy to let go of attention to detail. Making agent edits granular and trivial to investigate is part of a more satisfying AI UX.
Yet, this is a particularly challenging problem when it comes to version control for WYSIWYG documents, as they are highly coiled. DOCX for example, combines words, formatting and structure in its shared OOXML representation.
An interactive system needs to be able to reconcile harmless changes to the document (file changes that do not actually change the document as viewed, such as changes to the span nesting of a sentence), as well as connect changes to recorded actions: an AI proposal, the reviewer's decision, and the final application.
Recording these actions alongside full agent traces lets us attribute supported text ranges to their contributors. We can distinguish an AI agent’s edits from changes made by a human reviewer or other agents, even when they are working concurrently.
| Why retain each component? | ||
|---|---|---|
| Stage | Record to retain | Question answered |
| --- | --- | --- |
| Capture | Document/version, capture scope, payload format, time and raw hash. | Which source state entered the workflow? |
| Agent input | Run/session, pinned revision/hash, exact supplied context and model invocation where recorded. | What could the agent actually read? |
| Proposal | Target identity, original/suggested text, explanation and frozen evidence bindings. | What did the agent intend to change? |
| Review and apply | Reviewer, decision, applied wording, resulting revision/hash and exact operation identity. | What entered the saved document? |
| Later history | Subsequent transitions and supported surviving ranges. | Which contribution still explains the current words? |
Each agent edit should record what changed, where, and the before/after state. This lets reviewers check the intended effect and any other changes, then follow the linked run to establish authorship. Essentially, defence-in-depth, rather than a snapshot-only approach.
| Diff type | Example | What to compare |
|---|---|---|
| Text | “30 days” becomes “45 days”. | Aligned wording within the same paragraph or range, under a stated view of tracked changes. |
| Formatting-only | The words stay the same, but bold, font, spacing or indentation changes. | Direct properties and inherited styles; show the changed property and affected text. |
| Image-only: asset | A logo or scanned exhibit is replaced while its placement stays the same. | Resolve the image relationship and compare the media payload; show before/after previews. |
| Image-only: presentation | The same image is cropped, resized or repositioned. | Drawing properties and media. |
| Structure | A clause moves, a list level changes or cells are merged. | Node order, parent relationships and structural properties. |
| Notes, comments and links | A footnote changes, a comment moves to another range or a hyperlink gets a new target. | Referenced content or target, and its attachment to the document. |
| Serialization-only | XML prefixes or ZIP compression change without changing the interpreted content. | Exact bytes and normalized content, compared separately. |
By recording which paragraphs were added or modified at each version, alongside rejected proposals, we can follow their evolution over time. This gives us a basis for maintaining persistent graph, vector or simple metadata representations of our documents for information retrieval.