A medieval scribe spent months at his desk to make a single book. He copied it one letter at a time, and when he was done he checked it line by line against the original and corrected the errors. The work was slow, but it had one clear virtue. Once a book was proofed and bound, it no longer changed. No one could slip in overnight and rewrite a sentence. What was written in the book was settled.
An earlier piece looked at the philosophy Notion was built on: that tools shape how we think, so we should give people the raw material to shape their own tools. Underneath all of it ran one quiet assumption — that the one handling the tool is a person. And that assumption is now wobbling, because the job of reading and writing documents is increasingly being handed to AI agents rather than people. Suddenly the old virtue of the scribe’s book — that once settled, it stays settled — matters again.
Agents want a different kind of document
By “AI agent” I mean an AI that carries out work on a person’s behalf. It doesn’t just answer one question and stop; it walks through several steps on its own — finding and reading documents, editing code, writing the results back into a document. When an agent becomes the one doing the work, the definition of a “good document” shifts from what it was when the reader was a person.
For a person, a good document is one that’s easy to look at. Color, neatly aligned tables, something that lands at a glance. That’s exactly what Notion is good at. But for an agent, a good document is one that’s easy to handle — fast to read, with the changes plainly marked, and trustworthy enough to act on. By that standard, two old technologies pull ahead: markdown and git.
Markdown is a lightweight way to write formatting in plain text. You put a # before a heading and wrap emphasis in symbols, so the file itself is just a block of characters that both a person and a machine can read directly. Git is a tool that tracks the history of those files. Who changed what, when, and why is recorded line by line, and the state at any given moment can be stamped and stored whole. Put the two together and a document gets treated like code — a practice usually called docs-as-code.
For an agent, this combination is close to ideal. Because the files are just text, it can pull in dozens of them in an instant and find the exact word it’s after in one pass. Whatever changed is recorded precisely in the history. There’s no need, as there is with Notion, to spin up a screen and assemble blocks one by one.
The two weak spots of Notion’s blocks
Notion stores everything as a unit called a block — the elegant structure the earlier piece described. But once an agent rather than a person starts handling the documents, that same structure becomes a liability in two places.
First, it’s slow. Everything in Notion is a block, and a block is data stacked away on Notion’s servers. To open a single document, you have to fetch that data whole and assemble it on screen. A person opening one page and reading it doesn’t notice the delay, but for an agent skimming dozens of documents fast, each round trip to the server is pure cost. Against something that reads a text file directly, the speed gap opens wide.
Second — and this one matters more — there’s no settled version. For an agent to trust a document, take it as correct, and work straight from it, that document has to be a source of truth. And that requires two things. One, the agent has to be able to point back later to the exact version it read. Two, there has to be some guarantee that the content was reviewed and is reliable. Notion structurally lacks both.
In git, a change to a document isn’t reflected the moment it’s made. What someone edits first goes up as a pull request, and only after another person looks it over and approves it does it land in the official document. The instant it lands, that state is stamped to a single point in time and frozen. So anything in the official document automatically carries a trust grade — someone reviewed and passed this — and the agent can return to “that version at that moment” any time it likes.
Notion is the opposite. Anyone edits a document directly, at any time. A reviewed, settled version and a guess someone jotted down a moment ago look identical on screen. And because the document is always live and moving, there’s no way for an agent to point back to the version it read thirty minutes ago. Notion’s always-editable, always-collaborative nature is a clear advantage for people. But the moment you try to make it a source of truth, that very trait trips you up.
So when companies move their internal docs toward lightweight markdown and git, this is ultimately why: it’s too slow, and a Notion document — always changeable, with no review step — is hard to treat as a precise reference. A trait engineered for human convenience flips into a weakness in the seat reserved for an agent’s trust.
But are blocks only a weakness?
There’s an interesting twist. From another angle, the very structuredness of Notion’s blocks turns into an asset for the agent.
Markdown is free, but it’s vague. It’s hard to point precisely and say “fix the third item in this table,” because it’s just a block of characters. A Notion document, by contrast, is made of blocks that each carry a unique marker and a type. That actually makes it better for an agent trying to aim precisely — “change this block to this.” The insight from the earlier piece, “if everything is a block, then it’s a language,” reads differently in the agent era: it now means a structured interface an agent can address exactly.
So Notion’s block is a weakness and an asset at once. That two-sidedness shapes Notion’s entire response.
Notion’s answer: from the human screen to the agent’s backyard
Notion didn’t go the route of “defend blocks against the markdown tide.” Instead it left the blocks as they are on the inside and built a bridge at the boundary for agents to cross. What it announced in May 2026 makes the direction clear.
- An agent connection point (MCP). Notion opened a standard channel that lets external agents like Claude or Cursor find, read, and edit a Notion workspace directly. It patched the weak spot — that agents struggle to handle Notion directly — with a standard interface.
- Taking markdown as input. An agent can throw content at Notion in the markdown it’s comfortable with, and Notion converts it into blocks on its own. Markdown on the outside, blocks on the inside — the heart of playing both sides.
- Notion Workers and custom agents. Small automation programs (workers) that run inside Notion pull in outside data, let you build automation tools without a separate server, and run agents that handle recurring questions or classification tasks within an organization. Notion founder Ivan Zhao’s slogan for it: “Any data, any tool, any agent.”
Boiled down to one line: Notion is moving its own position from the screen a person looks at to the backyard an agent reads and writes in. One figure Zhao let slip captures the shift — more than half of the databases now created in Notion are made not by people but by agents.
Where the battle line falls
That doesn’t mean Notion is trying to win every fight. It deliberately divides the line.
Scattered markdown files are strong for individual work and weak for organizational work. For writing alone and handling code, lightweight text and git are all but unbeatable. Notion has no reason to win here, so it just connects via the bridge (the MCP above). But the story changes the moment several people and several agents need to read and update the same knowledge at once. Who can see what (permissions), how items relate to each other (relationships), who changed what and when (history) — all of it has to be managed in one place. That’s territory scattered text files can barely reach, and it’s exactly where Notion throws its full weight.
It’s also the point Zhao named as the next challenge. Not building one good agent, but how a single organization runs and manages a “factory” of dozens to hundreds of agents. Notion wants to set itself up as that control tower — the place where permissions, collaboration, and auditing converge.
Notion’s bet, and its weak point
The strategy has one clear weak point.
Once handling documents passes to agents, a weapon Notion long held loses its edge: the pretty screen. People grow attached to a good-looking workspace and don’t leave easily, but an agent doesn’t care whether the screen looks nice. It just picks whichever side is cleaner to handle. At which point Notion risks getting marked down to “one storage option among many.” The charm that kept people in place is useless the moment the customer becomes an agent.
So Zhao’s answer ultimately stakes the company on a single sentence. For an organization’s knowledge that many people and agents share, Notion — binding structure, collaboration, and permissions in one place — beats scattered markdown files. If the bet is right, Notion becomes the base layer of organizational knowledge in the AI era. If it’s wrong — if agents just pick lightweight text and git and route around Notion — then the old criticism from the earlier piece, “isn’t this just a closed filing cabinet in the end,” becomes real.
Tools shape us, again
The first piece in this series started from a line of McLuhan’s: we shape our tools, and thereafter our tools shape us. That sentence kept a person as its subject the whole time. The one shaping the tool is a person; the one shaped by it is a person.
The age of agents twists the sentence. The hands that shape and handle the tool are increasingly an agent’s, while the one being shaped by it is still us. A tool we neither made nor touched shapes our thinking all the same. So Notion moving its blocks from the human screen to the agent’s backyard isn’t just one company’s product strategy. It’s a small scene from a larger question: how will the tools we no longer touch ourselves go on shaping us?
The idea that you can delegate the execution of work to a tool but never the understanding continues in You Can Outsource Thinking, But Not Understanding; how agents reshape the very form of an organization continues in A Taxonomy and Evolution of Org Structures.
— tomte