GenOffice Dissected: Block-Level Agentic Editing in an AI-Native Office Suite

The Architecture That Makes Block-Level Editing Possible

The first thing that struck me about GenOffice's architecture is that it's not one application pretending to be a suite—it's six Electron-based desktop applications sharing a common core engine layer. Word, Excel, PowerPoint, PDF, and Markdown views each get their own shell, but they all sit on top of the same foundational services. That's a meaningful design decision. It means the hard problems get solved once, in the core, rather than being re-implemented per document type with subtle inconsistencies.

What's inside that core is where the real engineering lives. There's an in-house OOXML engine for .docx and .pptx, a custom layout engine, and a PDF engine that handles in-place editing and local conversion. Notably, GenOffice does not route Markdown-to-Word conversions through Pandoc or any remote cloud processor—it handles those natively. That's a deliberate choice to keep the parsing and serialization pipeline self-contained, which is exactly what you want if you're going to claim fidelity as a feature rather than an approximation.

For spreadsheets, there's a Rust .xlsx sidecar. That's an interesting architectural wrinkle. The Electron shell handles the UI and agent orchestration, but the heavy lifting of workbook parsing, pivot tables, and slicers happens in a separate Rust process communicating over IPC. It's the kind of split you'd design once you realize that V8's performance characteristics don't fit the problem. The tradeoff is latency and serialization overhead—sending large tabular structures across process boundaries can become a bottleneck on million-cell workbooks.

flowchart LR
    subgraph Electron Shell
        W[Word View]
        X[Excel View]
        P[PowerPoint View]
        PDF[PDF View]
        MD[Markdown View]
    end

    subgraph Core Engine
        OOXML[OOXML Parser<br/>(.docx / .pptx)]
        LAYOUT[Layout Engine<br/>Word-compatible pagination]
        PDFENG[PDF Engine<br/>in-place edit + OCR]
    end

    subgraph Rust Sidecar
        XLSX[Rust .xlsx Engine<br/>formulas, charts, pivots]
    end

    LLM[LLM Provider<br/>BYOK: Claude, OpenAI, Gemini...]

    W --> CORE_IO[Local .docx]
    P --> CORE_IO
    X --> XLSX
    PDF --> PDFENG
    MD --> OOXML

    CORE_IO --> OOXML
    OOXML --> LAYOUT
    PDFENG --> OOXML
    XLSX --> CORE_IO

    OOXML --> AGENT_EDITS[Agent Block Edits]
    LAYOUT --> AGENT_EDITS
    PDFENG --> AGENT_EDITS
    XLSX --> AGENT_EDITS

    AGENT_EDITS --> LLM_API[LLM API Calls]
    LLM_API --> LLM

The core principle driving the whole thing is byte-preserving .docx editing. Traditional suites like LibreOffice treat a Word document as an opaque file—they parse it, maybe modify it, and re-serialize the whole thing on save. Cloud-native tools like Notion and Gamma treat documents as proprietary web nodes and export to OOXML as an afterthought, which means round-tripping destroys fidelity. GenOffice's approach is fundamentally different: it modifies only the specific XML blocks that an agent actually touched, leaving everything else byte-for-byte untouched. That's how you preserve corporate master templates, nested styles, and conditional formatting that would otherwise get wiped by a full re-serialization pass.

The tradeoff is that byte preservation isn't a free lunch. It requires deep parsing and relationship reconciliation. When an agent inserts a block, it's not just editing document.xml—there are _rels/.rels, document.xml.rels, styles.xml, numbering.xml, and potentially footnotes, comments, and media parts that all need updating in lockstep. If the parser doesn't understand the full relationship graph, you get documents that open with "Word found unreadable content" errors. That's the risk you accept when you choose fidelity over simplicity, and it's why GenOffice's in-house engine has to be genuinely good rather than merely functional.

Byte-Preserving OOXML Editing: The Promise and the Pitfalls

Byte-preserving OOXML editing is one of those ideas that sounds elegant in theory and turns vicious in practice. The promise is straightforward: instead of parsing a document into an internal model, modifying it, and re-serializing the entire file on save, you locate the specific XML blocks that need to change and surgically edit only those. Every paragraph, run, table, and image that wasn't touched stays as it was on disk. That's how you avoid the styling wipeouts and corruption that plague round-trips through converters like Pandoc—the untouched 95% of the document remains structurally identical.

The problem is that in OOXML, "touched" is never just the block you edited. The format is deeply relational. A single paragraph in document.xml might have references that live in document.xml.rels, content that depends on styles.xml, and numbering that resolves through numbering.xml. Insert a footnote, and you're now modifying footnotes.xml plus the relationship graph that ties it back to the main document part. Add a comment, and comments.xml needs a corresponding relationship and anchor. Insert an image, and there's a media part, a relationship entry, and possibly a drawing context in the paragraph itself.

This is where independent parsers commonly fail. They handle the happy path—a simple paragraph with a style reference—but edge cases accumulate. VML shapes from legacy Word documents, SmartArt diagrams with their embedded XML parts, custom XML data bindings, fields and form controls, deeply nested tables with merged cells. Each of these carries its own relationship constraints. If the in-house OOXML engine can't reconcile the full relationship graph when an agent edits a block, the serialized document opens in Microsoft Word with the dreaded "Word found unreadable content" dialog. That's not a subtle formatting drift—that's a hard failure that makes the file unopenable without a repair pass.

GenOffice's approach tries to handle this by building the OOXML engine as a first-class citizen rather than a convenience wrapper. The byte-preservation strategy forces the parser to be conservative: it needs to understand everything it touches and leave everything it doesn't alone. But the honest assessment is that OOXML is a sprawling spec with decades of undocumented legacy behavior. No in-house engine will cover every corner on day one. Macro-enabled documents with VBA projects, unusual custom XML parts, or documents generated by non-Microsoft tools that produced imperfect OOXML in the first place—these are the cases where I'd expect divergence.

Approach	Formatting Drift Risk	Corruption Risk	Template Safety
Byte-preserving (GenOffice)	Low for untouched blocks; risks only for edited regions if relationship graph isn't reconciled	Low if parser is conservative; high if edge cases slip through (VML, SmartArt, custom XML)	High—master templates and corporate styling survive untouched blocks intact
Full re-serialization (Pandoc)	High—entire document gets re-rendered through a different model, uniform styles and sections often shift	Moderate—valid OOXML output but structurally different from source; can break macros and fields	Low—any style not natively understood gets mapped to a default, compromising template fidelity
Cloud-native export (Gamma/Notion)	Very high—web block schema has no concept of OOXML styles, so export is a lossy projection	Low for the export itself, but the source never had the fidelity to begin with	Negligible—these tools don't parse existing corporate templates; they generate from scratch

The practical takeaway: byte-preservation is the right architecture for documents that must survive in corporate ecosystems where fidelity matters. But it's only as good as the parser's understanding of the relationship graph. Before trusting it on business-critical documents, I'd run a round-trip test—edit through GenOffice, open in native Word, save, and verify no corruption warnings appear. If that passes for your document corpus, you're in good shape. If it fails on a specific file, that's a concrete bug you can report rather than an abstract risk.

Word-Faithful Pagination and Layout: Where Engineering Meets Fonts

There's a specific kind of hard problem that only becomes visible when you try to replicate a mature software product's behavior from scratch. Pagination in Word is one of those. It's not about rendering text on a page—it's about reproducing a system that depends on an enormous stack of subtle decisions, most of which are font-dependent and many of which are undocumented.

Word's layout engine computes page breaks using font metrics, kerning tables, OpenType features, language-specific line-breaking rules (including hyphenation dictionaries and CJK word-breaking), and printer metrics. When you're building an independent layout engine, you need to replicate all of that. The first problem is that you don't have the proprietary fonts. On a Linux or macOS system without Calibri, Aptos, or Segoe UI installed, the engine must substitute available fonts, which means different glyph widths, different kerning pairs, and ultimately different line wrapping. A paragraph that breaks as three lines in Word on Windows might break as four lines in GenOffice on Linux. The pagination parity breaks before you've even considered the more exotic layout features.

Then there are the structural layout challenges. Column balancing—where Word automatically equalizes the height of text columns on a page—is genuinely difficult to replicate. Floating objects with text wrapping around contours is another nightmare: you need to compute the wrap region based on the shape's geometry, apply the wrap settings (tight, through, square, top-and-bottom), and then reflow text around the resulting contour. Repeating header rows on nested tables requires the engine to understand table structure at multiple levels, which means duplicate row rendering logic across table boundaries.

The honest assessment is that GenOffice's layout engine will diverge from Word for complex documents. Not necessarily in ways that matter for simple reports or memos—where the text is linear and there are no floating objects—but definitely in ways that show up in newsletters, brochures, or any document with multi-column layouts and embedded visuals. The engineering team built a custom layout engine specifically to avoid dependency on Word itself, which is the right architectural call for an offline, cross-platform suite. But "close to Word" is not the same as "matches Word exactly," and the gap is directly proportional to document complexity.

For practitioners, the practical implication is straightforward: don't rely on the layout engine for pixel-perfect pagination parity if your documents have complex layout features. Use it for fast, AI-assisted drafting where the content matters more than the exact page breaks. If you need Word-faithful output for a client-facing deliverable, round-trip through native Word before sending. The layout engine is good enough to do the typing, but it's probably not good enough to do the typesetting.

PDF Editing and Local OCR: The In-Place Retrying Challenge

PDF editing is where most office suites give up and route you through a conversion pipeline. GenOffice doesn't—it attempts in-place editing directly on the page, letting you retype text and edit embedded images while preserving the original fonts. That's a genuinely hard problem, and the difficulty is almost entirely about font handling.

When a PDF is generated, fonts are typically subsetted—only the glyphs actually used in the document are embedded, often using identity encodings like Identity-H or custom /ToUnicode CMaps that map character codes to glyph indices. The editor can see the glyphs in the subset, so it can present them for editing. But the moment you insert text containing a character that's not in the original subset, you have a problem. The editor has two options: embed a new font to render the inserted glyph, or substitute an existing font family and risk the inserted text rendering with visibly different metrics, weights, or even garbled output if the CMap doesn't resolve correctly.

The first option preserves visual consistency but bloats the file and can break if the original document's font licensing doesn't permit embedding. The second option is simpler but degrades quality in precisely the way people notice. For practitioners, this is the failure mode I'd watch for: short, simple edits to standard fonts usually work fine. Edits that introduce Unicode characters, symbols, or non-Latin scripts into a document with heavily subsetted fonts are where things get unpredictable. Test before you trust.

Then there's the OCR story. On macOS, GenOffice uses Apple's Vision framework. On Windows, it uses the native Windows Media OCR. On Linux, there's no OS-level OCR engine at all—which means a feature gap that's baked into the platform rather than the application. The practical consequence is non-deterministic conversion quality across platforms. Vision and Windows OCR have different accuracy characteristics, particularly on handwriting, low-contrast scans, or documents with unusual layouts. A PDF that OCRs cleanly on a Mac might produce garbled text on Windows, and both might fail where a properly configured Tesseract would succeed.

For production workflows, this means you can't treat OCR as a stable pipeline component. If you're automating PDF-to-Office conversion across a mixed fleet, you need either a standardized OCR layer (Tesseract with a fixed model set, for instance) or you need to accept that quality varies by user platform. The architecture is sound—local OCR is the right call for privacy and offline capability—but the implementation is platform-coupled in a way that will bite teams that don't account for it.

AI Agents at the Block Level: How They Operate and Where They Break

The agentic model in GenOffice is fundamentally different from a chat sidebar that inserts text at the cursor. When you invoke an agent on a document, it operates on a specific block—a paragraph, a spreadsheet cell, a slide element—and receives that block's context along with its tool list. The agent can call tools in a loop: web search, image search, image generation, media analysis. All of that happens with the document context available, so the agent isn't just generating text; it's reasoning about a real piece of your document and producing a targeted patch. The workflow produces snapshots and diff previews so you can see exactly what changed before it's applied.

This is a big leap over plugin-based approaches in LibreOffice or ONLYOFFICE, where the LLM is a text generator and you manually paste the output. But it also introduces failure modes that are specific to block-level editing.

In spreadsheets, the risk is formula chain breakage. If an agent modifies a cell or table block, it can alter the data types or schema that downstream formulas depend on. An INDEX/MATCH that was resolving correctly might suddenly return #N/A because the agent changed a lookup key's format. A dynamic array that spilled across a range might now collide with the agent's inserted content. A pivot table's cache—which is a separate data structure—might not update, so the pivot shows stale or incorrect aggregated values even though the source block looks right. These are silent failures. The document doesn't corrupt; it just computes wrong. That's worse than an error message, because it can propagate through an entire business pipeline unnoticed.

Concurrent editing is another gotcha. If a human is actively typing in a section while an agent runs a multi-step transformation, there's no CRDT or operational transform layer to reconcile the two edit streams. The agent works on a snapshot, and if the human's edits land after that snapshot but before the agent's patch is applied, you get race conditions. The human's changes can be clobbered, or the undo/redo stack can get into an inconsistent state where undoing one change reverts the other. For production use, the safe pattern is to lock blocks while an agent is working on them, or to run agents on a copy and merge consciously.

Prompt injection is the third concern. Documents are untrusted inputs. A PDF from a vendor or a spreadsheet from a partner can contain hidden text, white-on-white characters, or metadata that carries injected instructions. If the agent has access to web search, image generation, or file operations, those injected instructions can trigger tool actions the user never intended—data exfiltration through a search query, or generation of content that gets saved into the document. The mitigation is to treat document content as untrusted in the agent's context and to scope tool access narrowly, but that's an operational discipline that has to be enforced in the product itself.

sequenceDiagram
    participant U as User
    participant A as Agent
    participant L as LLM Provider (BYOK)
    participant D as Document Model
    participant R as Rust Sidecar (.xlsx)

    U->>A: Select block, invoke agent
    A->>A: Receive block context + tool list
    A->>L: Send block context + tools (API call)
    L-->>A: Return patch (diff)
    A->>D: Apply patch to block
    A->>D: Update snapshot
    A->>U: Show diff preview
    U->>A: Approve
    A->>D: Update document.xml/rels (reconcile relationship graph)
    alt .xlsx edit
        A->>R: Trigger recalculation via IPC
        R-->>A: Return recalculated values
    end
    A->>D: Run schema validation before save

The diagram captures the ideal flow. The key moments are the reconciliation of the relationship graph—which is where byte preservation can go wrong if the agent's patch didn't account for related parts—and the validation step before save, which is the last line of defense against an agent-generated OOXML block that's structurally valid in isolation but invalid in the document's context.

The deeper takeaway is that block-level editing is a real architectural advance, but it shifts the failure surface from "the AI wrote bad prose" to "the AI wrote bad prose that also broke a formula chain or triggered an unintended tool call." Those are more dangerous failures because they're harder to detect by eye.

BYOK and Model Agnosticism: Real Flexibility or Configuration Nightmare?

Bring Your Own Key is one of those features that sounds liberating on paper and becomes a support burden in practice. GenOffice connects to Claude, OpenAI, Gemini, DeepSeek, Kimi, GLM, Qwen, Doubao, MiniMax, Grok, Mistral, OpenRouter, or any standard OpenAI-compatible endpoint—including local ones like Ollama or vLLM. The flexibility is real. You can route everything through a local model for air-gapped work, then switch to a frontier model for a particularly complex analysis, without changing your document workflow. For teams with data residency requirements, that's a meaningful capability.

But here's the operational reality: models are not interchangeable, and the agent orchestration layer has to accommodate that. Different models have different tool-calling reliability. Some are excellent at structured output—producing a well-formed patch or JSON diff reliably—while others are more likely to emit valid-looking but subtly malformed results. Some have context windows that can fit a full chapter of a document with room for tools; others will truncate or degrade on the same input. The execution loop has to handle each provider's strengths and weaknesses, which means the implementation can't simply treat every endpoint as an identical LLM wrapper.

The practical consequence for users is that your choice of model shapes the agent's behavior. A model with strong structured output will produce clean patches that apply without conflicts. A weaker model in the same role might produce a patch that the document model has to interpret, correct, or reject—and if the loop isn't robust, you end up with failed edits or, worse, edits that apply but with subtle errors. This isn't necessarily a bug; it's the underlying cost of model-agnosticism. When you design for portability, you design for the lowest common denominator, which means you're not fully exploiting the best model's capabilities. The engineering tradeoff is between provider flexibility and per-provider optimization.

There's also a privacy nuance that's easy to miss. GenOffice handles file conversion and OCR entirely locally, and the layout engine runs on your machine. That's genuinely local-first. But BYOK agent calls send your document blocks to whatever endpoint you've configured. If you're using Claude or OpenAI, that means document content leaves your machine and goes to a cloud provider. "Local-first" is only true for the non-AI parts of the pipeline. For sensitive contracts or proprietary spreadsheets, the only truly local configuration is a local endpoint like vLLM or Ollama—and those often have fewer capabilities and larger latency than a frontier cloud model.

The honest assessment: BYOK is a real feature, not a marketing checkbox, but the value it delivers depends entirely on how well the orchestration layer handles model heterogeneity. If you're the kind of user who picks one strong model and sticks with it, it's a nice convenience. If you're trying to route different tasks to different providers based on cost or capability, you're going to be managing a set of per-model quirks that are easy to underestimate until you've hit them in production.

Failure Modes in Production: What I'd Watch Before Trusting It

The first thing I'd flag for anyone considering GenOffice in a production pipeline is the relationship graph problem. Byte-preserving editing is only as safe as the parser's understanding of how OOXML parts interconnect. When an agent inserts a block, it's not just touching document.xml—it's potentially invalidating references that live in document.xml.rels, styles.xml, numbering.xml, and any number of ancillary parts. If the engine doesn't reconcile that graph, you get the dreaded "Word found unreadable content" dialog. That's not a subtle formatting drift; it's a hard failure that requires a repair pass and destroys trust.

The mitigation is strict pre-save validation. Run the generated document through an OOXML linter or schema validator before persisting. It's the last line of defense against an agent producing a block that's structurally valid in isolation but breaks the document's broader context.

For spreadsheets, the risk shifts from corruption to silent miscalculation. If an agent modifies a cell or table block, it can alter data types or schema conventions that downstream formulas depend on. An INDEX/MATCH that was resolving correctly might suddenly return #N/A because the agent changed a lookup key's formatting. Worse, LLMs frequently hallucinate formula syntax—mixing Google Sheets conventions with Excel's, or generating malformed range references. The Rust sidecar will try to evaluate them, and you'll get #VALUE! or #REF! errors that propagate through dependent cells. That's worse than a corrupted file, because it doesn't announce itself. Your business logic computes wrong values silently.

There's also an IPC overhead issue to watch. When you're editing a million-cell workbook, sending tabular structures back and forth between Electron's V8 thread and the Rust sidecar creates latency and memory spikes. The architecture is sound, but high-frequency block updates on huge workbooks will test its limits. Batch your operations, and be wary of running multiple concurrent agent edits on the same large file.

Memory footprint is a practical concern too. Six Electron applications sharing a core engine is architecturally clean, but each instance carries significant overhead. If your team runs multiple document types simultaneously, you'll feel it in system resources. Monitor CPU and RAM usage; isolate worker threads where possible.

The Linux OCR gap is worth noting for deployment planning. macOS has Vision, Windows has its native OCR, but Linux has nothing at the OS level. That's a feature gap baked into the platform, not a bug you can patch. If you need OCR on Linux, you'll need to standardize on a fallback binary like Tesseract.

Finally, audit your data flow. File conversion and OCR are genuinely local. But BYOK agent calls send document content to whatever endpoint you've configured. "Local-first" only holds for the non-AI parts of the pipeline. For sensitive documents, the only truly local configuration is a local endpoint like vLLM or Ollama—which usually means fewer capabilities. Know what's leaving your machine before you trust a workflow.

How GenOffice Compares to the Alternative Paradigms

The landscape breaks into four architectural camps, and GenOffice occupies a genuinely distinct position in it. Microsoft 365 Copilot and Google Workspace Gemini are the incumbents: deeply integrated into proprietary cloud ecosystems, with server-rendered internal representations that your users never see. When you prompt Copilot in Word, the instruction goes to Microsoft's cloud orchestrator, which interacts with Office's internal DOM. It's powerful, but it's locked behind subscription licensing, it transmits all document context to their infrastructure, and you're building on their object model. You can't take the files offline, you can't route to alternative models, and you're bound to their SaaS.

LibreOffice and ONLYOFFICE represent the opposite extreme for open-source. They have mature, decades-old rendering engines, but their AI integration is plugin-grade: a sidebar chat that generates text at the cursor. The LLM doesn't see the document's structure, can't orchestrate multi-step rewrites, and doesn't have tool loops for web search or image generation. It's a smarter autocorrect, not an agent.

Cloud-native AI workspaces—Notion, Gamma, Coda, Rows—took a third path. They replaced OOXML entirely with custom web block schemas, which lets them build beautiful AI-native interfaces. But the moment you need to interoperate with a corporate Word template, you're running a lossy export pipeline. Round-tripping through Pandoc or a headless browser destroys fidelity. They can't operate on existing local files; they generate from scratch.

GenOffice's sweet spot is the intersection no one else occupies: local-first, block-level agentic editing with BYOK. It's in-house OOXML parser modifies only touched blocks, the AI agents operate on actual document structures with snapshots and diff previews, and you can route to any provider (or a local one). It also runs entirely offline for conversion and OCR—something Copilot can't claim.

But it's early alpha. The parser won't handle every OOXML edge case on day one, the Excel formula engine isn't hardened against decades of corporate workbook weirdness, and Electron overhead is real. For enterprise-critical work, that's a risk. For practitioners who need fidelity, privacy, and agentic control over document edits, it's the most promising architectural direction I've seen.

	GenOffice	Microsoft 365 Copilot	LibreOffice + AI Plugin	Gamma / Notion
Architectural approach	Local Electron + Rust sidecar, in-house OOXML parser, byte-preserving edits	Cloud orchestrator on proprietary Office object models	Classic OpenOffice rendering engine; LLM as a side-panel text generator	Custom web block schema exported to OOXML via conversion pipeline
AI agentic capability	Block-level agent loops with tool calls (web search, image gen, media analysis), snapshots and diff previews	Deep integration into document context via Graph API, but proprietary and cloud-bound	Non-agentic: LLM inserts text at cursor; no document structure awareness or tool loops	Native AI features in a web-first format, but no block-level editing of existing binary files
Data locality	Fully local for file I/O, PDF conversion, OCR (macOS/Windows); BYOK agent calls to chosen provider	Cloud-dependent; all document context transmitted to Microsoft servers	Local for file rendering; plugin sends prompts to configured LLM provider	Cloud-native; files stored in proprietary web format, exports generated server-side
Maturity	Early alpha; active development but unhardened toolchain for enterprise edge cases	Enterprise-grade, decades of hardening; but locked-in and expensive	Very mature engine; AI integration is immature	Polished product for cloud-native workflows; fidelity loss on OOXML export

Project Applications: What You Can Build with This Approach

The block-level agent interface opens up tooling opportunities that traditional office suites simply don't expose. One pattern I'd explore is a block-level diff review tool. The idea is straightforward: connect to GenOffice's agent API, request an edit on a document, and then present the user with a before/after snapshot of every modified block. The tool would track which blocks were edited, allow highlighting of changes, and give the user a rollback path to any prior snapshot. It's the kind of transparency layer that makes agentic editing safe enough to actually trust.

The watch item here is the relationship graph. An agent might edit a paragraph and appear to succeed, but if it inserted a footnote reference or a comment without reconciling the associated footnotes.xml or comments.xml parts, the document is silently corrupted. Your diff tool should validate the full OOXML relationship graph before declaring a diff "safe." If it doesn't, you'll show the user a green checkmark on a file that's about to prompt Word's repair dialog. Performance also matters: diff previews on large documents require efficient block-level comparison, not a full re-serialization.

For spreadsheets, I'd build a formula guardian. The problem is well-defined: LLMs hallucinate formula syntax, mixing Excel conventions with Google Sheets' and generating range references that don't resolve. A plugin that intercepts agent-generated formulas before they hit the Rust engine, parses them against Excel's documented formula language, and flags anything suspicious would catch the silent #VALUE! or #REF! errors before they propagate through downstream dependencies. The tricky part is dynamic arrays—a formula that looks valid at the cell level might spill into ranges that clobber existing data or break a pivot cache. The guardian needs to simulate the spreadsheet's dependency graph, not just validate syntax in isolation.

The third pattern is an automated round-trip fidelity tester. This is the kind of tool I'd want before adopting GenOffice for any business-critical pipeline. The loop is simple in concept but thorough in execution: take a representative corpus of .docx, .pptx, and .xlsx files—including macros, SmartArt, pivot tables, complex nested tables—and run them through a fixed sequence. Save with GenOffice, open and save with the native MS Office application, then reopen with GenOffice and compare formatting, metadata, and structural integrity. The tester should specifically check for "unreadable content" errors, compare pagination and font substitution, and verify that relationships remain intact across conversions. Pass a corpus through this loop and you'll learn more about the engine's real-world fidelity than any README will tell you.

All three of these follow the same principle: the failure modes I've highlighted are most dangerous when they're silent. Building tooling that makes them loud is how you turn an interesting alpha into something you can actually rely on.

Resources

• GitHub - genspark-ai/genoffice: Free, open-source alternative to Microsoft Office with built-in AI agents — Word (.docx), Excel (.xlsx), PowerPoint (.pptx), PDF and Markdown editing for macOS, Windows
• GenOffice — The world's first full-featured open-source AI Office
• genspark-ai/genoffice on GitHub