The Paper That Reads Itself: How Papyrus Turns Research Into a Living Document

You are reading this on Papyrus right now.

That figure further down the page — the one you can drag, the worldline you can tilt, the sidebar that answers a question with a citation — is not a screenshot of a product. It is the product. This article is the medium explaining itself: a paper about living papers, published as a living paper.

So let's start with the thing every researcher already knows in their bones.

Research dies inside static PDFs

A paper can show you a conclusion. It can almost never show you the mechanism.

Imagine a paper proposing a faster-than-light signalling protocol. The whole argument turns on one uncomfortable fact: if a signal outruns light, the reply can arrive before the message was sent. On paper, the author draws a spacetime diagram, adds an arrow, and asks you to take it on faith. You cannot tilt the "now" slice yourself and watch causality break. You cannot turn up the damping term and watch the paradox close. The figure is frozen, and your first real question — the one that actually decides whether you believe the result — lands minutes after the author has left the room.

This is the quiet failure of the PDF. Three losses, every time:

• The mechanism is invisible. A static figure shows the output of a model, never the model. You see where the curve lands, not why.
• The reader can't talk back. Your question arrives after publication, with no one to answer it from the text.
• The proof is asserted, not demonstrated. "Trust me, the loop closes" is not the same as closing the loop with your own hands.

The instinct is to fix this with attachments — a supplementary notebook, a link to a demo someone will host until they don't, a video. But a bolted-on artifact lives outside the argument. It drifts, it rots, it breaks the moment a dependency moves. The paper and the proof go their separate ways.

Papyrus makes the paper itself interactive

Papyrus is an interactive research publishing platform — Next.js 14, TypeScript, Tailwind, Neon PostgreSQL with Prisma, NextAuth. Authors write in MDX, and where a static paper would drop a flat image, they embed a Visual Pack: a versioned, sandboxed HTML/JS micro-app rendered in an iframe and addressed from the prose with two small components, <Visual> and <Cue>.

The contract between the page and the figure is a real postMessage protocol, not a hand-wave. The parent sends the iframe {type:'cue', name, params} to drive it and {type:'setMode', mode:'interactive'|'print'} to switch it; the iframe answers with {type:'ready'}, {type:'event'}, and {type:'height', value} so the page can size it. The sandbox is allow-scripts on a separate origin, with strict origin validation — a figure can be lively without being trusted with the page.

That is what lets a sentence reach into a diagram. A key phrase in the text carries a cue; when you reach it, the figure responds. The proof stops being an attachment and becomes a limb of the argument.

Below is the whole idea, recursively. It is the Papyrus reader, rendered as a Papyrus Visual Pack — a paper inside the paper, on the fictional Causal Damping Protocol. Step the sections, drive the figure, ask the sidebar a question. Everything you touch is the platform doing the thing this paragraph just described.

Honest framing, up front: that embed is illustrative. The content is canned and deterministic — a fictional physics paper, computed entirely in your browser. No network call leaves the frame, no language model runs, and no retrieval crosses the sandbox. It is a faithful diagram of the reading experience, not a live session of it. The real reader behaves like this; this particular instance is a drawing you can poke.

Reading is a question, so Papyrus answers it

A living figure solves the "show the mechanism" problem. The second loss — that the reader can't talk back — needs a different organ.

Papyrus's answer is Ask Papyrus: grounded question-answering over the article itself. A reader's question is embedded with OpenAI's text-embedding-3-small (1536-dimensional), searched against pgvector chunks of the article stored in Neon, and answered by Groq's Llama 3 70B — streamed back with citations to the sections the answer came from. Not a chatbot bolted to the margin; a reader that has actually read this specific paper and will only answer from it.

In the demo above, the Ask Papyrus tab shows three canned, grounded answers, each closing with a Sources: §… line so you can see the shape of it. The shape is the honest part. The live product runs the real retrieval pipeline; the embed just shows you what grounded, cited answers look like.

The load-bearing part: the agent that builds the figures runs on Nexus

Here is where Papyrus stops being a clever front end and becomes something structural — and where precision matters more than the pitch.

Making figures interactive is easy to say. Doing it at the speed of writing is the hard part: an author shouldn't have to hand-code a sandboxed micro-app every time they want a live chart. So they don't. From the article editor, an author types a prompt describing the figure they want, and Papyrus generates it — as Agents-as-a-Service on Synaptix's governed platform, Nexus/AGENTS.

This is the genuinely load-bearing fact, and it is narrow on purpose: Papyrus the application holds no agent logic of its own. It does not orchestrate a model. It POSTs a prompt to the platform and streams back the work. Concretely, SynaptixAgentsClient is a thin SSE client that POSTs to /api/v1/platform/agents/{agentId}/stream with a service key, authenticated as the app key sl_app_papyrus in the AGENTS KeyVault. The platform runs a multi-stage, self-governing build and streams it back as typed events you can watch go by:

evaluate → facilitate → develop → review → judge.

The terminal done event carries the receipt: usage {tokens, cost_usd}, the judge's scores, and a judge_verdict of ship · iterate · restart. The Synaptix-Viz agent's output is already the exact Visual Pack format, so a compliance wrapper injects the bridge protocol, and the result is stored as a static, sandboxed pack — the same kind of pack you just interacted with. Cost is estimated before the run and metered through SXC, Synaptix Credits, on completion. The generation is governed and billed centrally, in one seam, instead of scattered across the app.

That is the whole AaaS thesis in miniature: the application transports a request; the agent decides and does the work; the platform governs and meters it. Papyrus never touches a provider directly for this — it talks to one layer, and the layer talks to the models.

What is not on Nexus yet — because honesty is the feature

It would be easy to round this up to "the whole platform runs on agents." It doesn't, and saying so plainly is the point.

Today, only the Visual-Pack generator runs as Agent-as-a-Service on Nexus. The reading and Q&A side — the embedding step, the RAG answer, the wizard and editor assists — still call Groq and OpenAI directly. Those agents already exist as seeds in the AGENTS catalog (papyrus-rag-qa, papyrus-wizard-assist, papyrus-editor-ai, papyrus-embeddings), but they are defined, not yet wired. Their migration onto the governed platform is deliberately deferred to Sprint 13. The thesis is "one governed platform behind every paper," with the Viz agent as the first proof — not the whole truth yet.

Honest status: an early-adopter surface, not a finished storefront

Papyrus is real and it is load-bearing, and it is also still in development. Both things are true.

The most recent closed sprint shut with 190 of 190 Playwright acceptance tests green and 33 bugs fixed across all 7 architecture non-negotiables, on top of 780+ Vitest unit tests. The current sprint is early-adopter release prep — measured, as we measure everything, in Vibes rather than days — and it is the sprint that wires the Synaptix-Viz generator into the article editor as Papyrus's first AGENTS integration. The agent ships behind a VIZ_AGENT_ENABLED flag with a graceful "AI Visual unavailable — upload manually" fallback, because a feature you can turn off cleanly is a feature you can trust.

So treat the live reader as what it is: a target and an early-adopter surface, not a generally available product with a marketing storefront. The architecture is finished enough to be load-bearing. The rollout is not finished, and pretending otherwise would betray the whole point of a platform that writes down what it runs.

The payoff is structural

Strip away the recursion and the demo, and what remains is a single architectural bet:

• The proof lives inside the paper. A Visual Pack is versioned and sandboxed, so the mechanism ships with the argument instead of rotting in an appendix.
• The reader can interrogate the text. Grounded, cited Q&A turns a published paper back into a conversation.
• The agents that build it are governed in one place. The figure generator runs on Nexus today; the rest are seeded behind it, queued for the same seam, so governance and metering arrive for the whole platform by routing through one layer instead of bolting it onto each feature.

Every interactive figure on this platform points back to the same idea: a paper should be able to show its mechanism and answer its reader, and the machinery that makes that possible should sit on one governed platform — not in a pile of API keys behind every article.

You just read that claim. Then you dragged it, tilted it, and asked it a question.

---

Papyrus · research that comes alive — you're reading this on it.