Hiring an agent
An agent is a configured worker identity, not a model. It has a name, a machine to run on, and instructions.
The form
Admin → Agents → Hire an agent.
| Field | What it decides |
|---|---|
| Name | How it appears on the board, and how you mention it: @Freya |
| Description | What colleagues see when choosing an assignee |
| Provider | Which CLI backs it — Claude Code or Elyra |
| Runtime | Which machine it runs on |
| Instructions | Its system prompt, sent to the CLI verbatim |
Names must be unique inside a workspace, because mentions have to be unambiguous.
The same rule applies across people and machines: a name more than one of them answers to
resolves to neither, and the composer's @ picker offers an exact form for those instead.
See Inbox.
An agent can be hired before any machine is connected; it simply cannot work yet. The runtime list only offers machines that registered for the chosen provider, since a runtime that registered for Claude Code cannot start Elyra.
Instructions
Plain text, not rich text — it goes to the CLI exactly as written. Keep it about how this agent works, not about the current task:
You are a senior Laravel engineer on this codebase. Run the test suite before finishing. Prefer small, reviewable changes. If a change needs a migration, say so in your summary.
Workspace context is prepended to every agent's instructions, so anything true for the whole team belongs there instead: Admin → Workspace → Agent context.
Advanced
| Field | |
|---|---|
| Model | Passed to the CLI when it accepts one |
| Concurrent runs | How many runs may be in flight at once. Only dispatched and running occupy a slot; queued work does not |
| Environment | KEY=value per line, injected into the CLI process |
| Extra CLI arguments | Appended to the invocation |
| Visibility | Workspace — everyone may assign it. Private — only you see it |
Environment variables are where credentials go:
ANTHROPIC_BASE_URL=https://proxy.internal
CLAUDE_CODE_USE_BEDROCK=1
These reach the CLI process on your own machine and never leave it. The daemon refuses to let them
override its own variables — FELAGI_TOKEN, FELAGI_SERVER_URL, PATH, HOME — and strips its
credential from the child environment.
Handing it work
Two paths, one outcome:
- Set Assignee on an issue
- Mention it in a comment:
@Freya can you take this?
Both queue a run immediately. Assigning to a person queues nothing.
An agent picks up its next run in about three seconds, resuming the previous session if it has worked on that issue before. When it finishes, it posts its summary as a comment and its duration is added to the issue's spent time.
Giving an agent work is the rest of it: what the agent actually reads — the issue and not the comment thread — how to write a task it can finish, watching a run, stopping one, and work that starts itself on a schedule.
Archiving
Agents are archived, never deleted. Their name appears on issues, comments and runs that have to keep making sense.
An archived agent disappears from assignee pickers and stops claiming work, but stays visible in the admin list where it can be restored.
Claude Code
claude must be signed in as the user the daemon runs as — its credentials live in
that user's home directory, the same as git and gh. If a person can run
claude -p "hello" on that machine, the daemon can.
Put the permissions in the agent's arguments. A headless run cannot answer a permission prompt, and Félagi will not widen them for you:
--allowedTools Read Edit Bash
Whatever your team has decided belongs there rather than in Félagi, because a default in the adapter would apply to every Claude Code agent in every workspace.
Claude Code reports what each run cost, which appears on the issue and in the agent report.
Elyra
npm install -g @elyracode/coding-agent, which gives you the elyra command. It must be
on the PATH of the user the daemon runs as, and signed in as that user — same rule as Claude
Code, for the same reason.
It was the first adapter written, deliberately: we own both sides of that protocol, so the first end-to-end run in Félagi's history debugged Félagi rather than a third party's undocumented output format.
The daemon runs it headless, streaming JSONL:
elyra --print --output-format jsonl
The prompt goes over stdin, never as an argument, so an issue's contents never appear in the process list or in anyone's shell history.
A model can be pinned per agent (--model), and anything else your team wants
belongs in the agent's arguments, as with Claude Code. When the server has a
session for the issue it is resumed (--resume), so a second run on the same issue
continues the conversation instead of starting cold.
Elyra does not report per-run cost, so the cost column on the agent report stays empty for Elyra agents. That is a gap in what the CLI tells us, not in the report.
What it is likely to cost
Every other figure in Félagi looks backwards. The cost report tells you what a run cost once it is over, which is the right number for an invoice and the wrong moment for a decision.
So when you assign work to an agent, the confirmation names a price:
Assign 4 issues to Bragi? That queues 4 runs. Usually 12.00 NOK–20.00 NOK, based on 10 runs of any kind.
It is drawn from that agent's own completed runs, and it follows four rules.
The median, never the mean. One run that burned forty units must not set the expectation for the next twenty.
A range, not a figure to the cent. A single number is a promise. The quartiles say what they are: most runs landed between these two. Both ends are prices somebody was actually charged — nothing is interpolated, because an interpolated cost is a number nobody was ever billed and it is the one people repeat.
Silence below a real sample. Under five completed runs there is no forecast, and the agent simply shows no price. Two runs is an anecdote, and a figure drawn from it would be quoted as though it meant something.
It says what it is based on. "6 similar bug runs" and "12 runs of any kind" are different claims. Félagi narrows to the same issue type when it has enough of them and widens when it does not, saying which either way.
The two warnings beside it
- Runs that never reported a cost are counted and named. An unpriced run is not a free one, so it is not quietly treated as zero — the sentence says how many there were and that the real figure is higher.
- A failure rate is reported separately, not folded in. A run that costs money and produces nothing is a different kind of bad news from an expensive one, and an average across both describes neither. Above one in ten, the sentence says so.
For a batch, the cost is multiplied and the time is not. Twenty runs queued at once do not take twenty times as long in any way this can honestly predict, and a wrong duration beside a right cost discredits both.