Open the Notion workspace of any small agency and find the teamspace named after a client. There's a strategy page in it, written with real care, last edited the month the engagement started. The client's ops manager was invited as a guest once. She opened it, read the strategy, and never came back, because nothing that happened afterwards was written there. The current plan lives in a Slack thread.
That page is the Notion row of our replacement ledger. This is part of a series on SharpOS, the workspace SharpHaw runs client engagements in, and it's about Pages: what Notion and Confluence do well, why the client wiki rots anyway, and what we built instead.
TL;DR: a wiki rots when it lives in the wrong house. Pages puts the docs inside the client's own workspace, next to the work and readable by the agents that do it.
What Notion and Confluence are for, and where they strain
Both are good at the shape of the problem. A block editor, a tree of pages, comments, a search box. Notion made writing feel light; Confluence made a company's knowledge navigable by team. If your documentation problem is internal, either one will hold it.
A client engagement is a different problem, and the strain shows in the boundary rather than the editor. The workspace belongs to the agency. The client is a guest in it, with the permissions a guest gets, in a tree organised the way the agency thinks. The page that describes the client's own business sits in someone else's house. "Confluence is where documentation goes to die. And then rot," as one HN commenter put it, and another named the cause a few years later: "Team knowledge lives in Notion (or Confluence, Google Docs, etc), but updates actually happen in Slack threads, Zoom calls, and email chains." The doc is far from the work. So it drifts.
There's a second problem that only shows up at the end. When the engagement ends, the client's docs are export files from the agency's workspace, if anyone remembers to export them.
What Pages does instead
Pages is the document surface of SharpOS. Each client is an Organization, and the page tree lives inside it: the client's strategy, research, playbook and operating docs sit in the client's workspace, and the agency works there as a member. You can click around one in the Whitmore & Finch case, a browser-only showcase fed by fixtures, no account needed.
Three things follow from that boundary.
Every page is client or internal. client means every member of the org can read it. internal means platform admins only; an org owner can't see or toggle it. So the agency's own working notes sit in the same tree as the client's docs without leaking, and the route answers "missing" and "forbidden" with the same 404, so the shape of the error discloses nothing.
Pages are written where the work is planned. A card on a board carries a brief page; the card that ships on Thursday links to the page that says why. Our own editorial Playbook is a page tree, and every content run loads it before it writes a word, so the doc gets read by something every day — the only cure for rot I've found that holds.
And a page is markdown when you need it to be. One call returns any page's body as markdown, and the same surface accepts a full replacement. The export is the read endpoint, available from day one rather than negotiated at the end.
How it works
One editor serves pages, board card bodies and customer notes. It's a block editor with realtime sync and presence underneath, so two people can type in the same brief and see each other's cursors. Read and write checks are enforced by the backend rather than by the client; a locked page stays readable and rejects every edit. The org-scoped Live Collab flag controls presence and comments, and switching it off removes exactly those two things, never access or editing.
The decision I'd defend hardest is that the API is markdown-first and section-aware. An agent doesn't need to know anything about the editor's internal blocks to update a doc: it names a heading, sends the new markdown for that section, and the page replaces the matched heading and everything under it up to the next heading at the same or higher level. Collapsible headings survive the round trip, so an agent that reads a page, changes one section and writes it back doesn't flatten the rest. Locked pages refuse the write and say so. For the rare case where a single paragraph needs touching, there are block-level edits that fail as a unit if anything they reference is missing.
One thing I got wrong, for the record. Every open editor keeps a live subscription to the page's latest version, and for a while that subscription failed every time a sign-in token refreshed under an open page, which took the page down. It was our highest-volume production error, 1,463 occurrences before I understood it. The fix is narrow on purpose: that one read answers a caller without a session with an empty document, while every other read keeps failing closed. Widening the tolerance would have made every caller that swallows the error fail open, so it stayed scoped to the session-absent case.
What it doesn't do
Pages is shallower than Notion, and I'd rather say where than let you find out. There are no databases-as-pages, no formulas or rollups, no template gallery, no publishing a page to the public web. Structured data lives on properties and boards instead, which is a deliberate split rather than a gap on a roadmap. If your team runs its whole company on Notion databases, keep Notion. If you need Confluence's space-level permission schemes and macros for a few hundred people, Pages isn't aimed at you either.
What it's aimed at is narrower: the documents of one client engagement, in that client's workspace, kept current because the work happens beside them.
Where it sits in the service
Pages carries the SharpHaw Content Engine: the Playbook, the briefs, the research, and the plan for what ships next week all live there, and every SharpHaw subscription includes the workspace (sharphaw.com/sharp-os). The feature page with the walkthrough is sharphaw.digital/features/pages.
Your turn
If you keep client documentation in your own workspace, whose house is it in, and when did the client last open it unprompted?
This is part of SharpOS, surface by surface. Part 1: We replaced a 12-tool client stack with one workspace we built. Here's the row we couldn't.
Top comments (0)