Let the page answer the question.

The moment this exists for

A deliverable answers the questions you thought of. The reader has one you did not. What happens next is an email, a wait, and an answer that lives in a thread instead of on the page. Or the reader gives up, decides on the basis of the section they skimmed, and you never find out what they wanted to know.

The page already has the answer, most of the time. It just has nine sections and a table, and the reader has thirty seconds. Ask this page turns the page into something you can ask, without turning it into a chat.

How it works

1. They ask. A small pill at the foot of the page, in the page's own typeface, says "Ask this page". It opens into a field. They type "what happens if we want changes after launch?" and press Enter.
2. The page answers. A caption says "Reading the page" while the model reads it. The answer arrives in a card that rises out of the field, a sentence or two, no preamble. The page is the only document the model is given, and it returns a citation for every sentence it relies on.
3. The page points. Each cited passage lights up in amber on the page and the first one scrolls into view. An "on this page" chip steps through them. The reader can check the answer against the page in one glance, which is the difference between an answer and a claim.
4. You find out. Every question lands in the page's What came back section, beside reactions and notes. The ones the page could not answer come first. Each is a sentence the next version needs.

Why it is not a chatbot

Chat widgets on documents tend to fail in the same three ways: they answer from things outside the document, they answer confidently when the document is silent, and they show you a paragraph with no way to check it. Each of those is a design decision here, made the other way.

• The page is the whole world. Nothing else is read. Not your other pages, not the web, not a knowledge base. A proposal answers as the proposal, and cannot be talked into anything the proposal does not say.
• Silence is an answer. Ask a page who the CEO is when the page never says, and the reply is "That isn't on this page." followed at most by the nearest thing it does cover. That sentence is also what makes the owner's list useful: an honest "not here" is a gap you can close.
• Every answer points. The highlight is not decoration. It is the reader's audit trail, and it makes the box a faster way to read the page rather than a way to avoid reading it.
• One question, one answer. No thread, no memory, no persona, no branding. Press Escape and the page is exactly as it was.

Private pages stay private

The box talks to the page's own address, so it sits behind whatever gate the page has: a passcode, a company email domain, a client space. A reader who has not passed the gate cannot ask the page what it says. The questions are stored for you and shown to nobody else, and the reader never needs an account.

The same page, for their agent

The person you sent the link to increasingly has an agent reading over their shoulder. Two things make that work. A browsing agent on the page finds a WebMCP tool, stacktree_ask_page, that returns the same grounded answer with its sources. And any agent that can fetch a URL can read the page itself as Markdown by sending Accept: text/markdown to the page's address, or fetching it with /_page.md on the end: headings, lists, tables and links intact, the design stripped. The HTML advertises it in a Link header and a <link rel="alternate">, and the gate applies exactly as it does to the HTML.

So the link you send a client is now three things at once: a page for the person, a Markdown document for their agent, and something both of them can ask.

Turning it on

On the page's screen in the dashboard, under What came back, switch on Let them ask the page. It is off by default. Over the API it is ask: true on the page's settings, and the same question box is available to agents as POST {page URL}/_ask, which streams the answer and its citations. Details are in the docs.