After working on that for a while, we've decided to shift focus and work on the DOCX angle. We felt there's a big opportunity here since .docx is such a widely used format.

As to the feature complete point - I agree. We already cover the most common features today (paragraphs, lists, tables, tracked changes, header/footer) and we're working hard on implementing more. Our main focus right now is to be the most accurate, cheapest and fastest solution out there for common scenarios.

Where I think it can break (and we show some of that in the benchmark post, though not on EigenPal specifically) is on tricky document edits, like multi-turn track changes, implicit style understanding (respecting surrounding styles without being told to), advanced list manipulation, etc. We also saw these problems get amplified on long-horizon, challenging document workloads.

Eventually we realized no product out there truly handles the wide variety of cases agents run into, so we set out to build one.

So to answer your question, it depends. If your documents are simple and you're happy with the results, stick with what works. But if you have tricky documents and find yourself chasing the N-th edge case, I think delegating that to something like our product makes sense.

For example, you could keep python-docx for the easy stuff and fall back to a Vespper-based approach when your agent hits errors filling the document. However, the end goal is to completely free your agent from python-docx and low-level work, so it can just focus on what goes into the template.