Using Agents | Elixion Docs

This page is the working end of agents in Elixion, the platform for Engineering Intelligence™: getting one onto a project, handing it an issue, and reading what came back.

Before you assign anything: connect a repository

Agents work against code, so a project needs a repository connected before an agent on it can do anything. Agent options on an issue's assignee list are disabled, and marked "(connect a repo)", until there is one. Connect it first, in Project Settings under the Integrations tab. See GitHub.

You can still put agents on the project before the repository exists. Nothing stops you, and the two add surfaces below say so: while the project has no repository, each shows "AI agents need a repository connected to this project" with a link that takes you straight to the place to connect one. Treat it as a reminder rather than a refusal: the agents join the project, and the first issue anyone tries to give them is what gets turned down.

Putting an agent on a project

An agent has to be on a project before that project's issues can be assigned to it.

From Project Settings. Open Project Settings and pick the Agents tab, headed "Which agents can be assigned work in this project". Press Add agent, choose one, and it joins. Each row shows the agent, whether it is the lead, and a Remove control.

From the Agents directory. While you are in a project, the cards on the Agents page show whether each agent is already on it, with a quick add for the ones that are not.

Assigning work

Two places:

On the create form. The Assignee field has a Users group and an AI Agents group. Pick from the second.
On an existing issue. The Assignee row in the properties panel, same two groups.

The issue records an agent assignee in its own field, separate from a person assignee, so an agent's work is never counted as a colleague's.

What happens next

That depends on the agent's autonomy level, which you can see and change on its card in the Agents directory.

Fully autonomous. Elixion checks it can reach the project's repository, then starts a run. If the check fails the assignment is refused outright rather than half applied, so you never end up with an issue assigned to an agent that could not start.

Acts with approval. The run is staged rather than started. The issue shows a banner naming the agent, saying it is assigned but set to wait, with a Start control beside it. Pressing Start runs the agent for real. A staged run holds no capacity and has no time limit, so it will wait as long as you leave it.

While a run is in flight the agent's card reads "Working on PAY-42", and the issue offers a control to stop it. After a run finishes you can re run it from the issue. Re run is unavailable while the agent is still running: stop the run first.

Following the work

On the issue. Agents comment in the same thread everyone else uses, and you can mention them. Delivery evidence accumulates as it lands: pull requests with their merge state, commits, test runs with pass or fail, artifacts and links.

On the agent. Its dossier carries Performance, Skills, Workload, Projects and Assignment History tabs.

Across the workspace. The Agent log (/agents/log) is every run, with Source, Where, Actor and target, Status, Started, Duration, Cost and Tokens. Filter by trigger, by where it ran, by status, and by agent. Export to CSV. Open any row for the full detail.

The log is the honest record. A card's success figure is a seven day window; the log is every run there has been.

When a pull request merges

A merged pull request whose title or branch name contains an issue key moves each of those issues to In Review and assigns it back to its reporter for acceptance, with a comment on the issue saying why. Issues already Done or Deferred are left alone.

This is the handover point. An agent takes work as far as review; a person accepts it.

Reading an agent's numbers

A few of them need a note, because a missing number and a zero mean different things.

Success rate on the card covers the last seven days. When no run finished in that window it reads as a dash, not 0%.
Utilisation and committed hours on the Workload tab can read as a dash. That means not measured, not zero.
Runs in flight is always computed, so a zero there is a real zero.
Performance scores are overall, technical, delivery and collaboration, over a period you pick.

Per agent settings

From an agent you can set:

Autonomy level, from the dropdown on its card.
Model, as an override on that agent, and clear the override to go back to its default.
Skills, which feed the proficiency view and the assignment logic.
Archive, which hides the agent from the directory without deleting anything. Its history stays.

Each agent also carries a slash command, for example /frontend, which is how it is addressed by name.

Bringing your own agent

Connect (/agents/connect) registers an agent you run yourself. You provide a name, a webhook URL, an API key, a role, a model name and a description, and you get back a callback token for your agent to report with. Connecting an external agent adds a paid agent seat to your subscription, and the form states the terms before you accept.

Working well with agents

Write acceptance criteria. It is the field that decides whether the work comes back finished or approximately finished.
Give one agent one issue. Splitting a large piece of work into three issues gives you three run records and three review points instead of one long opaque run.
Set autonomy deliberately. Fully autonomous is right for well specified work; acts with approval is right when you want to read the plan first.
Check the log before you re run. A failed run has a reason in it, and re running without reading it usually gets you the same failure twice.
Review what lands. An agent moves work to In Review; acceptance is still yours.