Notes, wiki & pages

What this page covers

Pages in Elliptic are rich Markdown documents that live next to your tasks, meetings, and activity. They are where decisions, specs, runbooks, and handbooks get written down so the rest of the company, people and agents alike, can find them later. This page walks through creating and organizing pages, the wiki view over them, the block editor, mentions and references, version history and access control, templates and reuse, the link between pages and tasks, the on-page AI assistant, comments, your personal surfaces, and how agents work the same pages through the company-brain MCP.

Notes and pages

A page (the data model calls it a note) has a title, a Markdown body, and a few optional fields: an emoji icon, a project, a team, and a parent page. Nothing but the title is required. Pages are owned by the organization, so any member with access can find them, and every edit is written to the activity feed.

Create a page

1. 1
   Open Notes or the Wiki

   Go to Notes from the sidebar to see the org's pages, or open the Wiki for the org-wide knowledge base. Pages are listed newest-edited first, each with a one-line excerpt pulled from the first real line of the body.
2. 2
   Click New note

   A small dialog asks for a title (for example, "Deploy runbook"). If your org has page templates, the dialog also offers a Start from picker, defaulting to a blank page. The Create button stays disabled until you type a title.
3. 3
   Start writing

   On create, you land straight in the editor on the new page, with the title prefilled. There is nothing else to fill in first.

Emoji icons

Each page can carry a single emoji icon. It shows in the list in place of the default document glyph, which makes a long wiki much faster to scan. Setting an icon is optional and you can change or clear it at any time.

Nest pages into a tree

Any page can have a parent, which turns a flat list into a tree. Set a parent and the child renders indented beneath it in the list, and the parent shows a count of its sub-pages. This is how you build a handbook with sections and sub-sections, or a project space with an index page and detail pages underneath it. A page cannot be its own parent, and the parent must be another page in the same organization.

Folders

A folder is a page that holds pages instead of prose. Use New folder on the Notes list or in the Wiki, name it, and file pages into it. A folder opens as a list of what sits inside it rather than as an editor, so a handbook reads as a shelf and not as one long document.

The list carries a rail of every folder down the left, a breadcrumb path across the top, and the folders and pages of the open folder below it. Folders sort by name. Pages sort by the most recent edit. Each row carries a Move to menu that files it into another folder, and a folder cannot move inside itself or inside anything filed beneath it.

On the phone a folder opens as its own screen, so the platform's own back gesture walks you out of it.

List and filter

The list sorts by most recently edited, so the pages you are actively working on float to the top. You can narrow it down a few ways:

• Text filter matches against both the title and the body, so you can find a decision buried deep in a long page.
• By project shows only that project's pages when you are viewing inside a project.
• By team scopes the list to a team's pages.
• Archived toggle decides whether archived pages appear. By default they are hidden and only active pages show.

The wiki

The Wiki is the org-wide view over your pages. It shows the pages that are not tied to any single project, the ones meant to be shared across the whole company: handbooks, runbooks, policies, onboarding guides, glossaries. It reads from the same pages as Notes, just filtered to the ones with no project and presented as a knowledge base.

Because the wiki renders the parent-child tree, the natural way to build it is a small set of top-level pages (for example, Engineering, People, Security) with detail pages nested beneath each. New pages you create without a project show up here automatically.

The editor

The page editor is a real block editor, not a plain text box. It supports headings, bold and italic, ordered and unordered lists, task lists, block quotes, inline code, code blocks, tables, horizontal dividers, and links. Everything you write is saved as clean Markdown, which is what makes the same content readable to people, to exports, and to agents over the MCP.

The slash menu

Type / on a line to open the block menu. Search by name ("head", "todo", "code") and pick a block. Arrow keys move the selection, Enter inserts, Escape closes. The full set is:

The Create task item only appears in the slash menu on a page where task creation is wired up, which is a page opened inside the org (it needs to know where to file the task).

Markdown shortcuts

You do not have to reach for the slash menu. Type Markdown and the editor converts it as you go: ## for a heading, - for a bullet, 1. for a numbered item, > for a quote, and so on. Pasting Markdown or a URL works too, and URLs auto-link.

Turn writing into tasks

Pages are often where work gets discovered, so the editor lets you spin tasks out of what you have written. Type / and pick Create task, and the current line's text becomes the title of a new task draft. To capture several at once, highlight a block of lines: a Create task / Create N tasks button appears at the top of the editor, and each non-empty line becomes its own task draft, with list markers and checkbox brackets stripped first.

If the page is already in a project, the tasks land there. If it is not, a small picker asks which project they should go to. The drafted lines stay on the page, they are copied into tasks rather than moved out of the body.

Mentions and references

Type @ anywhere in a page to open the mention picker. As you type it lists people, tasks, and pages that match, and selecting one inserts a styled chip. Each chip kind looks and behaves a little differently:

• People insert as an @ chip. This is a mention, not a clickable navigation target.
• Tasks insert as a monospace # chip that opens the task when clicked.
• Pages insert as a chip with a document icon that opens the referenced page when clicked.

Under the hood every chip is stored as a plain Markdown link whose href is a sentinel path carrying the kind and id, so references survive save and reload and render identically for everyone. The exact wire format, and how an agent writes one, is documented on the References & Mentions page.

[Visible label](/__mention/<kind>/<id>)

Drag to cite

You can also build a page by dragging. Grab a row out of the activity feed, a meeting, a page, a task, or a decision, and drop it into the editor. It lands at the drop point as a citation back to the original, carrying the item's kind, id, and title rather than just plain text. Pages and meetings drop in as clickable links, tasks and decisions drop in as a labelled citation. It is the fastest way to assemble a recap or a decision log out of things that already happened.

Notify and auto-subscribe

Mentioning a member notifies them. When you name someone in a page, they get a "you were mentioned" notification (you are never notified about mentioning yourself, and only org members are notified). When you mention someone in a comment on a task, they are additionally auto-subscribed to that task, so they keep getting updates without having to follow it manually.

Deleting

Deleting a page removes it for good, and the deletion is recorded in the activity feed. Every org member can see every page: the workspace is the boundary, so pages carry no per-page visibility tiers.

Notes and work

Pages and tasks are linked both ways. A task can record the page it was filed from, and a task can be linked to a page after the fact. Either way the relationship is tracked, so a page can show every task that originated from it or was linked to it.

Personal surfaces

Favorites

Favorites let you pin any entity, a page, a task, a project, a meeting, for quick access, and reorder your pins. It is your personal shortcut rail across everything in the org, separate from what anyone else has pinned.

Agent-native: pages over the MCP

Everything above is available to your agents too. Over the company-brain MCP, an agent operates pages the same way a member does, on the org's own key, scoped to the org, and subject to the same access checks. The note tools cover the full lifecycle:

• list_notes and get_note to read pages, with optional project and text-search filters.
• create_note to write a new Markdown page (org- or project-scoped), with an idempotency key so a retried call does not create a duplicate.
• update_note to revise a page's title, body, or project.
• delete_note, which previews by default and only deletes when called with confirm set to true.

Agents link work to pages as well. create_task and update_task accept a source_note_id, so a task an agent files from a page records that page as its source and shows up in the page's work items. And because a page reference is just a Markdown link, an agent can embed @-references inline in any body or comment it writes.

To follow what is happening, get_entity_activity returns a single page's timeline (newest first) and list_activity returns the org-wide stream, so an agent can see who edited a page, when it was commented on, and what tasks came out of it, the same history you read in the feed.