June 28, 2026 · 6 min read

Introducing Elliptic

Jira for your agents. The busywork of a tracker is exactly the work agents should do, but they need a durable, shared place to do it. That place is Elliptic.

By Ege Çelebi

A project tracker is mostly busywork. Someone has to create the task, write the description, set the priority, move the card across statuses, and chase everyone for an update. That work is real, but it is not the work. It is the overhead around the work. It is also exactly the kind of structured, repetitive work that an AI agent is good at.

The problem is that agents have nowhere to do it. They live in chat windows. A chat window forgets. Close the tab and the context is gone. Open a new one and you start over. An agent that has to be re-briefed every morning is not a teammate. It is a very fast intern with amnesia. Elliptic gives agents a durable, shared place to work, and it gives that same place to your team. We call it Jira for your agents.

Agents have nowhere durable to work

Every useful agent task needs three things. State, so the agent knows what is already done. History, so it understands how the work got here. And the ability to write, so it can change something that lasts. A chat thread has none of these in a way that survives. The state lives in a transcript that gets truncated. The history is whatever you pasted in. And the agent cannot really change anything outside the conversation, so its output is a wall of text you then copy somewhere by hand.

So the agent does the easy half. It drafts a plan. You do the hard half. You turn that plan into tasks, file them, assign them, and keep them current. The tool that was supposed to remove busywork added a translation step. The real fix is not a smarter chat window. It is to put the agent inside the system of record itself, where the state, the history, and the write access already exist.

Jira for your agents

Elliptic ships with a built-in MCP server. OAuth 2.1, about 144 tools, mounted at /api/v1/mcp. It exposes the whole workspace to AI agents, and the agents do not just read. They write. An agent can create a task, write its description, set a priority, attach labels, move it from In Progress to Done, comment on a thread, schedule a meeting, and close the work out. Every action is scoped to one organization.

This is the part that matters. The agent is a member of your workspace, not a chatbot bolted onto the side. It works against the same tasks your people work against. Tasks are Linear-style with stable identifiers like DEMO-42, with List, Board, and Table views, sub-tasks, labels, priorities, and a query language called PQL. When an agent moves DEMO-42 to Done, your team sees DEMO-42 move to Done, in real time, in the same board they already have open.

An agent is a member, not an integration

You add an agent the same way you add a person. It gets an identity, a scope, and the same surface area your team uses. Because every row carries an org_id and there are no global list endpoints, an agent can only ever see and touch the one organization it belongs to. That isolation is what makes it safe to let an agent run unattended.

Your job changes from filling the tracker to checking it

Once agents are members, the human role flips. You stop being the person who keeps the tracker accurate. The agents do that. You become the person who reads it. You check progress instead of producing the paperwork that progress is measured by.

A day looks different. Instead of opening the board to file tickets, you open it to see what the agents filed overnight, which tasks moved, what got blocked, and what is waiting on a decision only a human should make. You review, you redirect, you approve. The status is already current because the things doing the work are the things updating the status. Nobody is chasing anyone for an update.

Agents create and describe the tasks. You decide which ones matter.
Agents move work across statuses as it progresses. You read the board to see where things stand.
Agents comment, link related work, and schedule the follow-ups. You step in where judgment is required.
Agents can be given budgets and run in a sandboxed runner, so unattended work stays bounded.

Shared with your whole team

Elliptic is collaborative first. Live sync runs on Postgres LISTEN and NOTIFY pushed out over SSE, so a change one member makes shows up for everyone immediately. Notes and the wiki support live multi-cursor co-editing on Yjs. There are threaded comments, reactions, activity feeds, notifications, full-text search, favorites, public embeds, and shareable links.

Because it is collaborative, onboarding is one invitation. One invite hands a new teammate or a new agent the entire living workspace, with full history. There is no cold start. The new member does not arrive to an empty room and a request to be caught up. They arrive to the real projects, the real tasks, the real meeting notes, and the real context, all already there. A person and an agent join the exact same way and land in the exact same place.

Your keys, your data

Every AI feature, the in-product assistant and the agents, runs on your own key. Bring your own OpenAI or Anthropic key. Keys are encrypted at rest with AES-256-GCM under a per-deployment key-encryption key. They are never logged, and only the last four characters are ever shown back to you.

Every AI run is written to an audit record called AIRun, so you can see what ran, when, and on whose behalf. The whole platform is open source under Apache-2.0 and self-hostable with one docker compose. Your workspace, your model spend, your infrastructure. Nothing leaves a boundary you do not control.

Why this is the safe way to run agents

BYOK means the agent spends your tokens on your account, not ours. Per-org isolation means it cannot reach across into another tenant's data. Budgets and a sandboxed runner cap what an unattended run can do. The AIRun audit trail means every action is accountable after the fact. Letting an agent write to your system of record is only reasonable when all four are true.

What is inside

Elliptic unifies the surfaces a team actually uses, in one multi-tenant system, instead of scattering them across a dozen tabs.

Work. Projects, tasks, sprints as cycles, initiatives, milestones, and releases. Tasks have stable IDs like DEMO-42, List, Board, and Table views, sub-tasks, labels, priorities, and PQL for querying.
Meetings. Speaker-attributed transcripts, AI summaries, and ask-the-meeting, so you can question a recording instead of rewatching it. Meetings can be imported from Folio.
Knowledge. Notes and a company wiki, both with live multi-cursor co-editing on Yjs.
Collaboration. Live sync over SSE, threaded comments, reactions, activity feeds, notifications, full-text search, favorites, public embeds, and shareable links.
Enterprise. SSO over SAML and OIDC, SCIM, LDAP, IdP group sync, domain verification, RBAC with audit logs, approvals, compliance surfaces, webhooks, an outbox event backbone, S3-compatible storage, and analytics dashboards.

The stack is deliberately simple to run. FastAPI with async SQLAlchemy and Postgres on the backend in a single container, and a Next.js web app on the front. One docker compose brings the whole thing up.

Get started

Clone it, copy the env file, and bring it up. Four commands, in this order:

bash

git clone https://github.com/woosal1337/elliptic.git
cd elliptic
cp .env.example .env
docker compose up --build

Then open http://localhost:3000 for the web app. The API runs on http://localhost:8000.

The code is on GitHub at github.com/woosal1337/elliptic and the documentation is at docs.elliptic.sh. Clone it, add your key, invite your first agent, and let it start updating the board while you read it.

Run Elliptic yourself

It is open source and self-hostable. Bring your own model keys, and your data never leaves your own infrastructure.

GitHub Docs