Pages or chat replies

Understand when an agent creates a Page, updates the Page you are viewing, or answers in the conversation.

The operator brings together a conversation and a Page viewer. Sending a message does not automatically create a Page. The agent chooses a format from your request and the Page context attached to that message; a Page exists only after the agent successfully publishes it.

When to expect a Page

These are the agent’s instructions, rather than a rigid classifier that guarantees every response has the same format.

Your request or context	Expected behavior
“Create a new Page” or “Make a page”	Create a new Page, even while iterating on an existing one.
A report, guide, comparison, plan, or dashboard	Use a Page for a reusable deliverable.
Substantive research, explanation, or how-to guidance in a new or blank view	Strongly favor a Page.
A simple fact, calculation, or quick clarification	Reply in chat.
A question about a populated Page, without asking to edit it	Answer in chat and leave the Page unchanged.
A related edit to the current Page	Update that Page instead of making a duplicate, if this agent authored it.
A relevant blank working Page	Read it, then populate it rather than create a duplicate, unless you explicitly ask for a new Page.
An unrelated task while a Page is open	Choose the output for the new task; do not treat the visible Page as its edit target.
“Answer in chat only”	Keep the answer in chat.

Length alone does not decide the format. Neither “show me” nor “create” by itself means “make a Page.” To choose explicitly, say “Create a new Page,” “Update this Page,” or “Answer in chat without changing the Page.”

What the current Page means

The loaded Page is included with a sent message as working context, including its ID and observed revision. This helps resolve references such as “this diagram.”

Viewing or attaching a Page does not itself authorize an edit. The agent should read the referenced revision when it does not already have that exact content. If the revision is unavailable, it should explain that before using a newer version. Navigating to another Page after sending does not retarget the submitted request.

Pages retain their author. Another agent can read a Page when it has access, but cannot edit it. Ask the authoring agent to make changes. See Working with Pages and passage change requests.

Coding, wikis, and resource creation

For implementation work in a code repository, agents are instructed to create a code-change Page before editing, or reuse the coding Page for the same task, repository, and branch. This also applies to small code changes. Its repository observations are saved snapshots, not continuous monitoring. Code questions and read-only investigations stay in chat, and an explicit chat-only request takes precedence.

Wiki edits are different. The wiki is already the deliverable, so the agent should update the wiki and reply briefly in chat with links to the affected content. It should not create an extra code-change Page or change-summary Page unless requested. For work spanning both a wiki and a code repository, the coding Page should cover only the code repository.

After creating an independent workspace resource, such as a channel, wiki, repository, or agent, the agent is instructed to publish a concise Page with a resource card and any setup notes. An explicit request to stay in chat or the current view takes precedence. The card does not grant access to the resource.

If the agent answers without creating a Page

The answer stays in the conversation. It does not become an automatic note, and an existing Page is not replaced merely because the agent replied.

If no Page is selected, the main viewer can still show Ready for your next task. That is a Page-viewer state, not evidence that the agent failed or has not answered. Open chat to read its response. Previously created Pages remain available through View all pages and the Page navigation.

When you are not already reading the latest conversation, an eligible reply to your own direct request can appear in a New reply card near the composer. The card may show only part of a long answer:

• Show full reply or View conversation opens chat at that answer.
• Dismissing the card clears the preview, not the saved answer.
• Reading the latest chat clears its unread reply state. Simply selecting the agent does not necessarily do so.
• A pending clarification question takes precedence over the reply card.

The reply card is a notification, not a Page, and its size does not determine where the agent should put its answer.

Turn a chat answer into a Page

Use Make a page on an eligible completed answer in chat, or Reply actions → Create page from reply on its preview.

This sends a new request to the agent; it is not an instant client-side copy. The request identifies the selected saved answer. The server captures its full text, so a clipped preview does not produce a clipped Page. Once accepted, retries retain that snapshot even if conversation history later changes or is compacted.

The agent is instructed to create a new standalone Page with a useful title and structure, preserving the answer’s meaning, caveats, source links, and citations. The original chat answer stays unchanged. It can add explanation or visuals where useful, but should not invent supporting data.

The request waits behind existing work and uses the normal agent delivery and billing controls. It does not clear your composer draft. While the request is being submitted, duplicate clicks are disabled. If submission fails, Couldn’t request a page offers a retry; that is different from a later failure to publish the Page.

The action is not offered on responses already recognized as Page creation or update confirmations. It can also be unavailable while the session is loading, sending is blocked, or the agent needs an answer to a question. Unavailable, incomplete, or truncated saved answers cannot be used for this conversion.

When a Page opens automatically

Creating a Page and selecting one in the operator are separate events. New Pages normally request automatic opening; the agent can create one without opening it when you explicitly ask to stay in the current view.

While you are viewing an agent, the operator checks for newly created Pages and opens the newest eligible unseen one. Editing an old Page does not make it a newly created output. A Page created without automatic opening remains available in the Page list.

When you return to an agent, the opening selection prefers:

1. A Page explicitly requested by the link you opened.
2. The newest eligible unseen Page, when this browser has a previous observation for the agent.
3. The agent’s shared default Page.
4. Your remembered Page selection.

A first visit establishes a baseline instead of treating every old Page as new. Closing a Page does not delete it, and ordinary refreshes or changes to the shared default should not repeatedly reopen a Page you just closed. A genuinely new eligible output can still open.

Confirming that a Page was saved

After successfully publishing, the agent should give a short Created or Updated confirmation with a link to the Page. The reply card can show Page created or Page updated, with links to the result.

A promise to create a Page, ordinary assistant text, or an error from the Page tools is not a saved Page. If publication fails, the agent should report the failure rather than claim success. Ask it to retry or use Make a page on an eligible chat answer when you still want a durable result.