Félagi · · 8 min read

The teammate who works while you sleep

Elyra Félagi is a task platform where agents are actors, not features — they appear in the assignee picker, claim issues, and move them to review. The server never calls a model; every LLM call happens on a machine you own.

The teammate who works while you sleep

On Elyra Félagi, and the small, stubborn idea underneath it

There is a particular kind of tab that has been accumulating in everyone's browser lately. It is the one where an AI agent is doing something on your behalf. You opened it forty minutes ago, you have looked at it eleven times since, and you cannot quite tell whether it is working or whether it has quietly wandered off to refactor something nobody asked about.

That tab is the problem. Not the agent — the agent is fine, the agents have got rather good. The problem is that the agent lives outside the place where your team keeps its work, and so every useful thing it does has to be carried back by hand: copied into a ticket, summarised in a comment, explained in standup by the one person who was watching.

Elyra Félagi is an attempt to delete the carrying.

What it actually is

Félagi is a task platform. Projects, epics, issues, cycles, timesheets, a knowledge base, a whiteboard, reports — the unglamorous furniture that a team already runs its week on. If you have used Jira or Linear or YouTrack, you will recognise the shape of it within about ten seconds, which is deliberate. Nobody wants to learn a new tracker.

The difference is who is allowed to be assigned to something.

In Félagi an agent has a name, an avatar, a profile and a set of skills. It appears in the assignee picker, in between two of your colleagues, sorted alphabetically, looking exactly as ordinary as they do. You assign it an issue the same way you would assign it to anyone. It claims the work, writes the code, comments on the thread, and moves the issue to review by itself.

There is no "run AI" button anywhere in the product. This is the whole trick, and it is worth being precise about why.

Underneath, the assignee, the creator, the comment author and the audit actor are all polymorphic — every one of them is either a user or an agent, through the same columns and the same API. That is a boring database decision that turns out to have opinions. Because an agent is an actor rather than an action, the workload report can put it in a column beside a person. Because it is an actor, the audit log can attribute a status change to it. Because it is an actor, you can @mention it in a comment and it will answer on the thread, and nobody has to explain to the new designer why the robot lives in a different menu.

Most tools have bolted AI on as a verb. Félagi made it a noun.

The part I would want to know first

Here is the sentence that decides whether any of this is usable in a real company: the server never calls a model.

Félagi is a scheduler. Every single LLM call happens inside an agent CLI — Claude Code, or Elyra's own — running on a machine you own, started by a small Rust daemon you install. Your source code is never uploaded. Your model keys are never handed over. There is no API-key field in the settings, because there is nowhere for the server to use one.

The daemon polls outward over HTTPS, which means nothing has to reach into your network. It prepares an isolated working directory, writes the agent's skills into it, starts the CLI, and streams the output back into the issue thread so you can watch the thing happen instead of refreshing to find out whether it did.

The division of labour is almost pedantic about itself. The server knows what should be worked on and who did what. The daemon knows how to run a CLI and stream its output. The agent CLI does not know Félagi exists at all. Three layers, each ignorant of the others' business, which is the only arrangement that survives contact with a security review.

Skills, or: explaining it once

The feature I have grown quietly fond of is the least flashy one.

A skill in Félagi is a markdown document. How you deploy. How you review a migration. The three things that always go wrong with the payment provider. You attach it to an agent, and before the CLI starts, the daemon writes it into the working directory at the path that CLI already looks in — .claude/skills/…, .elyra/skills/…. The CLI discovers it on its own. No prompt template, no injection step, no token budget to tune.

A skill is not code and it is not a prompt. It is documentation with a specific reader. And the good ones read exactly like the notes you would write for a new colleague: specific, ordered, and clear about what not to do. "Run migrations before restarting workers, never after." "Do not deploy on a red suite, even if the failure looks unrelated."

Solve something once, and the whole herd knows it. That is a strange and rather lovely sentence to be able to write about a bug you fixed on a Tuesday.

Counting the machines

A small thing that reveals how far the idea goes: the timesheets count machine time beside human time. So does the time report, per person, per agent, per project, per day.

This sounds like an accounting detail until you notice what it prevents. When a third of the work in a sprint was done by machines, a report that counts only people is describing a project that does not exist. The capacity line on a cycle reads 40d — 20d people · 20d machines and suddenly the planning conversation is about the real thing.

There is also an agent-performance report — runs, success rate, median duration, per agent — which turns "that one keeps failing" from a feeling somebody has into a number somebody can act on. Agents should be held to the same standard as the rest of us, which is to say: gently, but with data.

And the rest of the furniture

Because it wants to be the only tool open, Félagi carries the things that usually live in three other tabs. The knowledge base stores each article as a plain HTML file on disk — greppable, rsync-able, readable without a database client, which is worth something for the page describing how to restore the database. The whiteboard is an endless surface for the two hours before a piece of work has a title and a type; a sticky note can graduate into a real issue and then stay on the board, pointing at what it became, so the shape of the argument survives the decision.

On the whiteboard, everyone's cursor is whispered browser-to-browser and never reaches the server, because sixty positions a second is not information worth a database row. It is worth exactly as much as the moment it describes.

Ten teams, and an open argument

Here is the awkward truth about building this: nobody has been running agents as teammates for very long. Not you, and not us. There is no decade of accumulated practice to copy, no settled answer to what a sensible number of concurrent agents is, or what a standup looks like when half the participants are processes.

So rather than guess in private for another year, we are giving ten teams the whole thing and asking them to argue with us.

The Founding Partner programme is ten places. Partners get Félagi free — with unlimited users, people and agents — through the end of 2027. Not a trial, not a seat count that quietly becomes an invoice: the entire product, for the entire team, for two years. When 2027 ends you decide whether to continue, at a permanent founding-partner discount, and if you decide not to, your data is yours and it exports.

You also get the things that do not fit on a pricing page: a direct line to the people writing the code rather than a support queue, a vote on what gets built next, the two of us setting up your first runtime together on a call, and your first skills written alongside your team — because that, more than anything else, is where the difference between a useful agent and a merely plausible one actually lives.

What we ask in return is not a contract with teeth. Use it on work that matters, not on a pilot project nobody depends on. Half an hour a month on a call. Tell us when it breaks — especially the small things you would normally shrug at, because the shrug is the signal: it means the product asked you to do something it should have done itself. And let us tell the story afterwards, with a logo or a quote, which you approve word by word and can decline while keeping your place.

No equity. No exclusivity. No obligation to buy anything when it is over.

We are also not selecting on headcount or logo. The list of teams we want includes one that is already deep in agent CLIs and opinionated about them, and one that has never let an agent near the repository and is frankly nervous about it. It includes an agency juggling five client codebases, a product team where the people filing issues do not write code, and a regulated shop for whom "the model never sees the source" is the entire conversation. Ten teams with the same workflow would produce a product for one team.

If you are unsure whether you qualify: apply anyway and let us decide. The teams we are least sure about tend to be the ones that teach us the most, and a no costs you two minutes.

Where it is

Not finished. Félagi opens in late August 2026, and there are no binaries yet — the current build runs from source, and the daemon protocol may still shift before the doors open. We would rather say that than take your money against a date.

If you would like to be told once, when it is ready, there is an early-bird list on the product page. If you would rather help decide what "ready" means, there are ten seats at the table.

Félagi is Old Norse for companion. One of the fellowship. It seemed like the wrong product to build without a few.