The Old Office File Problem Is Getting Worse

Office documents were built for people clicking buttons, not for software agents making careful edits under review. That was fine when the workflow was one person nudging a text box at 11:47 p.m. before a meeting. It is less fine when an AI tool is asked to rewrite a pricing slide, update a chart, add speaker notes, and leave behind a useful paper trail.

The practical problem is not that PowerPoint, Keynote, Google Slides, or PDFs are bad. They are very good at being office products. The problem is that they hide too much state. The visible slide is only part of the document. Layout rules, embedded media, charts, comments, transitions, fonts, speaker notes, and metadata are scattered through formats that are often hard to inspect casually.

That matters because AI-generated changes need review. A useful AI document workflow should answer boring questions quickly: what changed, where did it change, can the edit be reversed, and did the assistant touch anything it was not supposed to touch? If the only answer is “open the file and look around,” congratulations, the robot has recreated the intern problem with better capitalization.

The bottom line: If AI is going to edit office documents, the file format matters. Plain, inspectable document state beats mystery blobs and silent cloud saves.

Bento Is Interesting Because The File Is The Surface Area

Bento Slides is a useful signal here. Its public documentation describes a deck as a single .bento.html file that acts as the document, viewer, and editor at once; the product page says the document data is kept as readable JSON inside the HTML file. That is the important bit, not the marketing sparkle. A deck that contains its own editing interface and its own inspectable data gives an AI tool a simpler target than a conventional binary-ish office bundle. See Bento's own description at bento.page.

This is not an entirely new idea. Web-native slide tools have existed for years. reveal.js, for example, describes itself as an open source HTML presentation framework and supports features such as Markdown, speaker notes, PDF export, and browser-based presentation. The difference with the Bento-style pattern is the packaging: the document and the machinery for viewing or editing it can travel together in one file.

That packaging changes the AI workflow. Instead of asking an assistant to reverse-engineer a proprietary office file, you can hand it a text-adjacent artifact with structured document state. The AI tool can propose edits to JSON, CSS, text, and layout instructions. A human can inspect those edits with ordinary developer habits: search, diff, commit, revert.

Plain Document State Makes AI Edits Reviewable

The killer feature is not “AI can make slides.” AI tools have been able to make mediocre slides for a while. The killer feature is that the document can expose enough structure for review.

A good AI-editable document should make these things obvious:

  • Content changes: the title changed, three bullets were removed, one paragraph was rewritten.
  • Data changes: a chart now points at different rows or a table now has different numbers.
  • Layout changes: an element moved, resized, changed color, or changed animation.
  • Hidden changes: speaker notes, comments, scripts, external resources, or collaboration metadata changed.
  • Provenance: the edit came from a specific prompt, model, user, or automation step.

That list sounds obvious until you try to reconstruct it from a normal presentation file after several AI-assisted revisions. This is where plain data wins. If a document stores its meaningful state in readable JSON, the review process becomes less mystical. You can diff before and after. You can validate schema. You can reject edits that touch forbidden fields. You can run a linter. You can build a preview from the same source being reviewed.

This is the same reason Notavello keeps pushing exportable AI work instead of trapped conversations. If your team is already saving research, prompts, and decisions, Notavello's AI export tools are a better habit than leaving the only useful version inside a chat sidebar. Documents should be portable. So should the reasoning that produced them.

The Browser Can Do More Than People Think, But It Has Edges

Single-file web documents are possible because the browser is now a serious application runtime. Compression, local file handling, offline execution, canvas rendering, media, cryptography, and structured storage are all available in some form. That is why an HTML file can be more than a web page. It can be a small app with a document embedded inside it.

But this is where product teams need to stay awake. Browser APIs are not equally available everywhere. MDN marks showSaveFilePicker() as limited availability and experimental, and notes that it requires secure contexts in supporting browsers. That matters if a single-file editor depends on rewriting itself or saving directly back to disk. The fallback might be a download. That may be acceptable for a deck. It may be annoying for a daily document editor.

Other APIs are more settled. MDN describes DecompressionStream as widely available and says it has been available across browsers since May 2023. That makes compressed self-contained payloads more realistic. Still, the practical rule is simple: if the document must work for clients, schools, government users, or locked-down enterprises, test the boring browser matrix before celebrating.

There is also a security tradeoff. A self-contained HTML document can include executable JavaScript. That is powerful. It is also exactly why some organizations will treat it like software, not like a harmless attachment. If the file can edit, render, collaborate, and run scripts, then it needs the same suspicion you would apply to any local app.

A Sensible AI Document Workflow

If your team wants AI-editable documents without chaos, start with the workflow before falling in love with the format. The format should support the controls. Not the other way around.

Use this checklist for any HTML-file, Markdown-file, JSON-file, or “AI-native” document system:

  • Keep the canonical content readable. The main text, tables, chart data, image references, and notes should be inspectable without launching a proprietary editor.
  • Separate content from behavior. The AI tool should usually edit document state, not application code. If it changes scripts, that should require special review.
  • Require diffs for AI edits. No silent overwrites. The assistant should produce a before-and-after patch or a clear change summary.
  • Validate the schema. If the file stores JSON, run validation before accepting edits. Broken slides are bad. Broken slides five minutes before a board meeting are performance art.
  • Preserve revision history. Save snapshots or commit changes to version control. A single file is convenient, but convenience is not backup.
  • Watch external assets. Fonts, images, video, scripts, and remote URLs can create privacy, availability, and security problems.
  • Make export boring. A useful deck still needs PDF, image, or static web export for people who do not want your clever editor file.

The most important habit is to treat AI edits as proposed changes, not as final truth. The document format should make review cheap enough that people actually do it.

This Pattern Is Bigger Than Slide Decks

Slides are just the visible example. The same pattern applies to reports, product specs, notebooks, invoices, dashboards, diagrams, and lightweight databases. The next useful office format may not look like a traditional office suite at all. It may look like a portable web app with a readable data block and strict rules about what the AI tool is allowed to touch.

That would be a healthier direction than dumping more AI features into opaque editors. If an assistant writes a report, the report should be easy to diff. If an assistant changes a spreadsheet-like model, the changed formulas and source data should be obvious. If an assistant redesigns a pitch deck, the human reviewer should not need to click through thirty slides hunting for weirdness.

The web already has many of the pieces: HTML for structure, CSS for presentation, JavaScript for interaction, JSON for state, browser APIs for local behavior, and version control for review. The missing piece is discipline. A document that can execute code, store data, and invite AI edits needs boundaries.

So the Bento-style lesson is not “PowerPoint is dead.” PowerPoint is annoyingly alive, like every durable office habit. The better lesson is this: AI tools work best on documents that are inspectable, portable, and boring underneath. When the file tells the truth about itself, humans can finally review the robot's work without becoming archaeologists.