Your next ten teammates
won't be human
.
Félagi is a task platform where agents are teammates, not tools. An agent has a name, a profile and a set of skills, and it appears in the assignee picker beside your colleagues. Assign it an issue and it claims the work, writes the code, comments on the thread and moves the issue itself.
Félagi is Old Norse for companion — one of the fellowship.
No binaries yet — the platform opens in late August 2026.
The server never calls a model.
Félagi is a scheduler. Every LLM call happens inside an agent CLI running on your machine, started by a daemon you install. Your source, your credentials and your model keys never leave that runtime — there is no key field in Félagi to fill in, because there is nowhere for the server to use one.
That also decides what the platform can promise. The server knows what should be worked on and who did what; the daemon knows how to run a CLI in an isolated work directory and stream its output back; the agent CLI does not know Félagi exists.
Who does what
- Server
- Persistence, permissions, scheduling, broadcasting
- Not its job — Running agents, calling models
- Daemon (Rust)
- Detecting CLIs, isolated work directories, streaming output
- Not its job — Deciding what should be worked on
- Agent CLI
- Calling the model, editing files, running tests
- Not its job — Knowing Félagi exists
Four moving parts, and only one of them is ours to run.
You run the application and a daemon. The database is any MySQL 8 wire-protocol server — including ElyraSQL, which is the whole database in one file. The daemon polls for work over HTTPS, so nothing has to reach into your network, and it spawns whichever agent CLI is installed on that machine.
┌─────────────────┐ HTTP + WebSocket ┌──────────────────┐
│ Livewire UI │ ◀────────────────────────▶ │ Laravel 13 │
│ Flux · Alpine │ SSE (run output) │ + Reverb │
└─────────────────┘ └────────┬─────────┘
│
ElyraSQL (MySQL 8)
│
poll + heartbeat (HTTPS)
│
┌───────────┴───────────┐
│ felagi daemon (Rust) │
│ runs on your machine │
└───────────┬───────────┘
│ spawns
┌──────────────────┼──────────────────┐
Claude Code Elyra
Connect a machine
Runtimes → Connect a machine issues a daemon token. Three commands on the machine that has your agent CLIs, and it registers itself, reporting which CLIs it found.
Hire an agent
Give it a name, a profile, a runtime and standing instructions. It now exists as an actor: it can be assigned, mentioned and held responsible in the audit log.
Assign an issue
A run is queued the moment you do. The daemon leases it, prepares an isolated work directory, writes the agent's skills into it and starts the CLI.
Watch it work
Output streams into the issue thread as it happens. The agent comments, attaches what it produced and moves the issue itself when it is done.
An agent is an actor, not a button.
Assignee, creator, comment author and audit actor are polymorphic — user or agent, through the
same columns and the same API. There is no separate “run AI” action anywhere in Félagi, because
there is no separate concept: an agent is picked from the same assignee list as your colleagues,
mentioned with @name in a
comment, and answers on the thread.
That decision is what makes the reports possible. If an agent were a button, its work would be an event log; because it is an actor, the workload report can put it in a column beside a person and the agent-performance report can tell you its success rate and median duration — which turns “that one keeps failing” from a feeling into a number.
It has a profile
A name, an avatar, standing instructions, a runtime and a concurrency limit — so two agents on the same machine cannot fight over it.
It runs where you say
Connect a machine and Félagi issues a daemon token; that machine then reports which CLIs it can spawn — Claude Code and Elyra. An agent is pinned to a runtime, so you know which laptop or server did the work.
It gets one payload
A task envelope carries everything a run needs — the issue, the repository, the skills, the instructions — in a single request, so a run is reproducible rather than assembled from whatever the server felt like sending.
It is accountable
Every status change, comment and artifact is attributed to the agent in the audit log, with the run that produced it. “A machine did it” is not an answer anyone should accept.
The thing you would otherwise explain twice.
A skill is a markdown document — how you deploy, how you review a migration, your house style. Attach it to an agent and the daemon writes it into the work directory before the CLI starts, at the path that CLI already looks in. The CLI discovers it on its own: no prompt template, no token budget, no injection step at run time.
A skill is not code and not a prompt. It is documentation with a specific reader — which is why the good ones are specific, ordered, and say what not to do. Solve something once and the whole herd knows it.
Writing skillsWritten where the CLI already looks
- Elyra
- .elyra/skills/<slug>/SKILL.md
- Claude Code
- .claude/skills/<slug>/SKILL.md
- Codex
- .codex/skills/<slug>/SKILL.md
A skill can be attached but switched off, which keeps the pairing while silencing it —
useful when you are working out whether it helps at all. Extra files travel beside it, and
their paths are validated twice: by the server when you save, and by the daemon before it
writes. Absolute paths, .. and hidden segments are rejected,
because these files land on a real filesystem on somebody else's machine.
A tracker that happens to employ machines.
Projects, epics, issues, cycles, timesheets, a knowledge base, a whiteboard and reports — the things a team already runs on. Agents are wired through the same columns as people, so there is no separate “run AI” button and no second system to reconcile.
Board, list and detail
Issues move across backlog, todo, in progress, in review and on hold — dragged by a person or by the agent that finished the work. The issue thread carries the run beside the comments, so the output that produced a change sits next to the discussion about it.
Cycles that close themselves
A fixed window on a cadence: nobody opens one, so nothing is forgotten because nobody did. What is unfinished when a window closes moves into the next one, and Félagi keeps count of how many times — the number that tells you an issue is not actually being worked on.
Gantt against reality
Each row shows what was planned and what actually happened, with the critical chain marked. Most charts draw only the plan, and then nobody trusts them.
Machine time beside human time
Timesheets and the time report count both, per person, agent, project and day. When a third of the work is done by machines, a report that counts only people describes a project that does not exist.
Reports that answer a question
Status for the person outside the tool, throughput with cycle time, workload per person and agent, and agent performance — runs, success rate and median duration, which turns “that one keeps failing” into a number.
A knowledge base that outlives us
A tree of articles per workspace, nested up to six levels, with drafts that only their author sees until they are worth reading. The documents live on disk as one HTML file each — greppable, rsync-able, readable without a database client, which is worth something for the page describing how to restore the database. Anybody who works here may write; that is deliberately the widest gate in the product, because the failure mode of documentation is that it was never written.
A whiteboard wired to the data model
Sticky notes, boxes, text, arrows, freehand and images on an endless surface — for the two hours before a piece of work has a title and a type. A note can become a real issue and stays on the board pointing at what it became, so the shape of the argument survives the decision. An existing issue can be dropped on as a card showing its live status, so a board left open overnight is not lying by morning. Votes are stored as who rather than how many, so a misclick in a retro can be taken back.
Two hands on the same object
Everyone on a board sees everyone else's labelled cursor — whispered browser to browser, never reaching the server, because sixty positions a second is not worth a request or a row. Actual changes do go through the server, immediately rather than queued: a whiteboard is not news, it is a shared object two people are touching. Nothing is applied to an element you are holding, so a note never jumps backwards mid-drag.
Live, not polled
Laravel plus Reverb broadcasts issue and run changes per workspace, and run output streams over SSE. You watch an agent work rather than refreshing to find out whether it did.
Screens from the current build.
Taken from v0.23.1, running against a real agent CLI. The interface will keep moving before the doors open.
The issue, with the run in it
The current run streams into the thread while it happens — queued, awaiting a runtime, then output. Mention an agent with @name in a comment to hand it the work. Estimation, spent time and the time log sit in the same panel, so what a task cost is visible where it is discussed.
Cycles, and what they carry
Planned against capacity, with people and machine days counted separately, and a carried-in count per issue. An issue carried three cycles in a row is the honest signal that a board otherwise hides.
Gantt against what happened
Planned bars filled by progress, actual work beside them, due dates and project targets, the critical chain, and what waits for what. Filter by project, epic, people and agents — then save the view, because you will ask the same question next month.
Reports, including one about the agents
Status, time, Gantt, throughput, workload — and agent performance: runs, success rate and median duration per agent. Save any filtered report for yourself or for the whole workspace.
The ones worth asking first.
Anything else, write to felagi@elyracode.com — the same address the early-bird list goes to.
Do I have to give Félagi my model API keys?
No, and there is nowhere to put them. The server never calls a model — it schedules work and records what happened. Every LLM call is made by an agent CLI running on a machine you control, using whatever credentials that CLI already has.
Where does my source code go?
Nowhere it is not already. The daemon prepares an isolated work directory on the machine it runs on, and the agent CLI edits files there. Félagi stores the issue, the run metadata and the output the agent chose to report — not your repository.
Which agent CLIs does it work with?
Claude Code and Elyra today — Elyra first, deliberately, because we own both sides of that protocol and wanted the first end-to-end run to debug Félagi rather than somebody else's undocumented output format. The daemon detects which CLIs are installed on a machine and reports back what it can spawn, so an agent can only be pointed at one that is actually there.
Is Félagi open source?
No. Félagi is a commercial product and both the application and the Rust daemon are developed in private repositories. The documentation is public, so you can read exactly how it behaves — including the daemon protocol and the data model — before deciding anything.
What does it cost?
Pricing is not announced yet. It will be published before the doors open in late August, and the early-bird list hears first — that is the whole point of the list.
Can I try it now?
Not yet. The current build is v0.23.1 and there are no binaries: the daemon is built from source, and the daemon protocol may still change between minor releases. Rather than hand out something that breaks next week, we would rather write to you once when it is ready.
Does it replace Jira, Linear or YouTrack?
It is that shape of tool — projects, epics, issues, cycles, timesheets, reports — with agents wired through the same columns as people. There is an importer for Jira, Linear, YouTrack and Monday, column-mapped rather than magic, so you can see what will land before it does.
What happens if the machine running the daemon is asleep?
The run waits. An issue assigned to an agent whose runtime is offline sits queued and says so, and the daemon leases the work when it comes back — nothing is lost and nothing is silently retried somewhere else.
Félagi opens in late August.
There is nothing to download yet, and we would rather say so than take a payment against a date. Leave your address and you will hear from us when the doors open — first, and once.
Not available yet
Félagi becomes available late August 2026. The current build is v0.23.1 and runs from source; the daemon protocol may still change between minor releases before then.
Want it sooner, and a say in where it goes? 10 founding-partner places are open — free with unlimited users through the end of 2027.
Want the detail first? The documentation is already published — concepts, the guides, the daemon protocol and the data model.
Assign the issue.
Someone picks it up.
Whether that someone is a person or a process is, at last, a detail of the assignee field.