AI Agents Are Building Office Alternatives. The Factory Is the Story.

The interesting thing about ArtCraft isn't that somebody drew an Excel-looking window. It's that an agent-assisted team is attempting a whole family of complex desktop tools, publishing the code and release artifacts, and designing the tools so agents can operate them too.

That's a much better case study than “Microsoft Office is dead.”

Brandon Thomas and ArtCraft are making a serious small-team bet: coding agents can help turn a broad software ambition into inspectable implementations. The evidence supports that bet as an experiment in building. It doesn't yet support replacing the software you trust with your accounts, client documents or presentation tomorrow.

We followed the Tom's Hardware report into the original repositories. The useful discovery wasn't another feature list. It was the factory: shared engineering conventions, bounded work for parallel agents, commands that serve both humans and machines, and unusually candid lists of what still breaks.

Public artifacts, not a finished replacement suite

The Office-shaped projects are GridCraft for spreadsheets, DeckCraft for presentations and WordCraft for documents. All three have public source repositories and published v0.5.0 GitHub releases with platform-specific downloadable assets. That's a real step beyond a concept video. It's also a narrower fact than “the installers work”: we inspected release metadata, not installed applications.

The current ArtCraft lineup lists twelve apps. CADCraft is already there, marked In Development with Installers Ready. So the secondary headline's suggestion that CAD tools merely “may come next” has been overtaken by the current listing. That isn't evidence of AutoCAD or SolidWorks equivalence. Nor are twelve listings twelve finished products. FilmCraft also lacks the web label shown on many siblings; don't flatten the lineup into “everything runs in your browser.”

The Office projects' pinned roadmaps still say alpha. Keep that label next to the releases, not buried beneath them. A version number and a downloadable file tell you something was packaged. A roadmap, compatibility corpus and field testing tell you whether you should entrust work to it. Those are different questions.

What we can actually say about the AI work

Thomas's stated ambition is software ownership, not just another AI feature inside a subscription. In his Hacker News comment, posted under echelon, he says he's using Opus 5.5 to create open-source implementations of Adobe's suite. That's his account of the creative projects, not our measurement of how the Office apps were written.

There is more concrete attribution in the Office repositories. In the desk's October 11 snapshot of each repo's latest twenty commits, explicit Claude coauthor trailers appeared in 4 GridCraft, 12 DeckCraft and 20 WordCraft commit messages. The sample includes merge commits and isn't random. A WordCraft example credits both Claude and Brandon Thomas while describing work on document content controls.

Those tags are evidence of contributor-attributed AI assistance. They aren't authenticated model provenance, a percentage of generated code, a productivity multiplier or proof of unattended development. Merged contributor branches also make the “one person did absolutely everything” framing misleading. This is an ArtCraft project with human collaborators, not a controlled solo-developer benchmark.

The responsible conclusion is still interesting: publicly attributed agent work is participating in software with real source, packaging and engineering structure. We don't need to invent a weekend timeline or token bill to make that matter.

The factory starts with a place to put the work

Read the pinned WordCraft agent instructions and you find something more useful than “build me Word.”

The project separates document data, fonts, layout, formats, rendering, the editing engine, MCP and the UI into layers. WordCraft's engine owns the session and command registry; the front end is meant to be thin and swappable. GridCraft and DeckCraft document comparable separations for their own domains. The boundaries aren't identical across apps, but the principle is: don't put every concern into a window event handler.

That is a good fit for agent work. A change to a file reader can have a bounded module and explicit tests. A UI change doesn't have to rewrite the document model. The architectural contract reduces the amount of unrelated code a contributor needs to touch. That's our engineering interpretation of the design, not a measured reduction in agent errors.

The GridCraft instructions explicitly require parallel agents to use separate CARGO_TARGET_DIR build directories and edit only the crates they own. That isn't magical orchestration. It's practical collision avoidance: independent builds shouldn't fight over an artifact directory, and independent edits need ownership boundaries.

The visible recipe also includes behavior grounded in public specifications and black-box observation, regression tests for crash fixes, and pre-commit gates for formatting, clippy linting, tests, asset attribution, crate layering and WebAssembly. DeckCraft's retained CI workflow actually invokes the documented gate. We haven't audited compliance on every commit or run that workflow ourselves.

A particularly sensible rule is that programmatic command calls shouldn't pop up dialogs. They should run with defaults or return an error. An agent waiting forever for an invisible Save dialog isn't automation; it's a stalled desktop session.

Progress is meant to remain visible too: feature work updates the roadmap, affected parity documents and ranked gap list. That turns “what next?” into a work queue with evidence, rather than another increasingly elaborate prompt.

There is a limit to the reproducibility claim. Local plan/ material is gitignored, and the linked shared craftrules URLs returned 404 in the desk's retrieval. We can inspect the committed recipe. We can't reconstruct the complete private orchestration, planning files or prompt history.

Built by agents, built for agents

This is the part I'd borrow first.

The repositories' documented contract is “Everything is a command.” A command has an identifier, parameters and behavior; the GUI, command-line interface, control channel and MCP dispatch through that system. Agents aren't restricted to guessing where a toolbar icon is on screen.

GridCraft's MCP documentation exposes operations to read and write ranges, evaluate formulas, inspect a workbook and run engine commands. It describes both a headless engine session and a bridge to the running desktop app. Its Rust MCP library contains those backend abstractions; this isn't just a roadmap promise to add an integration someday.

DeckCraft documents slide inspection and rendering alongside presentation-editing commands. WordCraft documents reading the document structure back and rendering a page. Their MCP test files contain synthetic workflows that build a deck or format a document through the protocol and inspect the resulting state. We read the definitions. We didn't execute the tests.

The distinction matters. A command interface gives an agent a way to act and a way to check, but doesn't prove the check is sufficient. Document structure can look correct while pagination is wrong. A saved file can reopen in the originating engine and still lose something in Office.

WordCraft offers a nice example of controllability rather than raw feature count: its MCP docs describe naming an agent as the editing author and explicitly enabling tracked changes. That is the right direction for a copyediting workflow where someone needs to review what changed. It's documented functionality, not a desk-tested assurance that every revision survives exchange with Word.

Direct commands also aren't inherently safe. A powerful editing surface needs scoped files, explicit approvals where appropriate and recoverable output. Predictable verbs make those controls easier to design; they don't replace them.

Three products, three different trust problems

WordCraft: writing is easier than faithful document exchange

WordCraft's README describes a familiar document workflow: styles, tables, tracked changes, references and mail merge, with DOCX reading and writing and PDF export. CLI inspection and MCP control make it an interesting target for document-generation and editorial experiments.

The harder question is whether somebody else's document remains somebody else's document after an edit.

The project's gap list says real-world DOCX corpus testing hasn't been completed and pagination differs from Word. Its more detailed format-parity document says Word ink isn't preserved, embedded fonts aren't read, and charts imported from Word remain read-only even though WordCraft-created charts have an editable path.

The docs themselves show why a feature-count headline is dangerous. The roadmap's alpha explanation still says content controls are lost, while the pinned format document records content controls as read and written. We wouldn't use the stale summary to declare the feature missing. We also wouldn't turn the newer row into a blanket fidelity guarantee. Rapid development needs a fresh workload check, not just a more flattering paragraph.

GridCraft: a command can succeed and the workbook can still be wrong

GridCraft uses XLSX as its native format and documents formulas, tables, charts and PivotTables, plus CSV/TSV exchange. Its range-level MCP surface is a useful design for an agent assembling or reviewing a spreadsheet without clicking through individual cells.

But the gap list names the critical missing proof: a real-world XLSX corpus and confirmation that Excel opens saved output without repair prompts. It also lists calculation-correctness issues, chart round-trip limitations and field crashes or freezes.

The format docs distinguish preservation from implementation. Some unsupported package parts can be passed through untouched; other content, including slicers and the data model, isn't preserved. That is not equivalent to editing those features. The same docs say macro-enabled workbooks can be saved without their VBA macros, with a warning. A finance workflow built around VBA isn't fixed by an MCP endpoint.

DeckCraft: a good-looking slide isn't a dependable presentation

DeckCraft's README describes themes, shapes, tables, charts, transitions, animations and full-screen presentation. It documents PPTX exchange, a native .deckcraft format, PDF/image export and command-driven automation.

Its format-parity document is more useful for a go/no-go decision: real-deck fidelity hasn't been measured across a corpus; embedded fonts aren't supported; modern threaded comments are written back as legacy comments, losing replies and resolved state; media playback options can be lost on save.

The gap list also records a close-without-prompt data-loss issue and startup crashes on some Windows hardware. Those are project-reported issues at our pinned snapshot, not failures we reproduced. They explain why a demo deck isn't the acceptance test for a client's talk.

The hard part didn't disappear. It moved into validation.

ArtCraft's candid docs are a strength of the case study, not a reason to dismiss it as slop. They expose the difference between implementation breadth and professional reliability.

The repositories publish readiness percentages and estimates expressed as Opus 5.5 agent-hours. We aren't treating those estimates as desk benchmarks, delivery dates or dollar costs. A list of implemented commands can be mechanically counted. A claim that a lawyer can safely exchange a tracked contract, or an analyst can trust a financial workbook, needs different evidence.

The same applies to the projects' clean-room framing. They call themselves clean-room reimplementations and prohibit copying proprietary assets. Those are documented project policies, not our legal validation, copyright or patent ruling, or an allegation of piracy. “Pure Rust” isn't “dependency-free” either: the manifests include third-party crates such as serde and egui. This is software engineering on an ecosystem, not every line conjured from nothing.

Maintenance is where the ambitious catalog becomes an obligation. Cross-platform crashes, save/reopen behavior, fonts, pagination, review state, chart semantics and add-in expectations don't stop changing after a release. Agents may help work through that backlog. Somebody still has to decide what is acceptable and verify it independently.

What a small team should borrow

Don't start by asking agents to replace Office. Start by defining one workflow whose output you can judge.

For a spreadsheet tool, that might be a reporting workbook with known formulas and expected values. For a document tool, a report with tables, page breaks and review markup. For a presentation tool, a deck with charts, unusual fonts and timed media. These are proposed acceptance fixtures, not ArtCraft tests we've performed.

Then borrow the factory's useful constraints:

• Bound ownership. Give each worker a module and an interface contract. Separate build artifacts and make integration one explicit responsibility.
• Expose commands and inspection. An agent should be able to discover a verb, supply parameters, receive an error and read back state. Don't make screen-clicking the only route.
• Write nasty fixtures. Include malformed inputs, unsupported objects, missing fonts, repeated undo and interrupted saves. Test refusal and recovery, not just the attractive sample.
• Validate outside your own engine. Save and reopen in the intended receiving tool. Check values, visual layout and preserved metadata. Self-round-trip success isn't interoperability.
• Separate implementation from QA. Let another reviewer challenge the acceptance evidence. A model checking its own assumptions is not independent validation.
• Release narrowly and keep rollback. Use copies, retain originals and prior builds, and expand only after the workflow survives real use.

A small team can learn a lot from this pattern without claiming that a nonprogrammer can replace decades of Office engineering with a prompt.

The subscription implication is an inference, but a meaningful one: if agents reduce the effort needed to attempt alternatives, more teams can challenge individual workflows. If those alternatives also expose reliable commands, they can become useful tools for agents rather than just cheaper-looking interfaces for humans. Neither claim requires declaring Microsoft, Adobe or Autodesk dead.

ArtCraft is evidence of an ambitious, agent-assisted software factory taking shape. The next proof isn't another app name. It's a real user's file surviving the trip.

Methods and evidence limits

Research snapshot: October 11, 2026 UTC. We reviewed original GitHub API responses, pinned source documents, MCP library/test definitions, official product listings and creator statements. GridCraft was pinned at a5137872c15fac7bf260fa2d25ea8f7e66b19dc2, DeckCraft at be14248577b92059eb2b8c0c9460cceffbc1f01d and WordCraft at 053bb0fd858bc236c797737b6a8401847e03bf1d. These source revisions aren't a claim that the release binaries contain every described change.

No desktop app was installed or run, no Office file was round-tripped, no repository tests or benchmarks were executed, and no binaries, token costs or security properties were audited. Website browsing wasn't an application trial. Project claims are attributed; our recommendations are proposed practice.

Sources

All accessed in retained research on October 11, 2026:

• ArtCraft's current app lineup and Thomas's creator statement.
• Published releases: GridCraft v0.5.0, DeckCraft v0.5.0, WordCraft v0.5.0.
• Pinned engineering contracts: GridCraft, DeckCraft, WordCraft.
• Pinned roadmaps: GridCraft, DeckCraft, WordCraft.
• Ranked limitations: GridCraft gaps, DeckCraft gaps, WordCraft gaps.
• Source-level MCP tests: GridCraft, DeckCraft, WordCraft. Definitions inspected, not executed.
• Tom's Hardware seed report. Secondary reporting, not proof of product parity.

Article history

October 11, 2026 — Original commissioned case study researched and drafted for mr.technology. Source-research editorial QA completed. Publication prepared 2026-10-11T21:33:48.975471Z; no application testing performed.