They Stopped Sending PDFs and Built Pages That Update Themselves

Here is a small humiliation that anyone who writes proposals will recognise. You spend a day on a PDF. You check the margins, fix the orphaned heading on page nine, export it at the right resolution. You know, while you are doing it, that the person receiving it will read page one and maybe skim page three.

IA per tutti, an Italian AI newsletter with more than 22,000 subscribers, got tired of that trade. They stopped sending presentations, PDFs and spreadsheets almost entirely and replaced them with interactive pages that update on their own. The 19 October post reads like a house-style announcement, but the mechanics underneath it are worth pulling apart, because they solve a problem that has nothing to do with slides.

The argument against the document

Their case is about reading order, not aesthetics. A PDF is consumed exactly one way: top to bottom, with some skipping. An interactive page lets the recipient open the two sections they care about and ignore the rest, which means you can put more information in without losing them. A proposal built as a page can carry the full scope, the case studies, the pricing logic and the timeline, because the reader assembles their own path through it.

That is the whole theory, and it holds up. Documents are linear because paper is linear. Nobody has needed linear for about twenty years, and the reason we kept the format is that a well-typeset page used to cost real money and real skill.

The cost is what changed. In their workflow, you paste a prompt that refers to a page you have already built and approved into Claude, add the content, and it produces the page, checks it on a phone viewport and deploys it. There is code at the bottom of it. The person operating it describes the job in Italian.

The bit that is actually the product

Skip past the pages for a second. The thing that makes this repeatable is a folder on GitHub that the team calls their second brain, where each person saves the procedures that have worked. Claude follows those files the way a new hire follows a manual, and when someone corrects a mistake, the correction goes back into the skill rather than into a chat log that dies at the end of the session.

That is the design decision worth stealing. A generated page is a view. The procedure file is the process. Most teams doing this in 2026 have the first and not the second, which is why their output drifts: the fourth proposal in a series looks nothing like the first, because every generation started from a different description of what a proposal is. The one-person version of the same split, where a solo creator turns their own work into agent-run production lines, is in this earlier piece.

Their example is concrete enough to picture. A sales lead kept asking for an updated project deck as new work landed, and each version needed someone to write the cases, lay them out and paginate. The fix was not a better deck. It was a sentence: add these two projects. The agent writes to the projects database, checks whether the team has worked with that client before, updates the page and emails a summary of what changed. A human reads it and either confirms or says what is wrong.

Note where the review sits in that loop. After the change, before the send. That is the correct place for it and it is easy to get wrong.

When the agent should answer with a page

There is a second idea in the post that I think is more useful than the deliverable format. The author notes that agents force a lot of decisions and answer in walls of text, which trains people to accept recommendations passively. His counter is to ask for a page instead: the recommendation, the reasoning, the numbers that matter, the projection with the monthly figure. Same content, laid out so a person can actually evaluate it. He claims it also saves tokens, which is plausible since a table is denser than prose.

This applies well outside client work. Any recurring decision that arrives as six paragraphs of argument is a candidate for a two-column layout. The constraint of laying it out also forces the agent to commit to a number, which is where the argument usually gets interesting.

The honest caveat the format creates

A live page has a failure mode a PDF does not, and the post does not dwell on it. A PDF is frozen and therefore honest. It says what it said the day it was sent. A page that updates itself can quietly become wrong: the data source moves, an API changes, a project gets deleted from the database, and the page keeps serving a clean layout over stale numbers. Whoever owns the page owns a small piece of software now, with everything that implies.

Two habits cover most of it. Every page needs a named source of truth, for example the projects table, and a rebuild trigger, so the content is derived rather than hand-edited. And every page needs an audience decision made before it is built: internal pages can carry margin math, client-facing pages cannot. A PDF cannot leak its own revision history or get indexed. A page can do both, and the client who forwards a link is not thinking about that.

The other limit is variety. This approach pays off when you send the same kind of document repeatedly: a project index, a proposal skeleton, a margin calculator, a status page. For a single forty-page report that will never be reused, building a page costs more than it returns, and a PDF is still the right answer.

Where I would start

Pick the document you resend most often, not the one that is most annoying. Build one page for it and keep the layout deliberately plain. Do not write a skill file on the first attempt; do it after the third successful run, when you know which instructions were load-bearing. Then let the agent generate the fourth and compare it to the third, because that comparison is the actual test of whether your procedure file works.

On the "do you need an app" question, the post is refreshingly blunt. Usually not. Their sales lead ended up with a calculator that shows how fixed costs weigh on margin, and she runs negotiations with it. The author wired Circle and Stripe into a dashboard and stopped reconciling spreadsheets by hand. Neither is a product. Both replace a recurring hour. He also notes the practical ceiling: version one often holds for months, and a proper BI tool is still a proper BI tool.

They kept standard documents for the cases where the format is the signature, meaning offers that need signing. That is the right boundary. A contract is linear because a contract is a legal object, and no amount of generation changes what a signature attaches to.