Pages, folders and publishing

Everything in a workspace is a page or a folder. Pages hold the content; folders organize it and decide who can get at it. This page covers the mechanics. For advice on what to put in a page, see Writing pages agents can use. A page can also be a table, rows and columns instead of prose, for lists of records.

Creating pages and folders

The Pages list in the sidebar is your workspace's tree. The buttons at the top of it add a page or a folder at the top level. Hover over a folder for buttons that add a page inside it, and use the ⋯ menu (or right-click) for everything else: rename, move, add a subfolder, delete. Open folder from the same menu shows what's inside it and who has access to it.

If you can only edit some folders rather than the whole workspace, you add pages inside those folders. The top level is for people who can edit the whole workspace.

There's also a sticky-note button for a private note, a page only you can see. Anyone who can read the workspace can make one, anywhere they can see. See Private notes.

The editor

Pages are Markdown. You can write in the rich editor, which looks like a document, or switch to the Markdown source with the buttons at the top right. Both edit the same text, so use whichever you like. Headings, lists, tables, links, code blocks and [[Page links]] all work in both.

There's no save button. Changes save a moment after you stop typing, and the status next to the publish button says Saving… or Saved. If a save fails (you lost your connection, say), the editor keeps your changes and sends them with your next edit.

Page properties

Under the title is a short list of properties. They're optional, but a couple of them change what agents receive.

Type. What kind of page this is, from your workspace's own list of types: persona, competitor, runbook, policy, whatever fits how your team sorts things. Pick one, or choose + New type… to add one to the list; it's then offered on every page. The sales and marketing template starts with its own types, and a blank workspace starts with none. Agents see the type next to the page's title, and it's part of what search matches on.

Kind. Either Reference, which is sent when relevant, or Rule, which is sent with every request as a hard constraint. Next to it, Always include sends the page with every request as reference material. See Rules, pinned pages and packs for when to use which. Only people who can edit the whole workspace can change these, because they affect every request.

Tags. Tags you add here apply to every section of the page. You don't usually need many: sections are tagged automatically when they mention a word from your tag vocabulary.

Good for. A few short phrasings of the work someone is doing when they need this page: "writing a cold email to a finance buyer", "answering a pricing objection". Agents' tasks are matched against these, which is how a page of email rules gets found for a task that never mentions rules (see How get_context chooses). A model suggests them shortly after the page is first published, and again when it changes. Edit them and the list is yours; the model leaves it alone until you choose Suggest again. The line underneath says whether agents get the page whole (rules, voice and style pages) or in excerpts.

Usage note. One line that's sent along with the page's content wherever it goes, like "Quote prices only from this page." It's the place for instructions about how to use the page.

Expires. A date after which the page stops being sent by get_context and stops appearing in search. Useful for promotions, temporary policies and anything with a shelf life.

Visibility. Whether the page is Shared with team or Private to me. Making a shared page private hides it from everyone else and takes it out of any packs it was in.

Access. Who has been given access to this particular page, beyond those who can see the whole workspace. See People and access.

Kind, Always include, the usage note, Good for and the expiry date apply to agents as soon as you change them. Tags and type are part of the search index, so changes to those reach agents the next time you publish. Changing any property marks a published page as having unpublished changes, so it's easy to remember to do that.

Drafts and publishing

This is the one idea in the app that's worth getting exactly right: agents only see what's published.

Every page has two versions. The draft is what you see in the editor. The published version is what agents get. They start out the same, and they stay separate until you press Publish again. The chip at the top of each page tells you where things stand:

Status	What it means
Draft (agents can't see it)	Never published. No agent can find or read it.
Unpublished changes	Published once, edited since. Agents are still getting the previous version.
Published	Agents get exactly what you see.

The sidebar shows the same thing as a small dot next to each page.

This split means you can rework a page in place without agents picking up a half-written version. It also means a change isn't live until someone publishes it, which catches people out now and then. If an agent seems to be ignoring something you wrote, check the chip first.

Seeing what will change

When a page has unpublished changes, a Changes button appears at the top. It shows a diff of the published version against your draft, so you can check what's about to go live before you publish.

The Unpublished queue

Unpublished in the sidebar lists every page with content agents can't see yet, split into "Changed since publishing" and "Never published", most recently edited first, with who last touched each one. Changed pages open straight onto their diff. You can publish each one you have publish access to from the list, or publish everything at once if you can publish across the whole workspace. A big batch (more than a couple of dozen pages) is published in the background a few pages at a time, and the list updates as they go live. Pages you can only edit wait here for whoever can.

This is the page to check after an import, or after your team's agents have been suggesting edits.

Unpublishing

Unpublish takes a page away from agents without deleting it. The page goes back to being a draft, and you can publish it again whenever you like.

What happens when you publish

Publishing splits the page into sections at its headings, tags each section from your vocabulary, and indexes it for search. It takes a second or two. After that, the next request from any agent gets the new version. There's no cache to clear and nothing to reconnect.

A published page with no changes shows Republish instead of Publish. It runs all of this again on the same content, which is how a page picks up tags you've added to the vocabulary since it was last published.

Open How agents see this page at the bottom of a published page to see the result: each section's heading path, its size in tokens, and its tags.

Moving things

Use Move to… from a page's or folder's menu in the sidebar, or the move button next to the folder name at the top of a page. Moving a folder takes everything inside it along. You can only move things you can edit, into folders you can edit.

Moving a published page doesn't unpublish it. Its sections are re-indexed under the new folder path in the background, which takes a few seconds.

Agents with edit access can move pages too, and so can the REST API. See When agents write back.

Renaming

Rename a page by editing its title, or a page or folder from the sidebar menu. When you rename a page, every [[Old title]] link in the workspace is updated to the new title, in drafts and published versions alike, without changing anyone's publish status. The one exception is when either the old or the new title belongs to another page as well, since then there's no way to tell which page a link meant.

Deleting and restoring

Delete a page or folder from its menu in the sidebar, or with Delete at the top of the page or folder. It moves to Recently deleted, along with everything inside it, except other people's private notes, which move up a level and stay theirs. It stays there for 90 days and then it's gone for good, with any file it held. Restoring puts it back where it was, published if it was published. If the folder it was in has since been deleted too, it comes back at the top level.

Agents can delete too, when they're asked to: see When agents write back. Recently deleted shows which connection deleted something.

You'll see the things you deleted. People who can see the whole workspace see everything that was deleted, and restore what an agent deleted with a workspace API key.