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, real-time co-editing, 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
- Open Notes or the WikiGo 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.
- Click New noteA 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.
- Start writingOn 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.
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, 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:
| Block | What it inserts |
|---|---|
| Text | A plain paragraph |
| Heading 1, 2, 3 | Section, subsection, and minor headings |
| Bullet list | An unordered list |
| Numbered list | An ordered list |
| Task list | A checklist of toggleable items |
| Quote | A block quote for a callout |
| Code block | A monospaced, fenced code block |
| Divider | A horizontal rule |
| Create task | Turns the current line's text into a task draft |
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.
Real-time co-editing
Pages support simultaneous editing. When more than one person has the same page open, edits merge in real time, you see each collaborator's live cursor and selection, and presence shows who else is in the document. There is no "someone else is editing" lock to fight over and no manual merge step.
The session runs over a websocket at /ws/notes/{id}. Because the browser will not send its login cookie on a cross-origin websocket, the app first fetches a short-lived token from /realtime/token (valid for 30 minutes) and uses it to open the connection. Access is checked when the socket opens, so only members who can view the page can join its session.
History, visibility and locking
Version history and restore
Every time a page's title or body changes, Elliptic snapshots the previous state as a version, attributed to whoever made the edit. You can browse those versions newest-first and restore any one of them. A restore is itself non-destructive: the current state is snapshotted first, then the chosen version is applied, so restoring is always reversible and nothing is ever lost.
Visibility and sharing
Each page has one of three visibility tiers:
| Visibility | Who can see it |
|---|---|
| Public | Every member of the organization |
| Private | Only the creator, org admins, and members granted an explicit share |
| Shared | The creator, org admins, and members granted an explicit share |
On a private or shared page you grant access per member, at one of three levels: view, comment, or edit. View and comment grants let someone read, while edit is what lets a non-owner change the body. Changing a page's visibility, granting or revoking a share, locking, and archiving are all limited to the page's creator or an org admin.
Locking
Locking a page freezes its content. While a page is locked, edits to the body are refused even for members who would otherwise have edit access, which is useful for a finalized policy or a runbook you do not want drifting. Unlock it to resume editing. Locking is a creator or admin action.
Archiving and deleting
Archiving a page tucks it out of the active list without deleting it. Archived pages are hidden by default and reappear when you flip the archived toggle, and you can unarchive at any time to bring a page back. Deleting a page, by contrast, removes it for good, and the deletion is recorded in the activity feed.
Reuse
Templates
Page templates capture a starter title and body so you do not rebuild the same structure every time. There are two ways to make one: define a template directly, or save an existing page as a template. Either way, creating a new page from the template prefills the editor with its title and content, ready to fill in. Templates are scoped to the organization, and can optionally be scoped to a project. Each template name is unique within the org.
Duplication
Any page can be duplicated in one click. The copy keeps the original's project, parent, icon, and full content, and is titled "… (copy)" so the two are easy to tell apart. It is the quickest way to fork a working doc when a template would be overkill.
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.
The page work-items sidecar
A page exposes a work-items list: the tasks that record this page as their source plus any tasks explicitly linked to it. This is the sidecar that turns a planning page into something live, you see at a glance what is still open against the doc, and the tasks stay current as their status changes on the board. The sidecar's Create from selection button makes a task from the highlighted text and records this page as its source, so it appears in the list right away. That button needs the page to be in a project, since the task has to land somewhere.
AI on the page
The page assistant
Open the page assistant to work with the document using your org's model key. It grounds on the live content of the page, so its answers reflect what is actually written. It offers one-click presets plus free-form questions:
- Summarize condenses the page into a few bullet points.
- Action items extracts the to-dos from the page as a checklist.
- Improve writing rewrites the page to be clearer and more concise.
- Free-form lets you ask anything about the page, or ask it to draft new content, in your own words.
Any answer can be inserted straight into the page, or dismissed. Press Cmd or Ctrl + Enter to send your question without reaching for the button.
Inline text transforms
Select text in the editor and an AI action appears in the toolbar. Pick a transform and the selection is rewritten in place: Rephrase, Fix grammar, Summarize, or Expand. There is also a Generate control that writes new content from a short prompt (with presets like TL;DR, Action items, and FAQ) and inserts it into the page. Inline transforms run through the AI transform endpoint and, like everything else, on your own key.
Comments
Comments are threaded discussions attached to a task, a meeting, or a page. A thread can nest one level deep: a comment, and replies under it. Every comment is Markdown, so it can carry mentions and references just like a page body.
Internal vs. external visibility
Each comment is either internal or external. Internal is the default and is for the team. External comments are the ones guests are allowed to read. A guest member only ever sees external comments, which keeps an internal back-and-forth private even on an item a guest can otherwise open.
Anchors, edits, and resolution
- Text anchors let a comment point at a specific span of the item it is attached to, so feedback lands on the exact place it is about.
- Edit history is kept: editing a comment snapshots the prior content and marks it as edited, and you can list a comment's prior versions.
- Resolve and reopen mark a thread done or bring it back. Both are author or admin actions.
- Emoji reactions can be toggled on any comment, aggregated per emoji with a count and whether you reacted.
- Attachments can be added to a comment, so a screenshot or file rides along with the message.
Commenting notifies the right people. The owner of the commented item gets a "new comment" notification (a task's assignee, a meeting's or page's creator), and anyone you @-mention in the comment is notified too, and on a task is auto-subscribed.
Personal surfaces
Stickies
Stickies are your private scratchpad, a wall of quick notes only you can see. Each sticky is a small color-coded card (yellow, green, blue, pink, purple, or orange) that autosaves as you type. When a fleeting thought turns into real work you can convert a sticky into a task or a page in one step, optionally into a specific project, and optionally clearing the sticky afterward.
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_notesandget_noteto read pages, with optional project and text-search filters.create_noteto write a new Markdown page (org- or project-scoped), with an idempotency key so a retried call does not create a duplicate.update_noteto revise a page's title, body, or project. Each edit snapshots a version, exactly as it would from the editor.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.
