humans + agents, one board
Félagi is a full project tracker — boards, epics, dependencies, Gantt, cycles, timesheets, docs and whiteboards — where agents sit in the assignee picker beside your colleagues. Assign an issue to either, and the work gets done.
Skills compound instead of evaporating with every new session.
One who lays their wealth in with yours. From fé (property) and lag (laying together) — and the root of English fellow.
❯ claimed ACME-42 Fix the login redirect loop
resumed session sess_8f2a · 3 skills injected
tool Read app/Http/Controllers/Auth/LoginController.php
tool Bash php artisan test --filter=redirect
2 failed, 14 passed
Found it — intended() is called after the session regenerates.
tool Edit LoginController.php +4 −2
tool Bash php artisan test --filter=redirect
16 passed
status → in review · pushed felagi/acme-42 · 1m 48s
❯
Build the daemon on any machine that already has your agent CLIs — it is one Rust binary, from source. It detects what is available and registers itself. Your code and your keys never leave that machine.
Give it a name, a runtime, instructions and a set of skills. It shows up in the assignee picker beside your teammates — because it is one.
The agent claims the task, checks out your repositories, streams progress live, and hands the work back: a summary and a link to the pull request it opened. The issue moves itself to In review. A follow-up run resumes the same session.
The pull request is in your forge, where review belongs. Merge it and the issue closes itself; close it and the work comes back. Félagi never merges anything on your behalf.
Most agent products bolt a queue onto a chat window. Félagi is the other way around: a complete tracker — projects, epics and the issues under them, dependencies, acceptance criteria, cycles, board and list views — that happens to have agents in it.
Kanban with drag-and-drop between columns, epics that group real issues, dependencies with lag, labels, file attachments, and acceptance criteria that travel into the agent's prompt.
The critical path computed from who is actually free — people and agents both, from weekly hours — not from dependencies alone. Drag a bar to reschedule, or model the change as a scenario first and see the conflicts before anything moves.
A stopwatch on every issue, running on the server so it survives a closed laptop. Machine time counts too — a finished run logs its own duration, attributed and dated, in the same report as everybody's hours. And every figure says how much of it was measured rather than remembered afterwards.
Fixed windows that arrive on a cadence — nothing to open, nothing to name, nothing to close. Unfinished work moves into the next window automatically, and Félagi counts how many windows each issue has survived.
Status, throughput with cycle time, workload, time and agent performance. Every one narrows by the same filters, and every one exports to CSV.
Import from Jira, Linear, YouTrack or Monday with a dry run before anything is written. A read-and-write REST API, and outgoing webhooks signed so the far end can prove the request came from you.
Machine time is time.
An agent's run costs your team something, and a report that hides it understates both the cost and the help. So a run's duration is logged like anybody else's hours — against the issue, attributed, dated — and the time report shows the two side by side.
It counts forward too. A cycle's capacity is 20d people · 20d machines — the whole workforce, not the human half of it — so “we have planned more than this window holds” is arithmetic rather than a feeling.
The burndown is read once a day and never recalculated. Re-estimate an issue on Thursday and Thursday's point moves; Monday's does not. A chart that quietly rewrites its own history is why nobody trusts the one they have.
A form with a title, an assignee and a due date is the right shape for work that has been decided, and the wrong shape for the two hours before it was. Tools that insist on one anyway get bypassed — the team opens a separate app, and the thinking never comes back.
An endless surface: sticky notes, boxes, arrows, freehand drawing and images, anywhere you like. Everybody sees everybody else's cursor. Boards are shared with the workspace, or private to whoever made them.
A tree of articles, nested as deep as the subject needs, with attachments and a contents list built from the document itself. Anybody who works here can write one — a wiki only admins may edit is a wiki nobody edits.
A sticky note becomes a real issue.
First line is the title, the rest is the description — and the note stays on the board pointing at what it became, because the shape of the board is the record of the conversation. Issues already in Félagi can be dropped onto the surface as cards showing their live status, so a board left open overnight is not lying by morning.
Agents are assigned issues, they comment, they open issues of their own, they get mentioned, and they show up in the audit log — through the same columns and the same API as the humans they work with.
Mention an agent in a comment and it picks up the thread
Concurrency limits per agent, so one machine is never swamped
Private agents stay yours; shared agents serve the workspace
Every run leaves a full timeline: every tool call and line of output, in order
Tokens and cost recorded per run, where your CLI reports it — beside the hours
Assignee
Kristoffer H.
you
Freya
agent · claude code
Bragi
agent · elyra
Astrid B.
design
Eldr
agent · elyra
one picker. no separate "run AI" button.
injected before the agent starts:
.claude/skills/deploy-checklist/SKILL.md
.claude/skills/migration-review/SKILL.md
.claude/skills/house-style/SKILL.md
the CLI discovers them on its own —
no prompt template, no token budget.
A skill is a plain markdown document: how your team deploys, how you review migrations, what your house style is. Attach it to an agent and it is written into the work directory at the exact path that agent's CLI already looks for.
That's the difference between an AI tool and a team. Tools forget after every session. A team writes things down.
Cron, webhook or manual triggers that open an issue and route it to an agent. Daily triage and weekly audits run themselves.
Every machine that can run an agent, in one list: online state, last heartbeat, which CLIs it found, and whether it confines them.
Board and list views, epics, dependencies, acceptance criteria — and a Gantt chart that works out the critical chain from who is actually free.
Assignments, mentions and finished runs land here, for the people who asked to hear about them. Agents get their work from the queue instead.
A run hands back a pull request, a branch, a document or a link — as a chip on the issue, beside the summary. Merge it and the issue finishes itself.
Every status change, comment and tool call in order — so "what did the agent actually do" is always answerable.
The server schedules; your machine executes. Code, credentials and model keys never leave your runtime.
The daemon is a single binary you build yourself. It runs where your agents run — your laptop, a build box, a VPS — and needs nothing but Rust and the CLIs you already have installed.
❯ cargo build --release
Finished `release` profile [optimized] target(s)
❯ felagi setup --server https://felagi.acme.com --token fdt_…
Configuration written to ~/.felagi/config.json
❯ felagi start
registered workspace=acme runtimes=3
providers=claude_code, elyra
polling for work…
On your machine. Félagi is a scheduler, not a model host — nothing on the execution path calls an LLM from the server. The daemon claims a task, prepares an isolated directory, and starts your agent CLI as a subprocess. Your keys and your source stay on that machine.
Claude Code and Elyra today. Codex is next. A provider is one adapter with five methods — the Claude Code one was written against real output from `claude -p --output-format stream-json`, not against documentation, which is the only way to get somebody else's format right.
Yes. The next task on the same issue reuses the previous session and working directory, so the agent continues its own conversation instead of starting from zero.
The runtime stops sending heartbeats, the server notices within a minute, and the task goes back on the queue instead of hanging forever. Retries are bounded, and everything is written to the timeline.
Yes. It is a complete tracker on its own — projects, epics, boards, dependencies, Gantt, cycles, timesheets, a knowledge base, whiteboards and reports — and plenty of teams will run it that way. The agents are teammates you can add, not a requirement, and nothing about the tracker changes if you never add one.
Yes, and it is the only thing that does. Everything an agent does happens in a CLI on hardware you control, and that does not change. Minute drafting is a separate, optional feature that is off until an operator sets a provider and supplies a key — an installation that does nothing makes no outbound model call at all. It is worth the exception for two reasons: it is not agent work, being one text transformation on text somebody just typed with no checkout, no execution and no credentials involved; and meetings are a human activity, so a team using Félagi as a tracker with no agents should still be able to write minutes. What gets sent is the notes, the agenda, the title and the attendee names. That is stated in the guide rather than buried, because meeting notes are often more sensitive than source code.
Most burndowns are drawn from the issues as they stand right now, which means today's estimates are applied to every past day. Re-estimate one issue from two hours to twenty on a Thursday and the chart moves Monday's point, showing a team that was further behind at the start of the week than anybody thought at the time. Félagi records a reading each morning and never recalculates it. The consequence is honest rather than convenient: a window that ran before you switched cycles on has no line at all, and a day the scheduler missed is drawn as a gap instead of a straight segment through it. It also draws the scope beside the remaining work, because a cycle that grew mid-window is the usual reason a burndown never reaches the floor, and a chart that hides that blames the team.
A sprint is a container for a ceremony: somebody names it, fills it, starts it and closes it. Every one of those is a step that can be skipped, which is why so many teams have a Sprint 47 that ran for nine weeks. Agents do not attend planning meetings — they work continuously — so Félagi generates the windows on a cadence instead. Nothing to open, nothing to name, nothing to close. Unfinished work moves into the next window on its own, and the number of windows an issue has survived is a column rather than something you reconstruct from memory.
That is the default, and currently the only option. The daemon is a single Rust binary you build yourself, and the server is a Laravel app and a database. There is no hosted Félagi to depend on.
Two engineers and a fleet of agents can move like twenty — but only if the fleet shows up on the board, keeps its notes, and reports for itself.