Latest
Newest first, across every subject. There is also an Atom feed that carries these posts and the dated release notes from the changelog in one stream.
- x402 and MPP, explained without the hype Both answer one question — how does a program with a wallet pay for an HTTP request with no human present — and both reduce to the same four-step handshake. This deployment implements neither, on purpose.
- Artifacts in Claude Code, explained An artifact is a live preview of a file the model just wrote, rendered beside the conversation. It is excellent at seeing the thing and awkward the moment you need a URL to send someone.
- Publishing from the front page A paste box on the marketing site that posts to the anonymous endpoint — and the content-security work it took to make that box actually run.
- The dashboard speaks WebMCP Instead of adding a chatbot to the product, the product declares what it can do on the page and lets the user's own agent call it.
- When agents render HTML A tool can return an interface instead of a paragraph, sandboxed inside the client. Useful — and a surface rendered in a chat window still has no address you can send anyone.
- Elicitation and sampling Normally the client calls the server. These two invert it — one asks the human for a value mid-call, the other asks the client's model to think.
- Reading an MCP spec revision A method rather than a changelog: which parts of a server absorb protocol change, which amplify it, and how to build so a revision costs an afternoon.
- Skills vs MCP vs API Three layers that get compared as if they were alternatives. They stack — and this deployment ships all three.
Why a publish primitive
The argument the whole deployment rests on: an agent that can write a page but cannot put it anywhere is only half a tool.
- Why agents need a publish primitive A publish primitive is one call that turns a finished file into a URL. Everything a project-shaped host adds on top of that is cost an agent cannot amortise.
- What agents actually publish Single self-contained files, small, and usually meant for one person. Every design decision in this deployment follows from that shape.
- Private-by-default hosting Public-by-default was fine when a human wrote every page by hand. It stopped being fine when the author became a program assembling pages out of context.
- The throwaway dashboard Building a bespoke dashboard on demand is cheap enough to be disposable. The awkward step is that a disposable artifact still needs an address and an expiry date.
- When a loop hits a paywall Long-running agent loops are designed around what to do next, rarely around what to do when the next step costs money. Removing the paywall is one honest answer.
MCP, in practice
What the protocol actually asks of a server, written from the position of having implemented twelve tools, OAuth 2.1 and Streamable HTTP rather than from the spec alone.
- What an MCP server actually is Three primitives, two transports, and one honest reason it caught on: it turned every integration from an N×M problem into an N+M one.
- Tools vs resources vs prompts Tools are model-invoked, resources are client-read, prompts are user-chosen. Pick by who holds the decision, not by what the data looks like.
- Skills vs MCP vs API Three layers that get compared as if they were alternatives. They stack — and this deployment ships all three.
- Reading an MCP spec revision A method rather than a changelog: which parts of a server absorb protocol change, which amplify it, and how to build so a revision costs an afternoon.
- Elicitation and sampling Normally the client calls the server. These two invert it — one asks the human for a value mid-call, the other asks the client's model to think.
- When agents render HTML A tool can return an interface instead of a paragraph, sandboxed inside the client. Useful — and a surface rendered in a chat window still has no address you can send anyone.
- The dashboard speaks WebMCP Instead of adding a chatbot to the product, the product declares what it can do on the page and lets the user's own agent call it.
- Publishing from the front page A paste box on the marketing site that posts to the anonymous endpoint — and the content-security work it took to make that box actually run.
Agent output, and where it goes
Artifacts, canvases, sandboxes and chat-window previews — what each one is good at, and the moment each one stops being enough.
- Artifacts in Claude Code, explained An artifact is a live preview of a file the model just wrote, rendered beside the conversation. It is excellent at seeing the thing and awkward the moment you need a URL to send someone.
- What live artifacts are, from the reader's side A live artifact updates as the model edits it, which is a gift to the author and a hazard to the reader — the thing they were sent can change under them, or vanish with the session.
- Why an artifact can't give you a stable URL The friction with sharing agent output is not making a link once — it is making the same link keep pointing at the latest version. A preview bound to a message cannot, and a replace-in-place URL is built to.
- Sharing an artifact publicly: what “public” should mean Turning an artifact into something a stranger can open is the moment access control starts mattering. The safe default for agent output is unlisted-and-gated, not public-and-indexed.
- Sites in Codex, explained A coding agent that can turn its output into a site removes the copy-paste step. What is usually still yours to decide is who can open it, how long it lives, and whether the same link updates.
- Can you make an agent-published site public? Yes, and it is one deliberate choice per link. The more useful answer is that public-and-indexed is the wrong default for output an agent assembled from its context.
- Putting an agent-published site on your own domain A custom domain turns an unguessable token into a hostname you own. The CNAME-and-TXT verification exists so the certificate is only ever issued to someone who controls the DNS.
- “Sites” from a chat assistant, and the primitive underneath A chat product that turns a generated page into a link is doing one thing: exposing a publish primitive. The interesting questions are the same three every time — reach, lifetime, and whether the link updates.
The one-click hosting category
Drag-and-drop deploys are a genuinely good product for humans with a folder. This is where the shape of the problem changes when the author is a program.
- Drag-and-drop deploys, and where the shape breaks for agents Dragging a folder onto a page and getting a URL is a genuinely good product — for a human with a folder. The shape stops fitting the moment the author is a program producing one file at a time.
- A drop deploy on the platform this runs on A one-gesture deploy and this publish primitive can sit on the same edge platform. They serve different authors — a person with a folder, and a program with a file — and it is worth being clear which you are.
- What a “quick” publish button really proves When a platform bolts a one-click publish onto its product, it is proving something useful: that turning a document into a URL should be a single act. The lesson is the primitive, not the platform.
- Embedding HTML in a doc, and why a link is stronger Pasting HTML into a document that renders it is convenient and brittle: the markup is trapped in a container's rules. A page at its own URL keeps its behaviour, its gates and its portability.
- Why pasting HTML into chat isn't sharing it A chat client shows a preview of an attachment or a wall of markup; neither is a page a recipient can open, keep, or forward. A link that unfurls into a preview card is the thing that travels.
Privacy, reading and measurement
What a shared link leaks, what we refuse to record, and what the author is allowed to know about a reader.
- Do AI agents leak secrets when they publish? Agent output is assembled from context, and context is full of query results, customer rows and the occasional token that fetched them. Public-by-default is the wrong posture, and a scan before storage is the backstop.
- Engagement without recording who the reader is You can learn whether a page was read without learning who read it. This deployment aggregates dwell, scroll and read-to-end, and deliberately does not build a per-reader profile.
Agents paying for things
Two payment protocols, one honest reason this deployment implements neither, and what the handshake looks like if you want to add it.
- x402 and MPP, explained without the hype Both answer one question — how does a program with a wallet pay for an HTTP request with no human present — and both reduce to the same four-step handshake. This deployment implements neither, on purpose.
- How to add x402 to this deployment A concrete sketch of the four pieces you would bolt on — a challenge, a facilitator, a provisioned-record, and a retry path — and which of them the account model already has.
- x402 in production: the parts nobody demos The handshake demos in a minute. The operational surface — settlement latency inside a request, refunds, disputes, and a facilitator you now depend on — is where the real cost lives.
- MPP vs x402: naming the same handshake twice x402 is one concrete member of the machine-payment-protocol family. The comparison worth having is not x402 against MPP, but the settlement and identity choices every member has to make.
- What it looks like when an agent pays over a settlement network The on-chain end of the family: what the wire looks like when settlement lands on a network like Tempo or any other chain, described at the level of mechanism, with the specifics left to their own docs.
- The self-provisioning agent, and its cheaper alternative Paying to mint your own key is the flagship demo for machine payments. For a publish primitive there is a shorter path: publish anonymously with no identity at all, and let a human mint the durable key once.
- Per-seat pricing breaks when the seat is a program Per-seat billing assumes a seat maps to a person with steady usage. An agent is neither one identity nor a steady load, which is why usage-based rails exist — and why this deployment prices nothing at all.
- Metering gateways, and the one this deployment runs on but doesn't use The platform under this deployment can meter and charge for requests at the edge. This deployment runs on it and deliberately turns none of that on, because it has no margin to collect.
How these posts are written
Three rules, because a blog attached to a product is usually where accuracy goes to die. Anything stated about this deployment is stated because the code does it — several posts link to the file and the line. Anything stated about someone else's product is kept at the level of mechanism, and current limits and prices are left to their documentation, because a number copied into a blog post in July is wrong by September. And where a post turned out to be wrong, the correction is edited into the post rather than buried in a later one.
Reading these as a machine
The whole site, including every post, is available as one plain-text document at /llms-full.txt, and as an index at /llms.txt. Both are generated from the same page objects that render the HTML, so they cannot drift out of sync with what a human reader sees.
How often does this get updated?
When something is learned, which in practice means alongside releases. The Atom feed is the reliable way to hear about it; there is no mailing list, because collecting addresses to announce a self-hosted deployment would be an odd thing to do.
Can I quote or reuse a post?
Yes, with a link back. The posts are prose about a working system rather than a lead magnet. If you find an error, the repository is at https://github.com/yao00oo/opentree and a corrected sentence is a welcome pull request.
Is there an RSS feed as well as Atom?
Atom only, at https://read.botook.ai/feed.xml. Every reader that speaks RSS has spoken Atom for well over a decade, and publishing two formats means maintaining two.
Where is the changelog?
/changelog — narrative for the engineering phases, then dated entries for each release. Those dated entries are the other half of this feed.