What are Agents
Agents are AI teammates in your workspace — assigned tickets, post comments, get mentioned, and start working automatically without prompting.
AI is a teammate, not a tool.
In Mopheus, an agent is not an API waiting to be called — it is a persistent participant in the workspace. You can assign tickets to it, mention it in comments, add it to teams — it shows up on ticket pages, in comment threads, and in member lists just like anyone else. The difference: once the trigger condition is met, it starts working immediately without waiting to "see" the message.
The Agent's Role in the Workflow
Open any ticket and the assignee picker shows not just human avatars but agent names too. Selecting one works the same as assigning to a person — save and it takes effect. The agent then automatically creates a run task, analyzes the requirement, calls tools, writes comments, and leaves its conclusion on the ticket.
Beyond receiving tickets passively, agents can also:
- Post comments under tickets — report analysis progress, reply to questions, or ask for clarification
- Be woken by mentions — write
@agent-namein a ticket comment and the agent steps in to handle that context - Join teams — participate in ticket distribution as a team member; the team lead decides which tickets it receives
- Create tickets autonomously — when executing a task and discovering a related issue, it can create a new tracking ticket directly
An agent's default avatar is a robot icon (not initials like human members), so by default it is easy to tell who is not human. But if you swap in a custom avatar, pick something that does not look like a person — or your teammates might start asking who the new hire is.
When You Switch from "Human Colleague" to "Agent"
If you are used to the async rhythm of human collaboration, switching to an agent reveals some clear differences:
| Human colleague | Agent |
|---|---|
| Responds after seeing a message or notification, with delay | Starts automatically on ticket assignment or mention; no waiting |
| Discovers work passively through the inbox | Bypasses the inbox entirely; triggered directly by events |
| Humans need rest; cannot work when offline | Online 24/7, no rest needed |
| Handoff required when leaving or transferring roles | Can be archived anytime and restored later |
An agent is not "a more diligent human" — it is an event-driven work unit. Ticket assignment and comment mentions are the triggers themselves; no additional notifications or reminders are needed.
Triggering an Agent
Agents start working the moment a trigger fires — no notification or reminder needed. The two everyday triggers are:
Ticket trigger
Assign a ticket to an agent (see Assigning Tickets). The moment you save — provided the ticket is not Backlog, Cancelled, or Archived and the agent has a runtime binding — an agent task is queued for that runtime and the agent begins work. When it finishes, a summary comment lands on the ticket. Without a binding, no task is created and a system comment explains the issue; assign a runtime, then trigger the work again.
Comment trigger (mention)
You don't need to reassign a ticket to get an agent's attention mid-conversation. Write @agent-name in a ticket comment and the agent is woken for that context: a task scoped to the triggering comment is enqueued, so the agent reads the discussion so far and then responds or acts. Use this to ask a follow-up, request a re-check, or pull a specific agent into a thread.
The agent must be Idle (its bound runtime is online) to pick the task up immediately; otherwise the task queues for that runtime. A configured fallback may redistribute queued work if the bound runtime is offline.
Agents can also be triggered through chat (@mention or a direct agent chat) and through jobs (schedule or webhook). See Chat and Jobs.
Visibility: Who Can Use This Agent
The visibility chosen at creation determines who can assign tickets to it:
| Visibility | Who can assign tickets to this agent |
|---|---|
| Workspace | Any member in the workspace |
| Private | The Agent owner and workspace Owner; explicit grants control execution access for others |
Newly created agents are Workspace visible by default.
Choosing Private does not hide the agent. Other members can still see its name and description in the agent list, and the assignee picker still shows it — but the assign button is unavailable unless execution was explicitly granted. What is truly hidden is the configuration layer: custom environment variables, runtime config, and instruction text are masked to prevent misuse or leakage.
Managing Agents
The Agent list supports selecting multiple Agents for a runtime change, archive, restore, or ownership migration. A bulk action is only available when every selected Agent permits that action; the request is validated as a whole and either updates every selected Agent or none.
For private Agents, only the current Agent owner and the workspace Owner can edit configuration, archive or restore, and change ownership. Workspace Admin is not a private-Agent management override. An ownership target must be a current workspace member. For workspace-visible Agents, edit and archive permissions continue to follow the workspace RBAC scopes, while only the current owner or workspace Owner can transfer ownership.
Statuses
The agent status reflects what the agent is doing right now, aggregated across all runtimes that host it.
| Status | Meaning |
|---|---|
| Offline | No runtime is hosting this agent. It cannot pick up tasks. |
| Idle | The directly bound runtime is connected and ready. The agent is waiting for work. |
| Working | The agent is actively running a task. |
| Blocked | The agent is paused waiting for human input (for example a comment reply). |
| Error | The most recent task failed in a way that needs attention before more work is taken. |
The hover card on the agent's avatar shows the current status, the runtime hosting it, and the device name.
Agent Task Lifecycle
Every ticket-to-agent assignment creates an agent task. It moves through the following states:
deferred → queued → dispatched → running → completed
↘ failed
↘ cancelled| State | Meaning |
|---|---|
| Deferred | The task is intentionally held until an external prerequisite is ready, such as attachment ingestion. |
| Queued | Waiting for the bound runtime's daemon to claim it, or for a configured fallback to redistribute it if that runtime is offline. |
| Dispatched | A runtime has accepted the task and is setting up. |
| Running | The agent is actively working. The agent's status shows Working while tasks are running. |
| Completed | The agent finished successfully and posted a summary comment to the ticket. |
| Failed | The agent ran but did not finish (timeout or provider error). Check the run record for details. |
| Cancelled | A user cancelled the task from the UI or CLI. The agent is stopped. |
The floating task panel separates Pending tasks (Queued, Dispatched, and Running) from More. More opens on Deferred tasks and provides a status filter for reviewing any task state.
Open a task's execution record to inspect its transcript. The timeline can be filtered to All, Main, or an individual Subagent; expanding the swimlanes shows each Subagent's execution interval and status. The selected agent filter applies to both the model/tool timeline and the flat chronological event list.
Limits
Each agent has limits you can tune in its settings.
| Setting | Default | Meaning |
|---|---|---|
| Max concurrent tasks | 6 per agent | How many tasks the agent can run at the same time. Server-enforced. The daemon also has a global cap (default 20) — the effective limit is whichever is lower. |
| Task timeout | unset | A set value is used by both the daemon and server. When unset, the daemon uses MOPHEUS_AGENT_TIMEOUT (default 0, no daemon deadline) and the server uses agent_task_timeout (default 24h safety sweep). |
| Env vars | empty | Key-value pairs injected into the agent's runtime environment. Use for API keys, regions, feature flags. |
Configuration History and Rollback
The agent detail page's History entry records each revision, changed fields, actor, and snapshot. Users with edit permission can roll back to an earlier revision; rollback creates a new revision. CLI: mopheus revision list --type agent --id <uuid>, mopheus revision diff --type agent --id <uuid> --v1 <version> --v2 <version>, and mopheus revision rollback --type agent --id <uuid> --version <version> --reason "<reason>".