[EPIC] Offline Office document support (docx, xlsx, pptx)

[andrii-novikov]

Goal

Let a QuickApps agent read, generate, and edit Microsoft Office documents (.docx, .xlsx, .pptx) that exist as files in DIAL storage — attachments, context files, and agent-home working files — with no dependency on a cloud suite.

Today this is not possible:

• internal_file_write creates UTF-8 text only. There is no binary write path to DIAL storage, so an agent cannot produce or modify an Office file at all.
• Reading is partially achievable through an external MarkItDown-style MCP server (unblocked by Add a file:data:: prefix to inline attachments as data: URIs for MCP tools (e.g. MarkItDown-MCP) #475, file:data:: inline attachments), but it is conversion-only and lossy.
• No Office libraries are present in the application.

Enterprise business documents are still .docx/.xlsx/.pptx. For a no-code builder assembling a personal agent or a POC, "produce our weekly report in the company template" or "fill in this spreadsheet" is a first-class expectation, and the answer today is no.

Why now: this is a live 2026 frontier — OpenAI shipped document, spreadsheet, and presentation editing in ChatGPT Work on 2026-07-09, and a set of agent-facing open-source Office toolchains has appeared (OfficeCLI and several MCP servers). The differentiating angle for DIAL is that the entire path can stay inside the customer's own infrastructure.

Scope — child issues

• Discovery: implementation options for offline Office document support #488 — first step, gates everything below
• (not yet filed) Binary write path for DIAL storage
• (not yet filed) Chosen implementation, per the discovery outcome
• (not yet filed) features.office_documents configuration surface + documentation

Out of scope

• Cloud-hosted documents — Google Docs/Sheets/Slides and Microsoft 365 / SharePoint. Those are API integrations with a per-user OAuth problem rather than file handling, and will be tracked separately.
• Changes to the code interpreter execution engine itself (epam/ai-dial-code-interpreter).
• PDF export, document rendering, and preview generation.
• Legacy binary formats (.doc, .xls, .ppt).
• OpenDocument formats (.odt, .ods, .odp).

Dependencies and sequencing

• The discovery issue must land first — the option chosen determines every subsequent child issue, so nothing else should be filed in detail before it.
• A binary write path in DIAL storage is a prerequisite for every option except pure format conversion. Small and self-contained; file it as soon as discovery confirms the direction.
• If discovery selects an external MCP document service, it inherits Preserve MCP session across tool calls #389 (MCP session persistence — a stateless-per-call client must ship the whole document in and out of every call, which does not scale past small files) and Support agent-home-relative file references in MCP dial_url parameters #445 (agent-home-relative file references in MCP dial_url parameters, so documents travel by reference rather than as bytes).
• If discovery selects the code interpreter route, it depends on the epam/ai-dial-code-interpreter image (external repo) and on the boundary decision in [EPIC] Code interpreter as a standalone MCP application #424 — decide that first.
• Skills bundling ([EPIC] Advanced Agent Skills support #421, and Skills scripts references for code execution tools #420 specifically) is a natural delivery vehicle for document recipes and templates; sequence after Skill artifacts support #418 if the two are combined.
• Whichever option lands, Office input and output increase context and attachment pressure — Display context window usage indicator during conversation #351 (context window usage accounting) is a useful companion rather than a hard blocker.

Additional information

• Read path partially unblocked by Add a file:data:: prefix to inline attachments as data: URIs for MCP tools (e.g. MarkItDown-MCP) #475.
• internal_representation_add_attachment already exists, so returning a produced document to the user is solved.
• Related: [EPIC] Code interpreter as a standalone MCP application #424 (code interpreter boundary), Preserve MCP session across tool calls #389, Support agent-home-relative file references in MCP dial_url parameters #445, [EPIC] Advanced Agent Skills support #421, Skill artifacts support #418, Skills scripts references for code execution tools #420, Display context window usage indicator during conversation #351.
• Known trap worth recording up front: .xlsx is not .docx-with-cells. openpyxl does not evaluate formulas — it reads cached values and writes formula strings — so an agent that edits a spreadsheet's inputs produces a file with stale totals until a human opens it in Excel. Formula recalculation likely requires a headless engine, which may justify scoping .xlsx separately from .docx/.pptx.