Case study, in development
Quillsmith
A long-form writing system for authors, and the product we build for ourselves. It is where we run one tool registry, one admission point, every surface a rendering of that pair, at full scale before recommending it to anyone else.
What it is
An author writes prose. Quillsmith reads it and keeps a model of the world the book describes: who the characters are, where things happen, who is related to whom, what state someone is in at a given point in the story. Nobody types that model into a form, and every fact in it can name the paragraph that established it. On a long draft, which paragraph said that? is the question an author actually asks.
There are two writing applications. Lite keeps to the chapter and the page; Pro keeps the whole book beside the chapter. In front of both sits a gateway for accounts: sign-in, sessions, usage, and the personal access tokens an outside client authenticates with. Beside them is a Model Context Protocol server, so a model the author already uses can work on the same projects.
All of it shares one tool registry, one component library and one set of interface strings, in English and German. The applications are views onto that layer, not separate products that happen to share a login.
- 61
- tools in one registry
- 39
- in the external catalogue
- 1
- admission point between outside callers and the registry
Counted from the code on 28 September 2026.
The decision that mattered
Every product that grows an AI feature eventually grows a second one: the assistant inside the application, and the surface that lets somebody else's model drive the same system. The default is to port the first into the second. A port is a copy, a copy has an owner, and an owner has a backlog.
Quillsmith has no second definition. The external server's catalogue is a filtered view of the internal registry, every call it makes into that registry goes through one admission point that checks exposure, ownership and usage limits, and every operation it starts runs through the same route into the same work queue as one started by the product's own assistant. It adds transport and nothing semantic. Parity is not a checklist item someone has to maintain; it follows from the composition.
What the protocol forces us to build anyway lives in an assembly of three files. There is a status tool and a bounded wait, because the protocol gives a server no way to push to a model. There is the project argument a caller without a conversation must pass on every call, injected into the schemas rather than written into the tools. And there is a short table of tool descriptions that are true only inside a conversation, rewritten for the outside. The capabilities themselves are not in that assembly, and a test fails the build if it ever reaches below the application layer.
What it got wrong first
The pattern only works if the registry meets some preconditions, and most of the engineering went into meeting them: a tool interface that already speaks the protocol's language, host-side annotations kept apart from the schema the model sees, with defaults that fail closed, and exactly one place where authorisation is decided.
The first external catalogue listed the tool that creates a project while the call handler demanded a project for everything, so the documented way in was impossible to execute. A test now derives the catalogue from the registry independently and fails the build unless it is exactly the set of tools an outside caller can invoke.
A second test fixes the list of tools that exist only on the protocol surface, with the reason for each written beside its name. When the paper on this architecture was written on 14 September 2026 there were four. There are eight now, and each of the four added since went into that test with its reason attached. That is the guard doing its job: the slow failure of a projection is not a rewrite, it is one exception at a time.
Measured, not estimated
On 16 August 2026 a complete generation run, from a premise to a world, a structure and ten chapters, made 64 model calls and cost seventeen cents. Sending a typical finished manuscript into a single call costs about eighteen. Numbers like these come from what was billed, not from the pricing page, and they end arguments: blanket whole-book context would cost roughly twelve times the entire run for every chapter it touched.
The same habit finds waste that nothing else would. In July we found reference extraction running three times for every entity created through chat, because three layers each called it on the same unchanged text, and the storage layer was idempotent enough to hide it completely.
Undo is kept free on purpose. Rolling back AI-generated work restores the text, re-derives the deterministic part of the world model at no model cost, and reports which model-derived facts are now stale, so the author decides whether a refresh is worth paying for. It was checked live on 27 August 2026 against a thirteen-entity rename cascade: nothing failed, and exactly the eight entities the cascade touched were reported stale.
Written up in full
- The MCP Server as a Projection of the Tool Registry
A customer wants to drive your product from outside it. Declaring your tools again in the new protocol's vocabulary ships in a week and leaves you with two definitions of what your system can do, drifting apart. What it takes to make the external surface a rendering of the internal one instead.
- Which Paragraph Said That
A world model derived from prose instead of typed into a form, where every fact can name the sentence and the paragraph that established it. What per-fact provenance costs, what it makes possible, and when a form is the right answer instead.
- Sixty-Four Calls and Seventeen Cents
In August 2026 a complete generation run made 64 model calls and cost seventeen cents; sending the finished book into one call cost eighteen. What we learned about agentic cost by paying the bills rather than the pricing page.
What carries over to client work
None of this is specific to writing software. Find the one definition of what a system can do, or build it. Decide authorisation in one place. Turn each guarantee into a test that fails the build, so it outlives the people who wrote it. Measure cost from the bill. Quillsmith is where each of those was tried first, on a system we have to live with ourselves.
If you have an internal tool layer and a customer asking to drive it from outside, the question worth asking first is not which protocol. It is whether you have one definition of what your system can do, or are about to create a second one. That question is what thetwo-week audit answers.