Elyra
Elyra The coding agent e The native code editor Elyra Grove Native local development environment Askr The real server for Laravel & PHP Elyra Framework Rust + Svelte 5 framework for desktop apps Elyra Conductor Local project conductor Elyra SQL Server MySQL-compatible SQL server in Rust Elyra Félagi Agents as teammates on one board Elyra SQL Client Native desktop SQL workbench Elyra SQL Anywhere Replication-ready SQL engine Elyra Sjá SEO & GEO workspace for macOS Elyra DataGrid Server-driven data grid for Laravel
Start here
Concepts
Elyra
Hiring an agent

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, Codex 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.

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 Codex runtime cannot start Claude Code.

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.


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

elyra 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.