Core concepts

The shape of Elliptic

Elliptic is built from a small set of building blocks that fit together the same way for everyone. Once you can picture how they nest, every screen in the product reads as a different view onto the same few things. This page is the map. It names each concept, says what it is, and points you to the guide that covers it in depth.

The framing to keep in mind is Jira for your agents. Everything below is a surface a human can use and an agent can drive. Your AI members are not bolted on the side, they are first-class members that operate these same boards, notes, and meetings over the company-brain MCP, running on your organization's own model key.

How the model fits together

Read it as a nesting doll. Your account is your single login. An account belongs to one or more organizations, and an organization is a fully isolated workspace. Inside an organization, people are grouped into teams (teamspaces), and teams own projects. A project is a container of work items (tasks, bugs, stories, epics), and a work item can have sub-tasks beneath it. That is the spine: Account, Organization, Team, Project, Work item, Sub-task.

Layered across that spine are the surfaces that give the work context. Notes and wiki pages hold the thinking. Meetings capture conversations as transcripts and AI summaries. The activity feed threads every change into one timeline. The calendar places dated work on a grid, and the inbox routes what needs you personally. None of these replace the spine, they wrap around it, so a task can point back to the meeting it came from and the note that specified it.

Account vs organization

Account

Your account is your personal, global identity: your full name, your email, and your password. It is the one thing in Elliptic that is not scoped to an organization. The same account follows you across every org you belong to, and you switch between them from the organization switcher in the sidebar without logging out.

Organization

An organization (or org, or workspace) is a shared, fully isolated home for one company or team. It has a name you choose and a unique URL-friendly slug that Elliptic generates from that name. Every project, task, note, meeting, person, model key, and agent lives inside exactly one organization, and people you invite see only the org they were invited to.

An organization also carries a few behavior settings that change how it operates:

• AI on or off. A single switch (ai_enabled) turns every AI feature in the org on or off at once. With it off, no AI surface will run.
• Block backward transitions. When enabled (block_backward_transitions), a work item cannot move back into an earlier category band, for example out of a Done status into an In Progress one, keeping progress strictly forward-only.
• Data residency. An optional region pin (residency_region) records where the org's data should live.
• Compliance. Optional compliance frameworks, a data controller, and a DPO contact can be recorded on the org for governance.

People and roles

Everyone with access to an org is a member of it, and every member holds exactly one organization role. The roles are a strict hierarchy, each one outranking the one below:

Teams (teamspaces)

A team (teamspace) groups members inside an org and gives them a shared home: a name, an optional lead, and a charter describing what the team is for. Teams are how projects get owned. A project can be owned by a team, and a team can also be linked to many projects, granting its members a project role on each. So org roles answer "what can you do across the workspace" and teams answer "which slice of the work is yours". Projects carry their own project-level roles (admin, member, commenter, viewer) as a second axis on top of the org role.

Agents as first-class members

This is the concept that makes Elliptic different from a normal tracker. An agent (an AI user) is not a chatbot pinned to the corner of the screen, it is a real member of your organization with its own identity. An agent has a name, a provider, a specific model, and a system prompt that fixes its behavior, and it shows up wherever members show up.

Four properties make an agent a true member rather than a feature:

• It has an identity. An agent is a named entity in your org, so it can be referenced and held accountable like a person. Work items even carry a dedicated bot-assignee field, so a task can be assigned to an agent directly.
• It runs on the org's key. Every call an agent makes runs on your organization's own model key (BYOK). The cost lands on your provider bill, and the data never enters a shared pool.
• It carries a budget. Each agent can be given a monthly spend cap, set in cents per month (budget_monthly_cents), so an automated member can never run away with your bill.
• It acts through MCP with a member's permissions. An agent reaches the workspace through the built-in company-brain MCP server, authenticated by a token scoped to an org and a set of permissions. It can only ever do what that grant allows, and only inside the org it is connected to.

Work hierarchy

Work lives in projects and is tracked as work items, with planning layers above and around them. This is where the day-to-day actually happens.

Project

A project is a container for related work inside an org: a product area, a workstream, an initiative made concrete. Each project has a short key (up to six characters, like WEB or API) that prefixes every work item in it, an optional lead, an optional target date, a set of feature toggles, and a configurable estimate scale. A project can be private or public, and its key is unique within the org.

Work item

A work item (task) is the unit of work. Every item gets a stable id of the form KEY-number (for example WEB-142), numbered per project, so a meeting summary or a chat message can point straight back at it. A work item has a kind, one of task, bug, story, or epic, plus a title, description, priority, and an assignee. The assignee can be a person or, through the bot-assignee field, an agent.

Statuses and immutable categories

A work item moves through statuses like Backlog, Todo, In Progress, In Review, Done, and Cancelled. Statuses are renameable and recolorable, but each one is permanently bound to one of five immutable categories: backlog, unstarted, started, completed, or cancelled. The categories are fixed in code and never editable. That is deliberate, they are the stable spine that progress math, ordering, and AI summaries read no matter how a team renames its statuses.

Sub-tasks

Any work item can have sub-tasks, child items nested under a parent. This is how an epic breaks into stories, or a story into the tasks that deliver it. The nesting respects each type's level, so you cannot file a higher-level item under a lower-level one, though same-level nesting (a task under a task) stays allowed.

The planning layers

Around and above the board sit the layers that organize work over time and across projects. A work item can be attached to any of them:

Cycles, milestones, and modules organize work inside one project. Initiatives and releases operate at the org level, spanning projects. The full mechanics live in Projects & Tasks.

Customizing work

The defaults work out of the box, but every team shapes its work differently. Four building blocks let you adapt the system without leaving it:

• Labels. Org-scoped tags with a display color that you attach to work items to slice and filter them. A label name is unique within the org.
• Custom properties. Project-scoped custom fields on work items, typed as text, number, date, select, checkbox, or URL, for the attributes your team tracks that the built-in fields do not cover.
• Saved views. A named, reusable slice of the board, its filters, grouping, ordering, and display, saved once and reused. A view can be personal to you or shared with the whole org.
• Workflow statuses and transitions. Rename, recolor, reorder, and add statuses within their fixed categories, and define which transitions between them are allowed, so the board matches how your team actually works while the categories underneath stay stable.

Knowledge surfaces

Tasks are only part of the picture. The surfaces below hold the context around the work, and because everything is connected, that context stays attached to the items it belongs to.

Notes, the activity feed, the calendar, and the inbox are covered in Notes, Activity & Calendar, and meetings have their own guide in Meetings.

The AI brain

The AI layer reads across every surface above, projects, tasks, transcripts, notes, and activity, so one question can be answered from all of it at once. Three pieces make it work, and they share a single rule: everything runs on your organization's own key.

BYOK keys

BYOK (bring your own key) is the foundation. An admin or owner stores an OpenAI or Anthropic key once at the org level. It is encrypted at rest and only ever shown masked, just the last four characters. Every AI feature in the org, summaries, answers, agents, runs on that key, so the cost lands on your provider bill and your data stays under your control. You can mark one key as the default per provider and rotate keys by adding a new one and deleting the old.

The company brain

The company brain is a set of cross-project tools that answer the questions you actually have when you sit down. Catch me up returns everything that changed in the org since a moment you choose. Resume points at a project and reconstructs where you left off, the in-flight tasks, recent notes, and recent activity. Open threads pulls together your assigned tasks, the tasks you created, and your triage queue, with the closed ones filtered out, into one honest snapshot of your plate.

The company-brain MCP server

The built-in MCP server is what exposes all of this to agents and external AI clients. It is a single endpoint that presents the workspace, tasks, projects, notes, meetings, activity, the brain, and more, as tools an AI can call. A connected client authenticates with a scoped token, and every call runs with a member's permissions inside one org. This is the doorway your first-class agents come through, and the technical details are in Company-Brain MCP.

Glossary

Every concept on this page, and the guide that documents it in full: