DOCX editing API for AI agents

DOCX Editor is a foundation for custom document agents. It does not impose a model, prompt, tool catalog, or chat interface.

@docx-editor.dev/editor-api provides an Office.js-compatible document API. The React and Vue packages provide the editor UI. The Pro package adds tracked changes, comments, and review controls.

Your application connects these layers:

1. Your agent framework calls the tools that you define.
2. Each tool uses the document API to read or change DOCX content.
3. The editor UI shows the result to the user.
4. The user reviews, changes, accepts, or rejects the result.

This design works with Vercel AI SDK, another tool-calling framework, or your own agent loop.

Put deterministic document operations behind the agent

A language model should decide what to change. It should not manage OOXML relationships, numbering definitions, run boundaries, or package serialization.

Your application gives the agent a small tool catalog. Each tool calls the Office.js-compatible document API. The API runtime manages object proxies and batches. The document engine applies transactions and produces DOCX output.

The browser and server runtimes use the same document object model. They serve different product surfaces:

• The browser runtime applies agent operations to the document that a person can see and edit.
• The server runtime parses DOCX bytes, edits a detached document, and returns new bytes when saved.

Applications can reuse common tools across both runtimes. Host-specific tools must check runtime.capabilities. Neither runtime requires Microsoft Word, Office.js, or UI automation.

Each layer has one responsibility:

The model never needs to generate XML in this design. It works through focused operations such as search, replace, format, and comment. Deterministic code handles the document format.

Edit a DOCX file on a server

The server runtime takes DOCX bytes and returns edited DOCX bytes. It needs no Microsoft Word process or browser Document Object Model (DOM).

import { DocxEditor } from "@docx-editor.dev/editor-api";
 
const runtime = await DocxEditor.createServer(bytes, {
  author: "Contract agent",
});
 
try {
  await runtime.run(async (context) => {
    const matches = context.document.body.search("$50k");
    matches.load("items");
    await context.sync();
 
    for (const match of matches.items) {
      match.insertText("$100k", "Replace");
    }
    await context.sync();
  });
 
  const editedBytes = await runtime.save();
} finally {
  runtime.dispose();
}

The first sync() loads search results. The second applies every queued write as one transaction.

The editing API overview documents runtime ownership, capabilities, saving, and disposal. The Office.js compatibility guide lists the supported objects and methods.

Drive an open editor

The browser runtime connects to a document that a user already has open. Agent edits use the editor undo stack and appear in the document interface.

import { DocxEditor } from "@docx-editor.dev/editor-api/browser";
 
const runtime = DocxEditor.createBrowser(editor, {
  author: "Review agent",
});
 
try {
  await runtime.run(async (context) => {
    const matches = context.document.body.search("payment terms");
    matches.load("items");
    await context.sync();
 
    matches.items[0]?.insertComment("Compare this clause with the playbook.");
    await context.sync();
  });
} finally {
  runtime.dispose();
}

Browser comment writes need the Pro review module and an editable document. Your application decides which document text reaches the model.

Define narrow agent tools

The editing API exposes document operations, not model tools. Wrap only the operations that your workflow permits:

• read_document loads approved document text and structure.
• search_document returns explicit matches before a write.
• replace_text changes an exact range.
• add_comment anchors a review note to an exact range.
• save_document returns the edited bytes from a server runtime.

Each tool can perform its work inside one run() block. A refused operation returns a typed error, and the transaction leaves no partial edit.

With Vercel AI SDK, define each tool with tool() and an inputSchema. You can forward browser tool calls to the client. The client then executes them against the open editor and returns the result to the agent loop.

This boundary gives your application full control. You can change the model, prompt, schemas, permissions, retry policy, and validation without changing the document editor.

Let the agent verify each operation

An agent can work in short document transactions instead of generating one large patch:

1. Search for the target clause or structured content control.
2. Load the matching text and nearby document context.
3. Queue one supported change.
4. Synchronize the transaction.
5. Read the changed range before the next tool call.

The application can stop after any refused or ambiguous operation. A failed transaction does not leave a partial edit.

For browser-based legal review, register the Pro review module and enable suggesting mode before agent writes. The agent can add a reason as a comment. A person can then inspect, revise, accept, or reject the proposal.

Content controls give agents stable, structured targets in template-driven documents. The core architecture guide explains the document model that both runtimes edit.

Build the user interface around the agent

The editor UI and agent UI are also separate. The editor provides editable DOCX pages, selection, undo, comments, and review controls.

Your application can add a chat panel, task form, clause list, or approval queue. It can render tool progress, source text, explanations, and failure states in its own design system.

Use React composition or Vue composition to arrange the editor surface. Add your agent panel beside the document or inside your existing workflow.

The user remains in control of the document. A person can inspect each agent action, revise its output, and decide which proposals become final.

Add tracked proposals

If an agent must propose redlines, attach the browser runtime to an editor with the Pro review module and suggesting mode. The user can then accept or reject the proposed changes.

See the contract redlining API guide for that setup. See the programmatic editing API for the object model, host differences, and license terms.

For review operations, read tracked changes and comments.