The Tools Are Dead. The Formats Survived.

SaaS is not dead. The seat still renews. What died is the tool as the place where work happens. I have not opened PowerPoint to make a slide in six months; it opens for twenty minutes to show a deck made somewhere else. The tool became a distribution contract.

Yoram Friedman, MD
– 8 min read
The Tools Are Dead. The Formats Survived.

I am building three presentations this month, and last week I noticed something about how I am building them. I have not opened PowerPoint to make a slide in almost six months. I have not opened a word processor to write a paragraph in the same period. In that time I published dozens of articles and four books, and the decks for an enablement series I teach inside SAP are on their fourth and ninth versions. All of it was made, and none of it was made in the tools that were built for making it.

The only time PowerPoint opens on my machine is the twenty minutes of a Teams meeting, when the deck has to be shown to people. Then it closes again. That is the whole of what an entire category of software has become in my working day: the projector.

Since spring the obituaries have been for SaaS. Agents will replace the seat, the subscription is dead, the application layer is over. I do not think that is the right obituary. The seat is still paid for. The subscription renews. What died is something quieter and, for the people who make these products, worse. The tool stopped being where the work happens and became the format the work is delivered in.

Where the work went

The way I work now looks like the way a developer writes code this year, and that resemblance is the whole story. I open Claude Cowork or Codex, I describe what I want the deck to achieve, who it is for, what they should know and feel and do by the end, and I run the six-role loop I described in "Where the Time Came From": a spine I write by hand, research in parallel across three models, one model drafting, a different one judging, one coaching the voice, and me at the top deciding what is true and what ships. The artifact that comes out of that loop is a text file. Markdown, with the structure in headings and the slide notes inline. That file is the presentation. It is versioned, it is searchable, it is the thing the next iteration is built from, and the loop runs on it in something close to real time.

At some point a person downstream needs it in a shape they can open. A reviewer wants a Word document. The meeting wants a .pptx. The printer wants a PDF. So the artifact is rendered, once, into the format that person's tool understands, and the tool's entire contribution is to display it. The .pptx is not the deck. It is a snapshot of the deck, taken for the meeting, in a format the meeting can read.

Which means the productivity suite has been demoted to something it was never designed to be: a distribution contract. A codec. The agreed shape in which finished work is handed to somebody else's software. That is a legitimate job. PDF has done it honorably for thirty years. But it is not the job PowerPoint was built to do, and it is not the job the roadmap is priced for.

The conversion tax

The demotion would be harmless if it were free. It is not, and the cost shows up as latency.

A .pptx is a format built for a person editing in place with a mouse. Every object has a position, a size, a style, and a history of being nudged by hand. An agent regenerating a deck from the text source does not nudge; it rebuilds. So every round trip through the format is a rebuild, and every rebuild is a place where the two ways of working collide. If I move a text box by hand in the rendered file, the next regeneration from the source does not know I did it and puts it back. If I ask the agent to tighten section three, the hand edits I made in the .pptx are not in the source, so they evaporate. The two channels do not share an artifact, and the format is what keeps them apart.

For a fortnight my presentations lived in a version dance for exactly this reason. Version nine of one deck was approved and the lesson from it had to be carried into the next two, which meant carrying it through text, regenerating, checking the render, adjusting, regenerating again. The loop that produces the content runs in seconds. The step that produces the file the meeting can open runs in minutes and loses information each time. The format was designed as a working surface for a human, and I am asking it to be a checkpoint for an agent, and it is bad at that because nobody built it for that.

This is not a complaint about a bug. It is a description of a contract that expired. The contract, for forty years, was that the screen is the page: what you see is what you get, and the way work enters a document is through a human's hands on that screen. Every productivity tool is a bet on that contract. The bet lost, not because hands stopped mattering but because they became one of two channels, and the slower one.

What I actually want

I want one view of the artifact that I can change by hand and by prompt at the same time.

The hand is for the local edit: move that box, cut that word, swap those two slides, because nobody is going to describe a two-millimeter nudge in a sentence. The prompt is for the structural edit: make the middle section half as long, carry the argument from slide four through to the close, unify the color story with the previous deck. Both edits land on the same artifact. Neither overwrites the other, because the artifact is the source of truth and both the rendering and the chat are views of it. And at the points where a human downstream needs a file, I save a checkpoint into whatever format that person's tool can open, the way a developer tags a release.

Developers already have this. It is called the editor. A coding agent and a human edit the same buffer, the file is the truth, git is the checkpoint, and the rendering is whatever the runtime produces from the source. Nobody in software argues about whether the agent should live inside the compiler. The productivity suite has no equivalent yet, and the difference between the two answers being built right now is the difference between a roadmap and an obituary.

One answer puts the model inside the tool. This is no longer a thought experiment: Claude has had a PowerPoint add-in since February, ChatGPT since May, alongside Copilot. They are good. They read the slide master so the deck comes out in your brand, they produce native editable objects rather than pictures of slides, they ingest notes and documents and previous decks, and the ChatGPT version will read a finished deck back to you and name the weak slide. If the question were only whether the model can help inside PowerPoint, this answer wins and the article ends here.

But look at what stays fixed. The file is still the source of truth. The mouse is still the primary channel. The model is a very capable colleague who has been let into a format built for hands, and every structural change it makes still has to be reconciled with whatever your hands did last. It keeps the seat, and it keeps the tax, because the artifact is still the binary.

The other answer puts the tool underneath the artifact. The source is text plus intent plus history; the agent works on the source; the rendering is generated and disposable; the hand edits are captured back into the source rather than into the render. That is what I am approximating today with a markdown file, a build script, and a loop, and it is clumsy, and it is still faster than the first answer, which should worry anybody whose revenue depends on the first answer.

What the file cannot hold

The speed is not even the main reason I stopped opening the tool. The main reason is what the loop can see that the file cannot.

When I build a deck in the loop, the source material is my own body of work: every article cataloged, four books, the previous decks in the same series, the reading notes, the framework register. The agent reads all of it before it drafts a slide, and the deck comes out consistent with everything I have already said, because it was built from it. An add-in can ingest a document I attach. It cannot stand on a library I have spent a year organizing for exactly this purpose, because that library does not live in the file, and the tool has no idea it exists.

Research runs in parallel, across three models, before the outline is settled, and the disagreements between them are where the interesting slides come from. The images are generated to the argument rather than found for it, which means the slide that needed a picture of a warehouse manager looking up from a dashboard got that picture, in the deck's own palette, in a minute. The judge model checks every number against its source before the deck goes anywhere near a room. What comes out is not a set of slides. It is coverage of a topic from every angle I know, compressed into a form a meeting can consume.

None of that happens inside PowerPoint, not because the add-ins are weak but because the file is the wrong container for it. The library, the research, the judge, and the voice are all outside the file, and they are the part that makes the deck worth showing. The .pptx is just the distribution contract.

Three roadmaps

Every application in the suite now has one of three futures, and which one it gets is a product decision its owner is making right now, mostly by default.

It can become the viewer. The twenty minutes in the meeting. Necessary, universal, and worth very little, because a viewer is a feature of the operating system, not a product.

It can become the checkpoint format. The exchange standard the artifact is rendered into when a human downstream needs it. Durable, boring, and valuable the way PDF is valuable: nobody loves it, everything passes through it, and no one pays much for it.

Or it can become the working surface where both channels meet, the one place the artifact lives with its history, its intent, and its two ways of being edited. That is the only future with a product in it, and it is the one that requires admitting the file was never the thing.

The interesting exceptions are the tools that were already halfway to being editors. A spreadsheet is a program with a visible surface; the cell is code and the grid is the render, which is why Excel will survive this in better shape than Word. An image editor with layers is closer to a source-and-render model than a slide deck ever was. The tools in the most trouble are the ones whose entire value was the direct manipulation of the final form: the slide, the page, the poster. The final form is exactly the part the agent now produces on demand.

The tool is a format now

In "Where the Time Came From" I wrote that the tools are rented and the layers are owned. Six months later the tools are not even where I spend the rented time. Efficiency went up, sharply, and the productivity applications did not go up with it. They went sideways, into the role of a format, opened for twenty minutes to show a room something that was made somewhere else.

Nobody in the meeting can tell. The deck looks like a deck. That is the tell. When the output is indistinguishable and the tool was not involved in making it, the tool has already been replaced and has not yet been told.


This article is part of an ongoing series on AI product design, healthcare data, and the human side of technology adoption.


Share