Open app →
Documentation

Notes, wiki & pages

Write rich Markdown pages in a block editor, organize them into a wiki, co-edit them live, comment and version them, and let your agents read and write the same pages over the MCP.

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.

One model key behind every AI feature
Every AI feature on a page, the page assistant, inline text transforms, and the Generate control, runs on your organization's own model key. You bring an OpenAI or Anthropic key once at the org level and all AI work runs on it. This is what BYOK (bring your own key) means throughout the product.

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. 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. 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. 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.
Create a page inside a project
When you start a page from a project, it is automatically linked to that project, so you do not have to set the project field yourself. The page then appears in the project's pages as well as on the main Notes list. A page can also carry a team.

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.

Wiki vs. project pages
A page belongs to the wiki when it has no project. Give a page a project and it moves into that project's space instead. Nothing else changes about the page, the editor, sharing, history, and comments all work the same either way.

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:

BlockWhat it inserts
TextA plain paragraph
Heading 1, 2, 3Section, subsection, and minor headings
Bullet listAn unordered list
Numbered listAn ordered list
Task listA checklist of toggleable items
QuoteA block quote for a callout
Code blockA monospaced, fenced code block
DividerA horizontal rule
Create taskTurns 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.

Linking those tasks back to the page
Tasks made this way are filed in the project you choose, but they are not automatically tied back to the page. To get a task that shows up in the page's work-items list, use Create from selection in the work-items sidecar (covered below), which records the originating page.

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.

markdown
[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.

Autosave to durable Markdown
The live session keeps everyone in sync, and the page's content is persisted back to durable Markdown automatically. There is no Save button. The same Markdown is what history, export, comments, and the MCP all read, so the collaborative copy and the stored copy stay in step.

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:

VisibilityWho can see it
PublicEvery member of the organization
PrivateOnly the creator, org admins, and members granted an explicit share
SharedThe 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.

"Public" means visible to the org
"Public" here means visible to the whole organization, not to the open internet. Publishing a page to a public web link for people outside the org is a separate capability with its own published-page URL and visitor comments.

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_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. 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.

Same surface, two kinds of member
Because people and agents read and write the same Markdown pages through the same access rules and the same activity log, a page an agent drafts is a page you can pick up and finish, and a page you write is one an agent can summarize, extract tasks from, or keep up to date. That shared surface is the point: Elliptic is Jira for your agents and your team at once.