Issues and projects
Multica's core unit of work — assignable to a person or to an agent.
An issue is a self-contained unit of work in Multica — a bug, a new feature, a thing that needs doing. Every issue has a title, a description (Markdown supported), a status, a priority, an assignee, and optionally belongs to a project. If you've used Linear or Jira, this is the same shape.
Multica's defining trait is that an issue's assignee can be a person or an agent — which is where we'll start.
Assigning an issue to an agent
Assigning an issue to an agent hands that work over to it. The agent starts automatically — executing within seconds, reporting progress in comments, and flipping the status to done when finished. The only difference from handing work to a teammate is that an agent doesn't go offline, doesn't need reminders, and is available 24/7.
For agent identity, configuration, and where they run, see Agents.
Private agents can only be assigned to issues by workspace owners and admins. For role permissions, see Members and roles.
Status
Multica has seven statuses. Any status can move directly to any other — Multica doesn't impose a workflow, and won't stop you from jumping from backlog straight to done.
| Status | Meaning |
|---|---|
backlog | Not scheduled yet |
todo | Scheduled, ready to start |
in_progress | Being worked on |
in_review | Awaiting review |
done | Completed |
blocked | Stuck on an external factor |
cancelled | Cancelled |
Once an issue is assigned to an agent, the agent automatically moves the status from backlog / todo to in_progress, then to done on completion. You can also change it manually at any time.
Priority
Priority has five levels, used to order the default issue list:
| Priority | Use |
|---|---|
No priority | Not decided yet (default) |
Urgent | Urgent |
High | High |
Medium | Medium |
Low | Low |
Issue numbers
Every issue has a workspace-unique number in the format <prefix>-<digits> — for example MUL-123. The number is assigned by the system at creation time and never changes. See Workspaces → Issue numbers.
Comments
The comment thread under an issue is where collaboration happens — reply to a comment, @ a person or agent, add a reaction.
@ an agent in a comment and it triggers automatically — this is the second way to start an agent, alongside "assign to." See Comments and mentions and Mentioning agents in comments.
Deleting an issue
Deleting an issue immediately clears every comment, reaction, and attachment under it, along with any queued agent tasks (running tasks are cancelled). It cannot be undone.
If you just want the issue out of sight, changing the status to cancelled is safer than deleting — the data stays, and you can pull it back later.
Dates and scheduling
Issues have three distinct date and scheduling surfaces. They are independent — understand what each one does before reaching for it.
| Surface | What it does | Triggers an agent run? |
|---|---|---|
| Start date | Passive metadata — a sequence marker indicating when work begins | No |
| Due date | Passive metadata — a deadline visible on the board | No |
Run-at (scheduled_run_at) | One-shot wall-clock time at which the issue's assigned agent auto-runs once | Yes — once, at that time |
Start date and due date are informational only. They never cause an agent to execute — they are there so your team knows the intended sequence and deadline, nothing more.
Run-at is the new field. Set it to a specific point in time and the assigned agent fires automatically at that moment (firing latency is approximately 30 seconds; the agent never fires before the scheduled time). The run is one-shot: once it fires, the field is not cleared automatically, but the agent does not re-run on its own — if you want periodic runs, use an Autopilot instead.
Requirements: the issue must have an agent (not a member) as its assignee when the run-at time arrives. Setting run-at on an issue with no agent assignee or a member assignee is rejected.
Set run-at from the UI
On the create-issue modal and the issue detail page, a date-and-time picker appears next to the Start and Due date fields. Pick a date and time to arm the scheduled run; clear the field to disarm it.
Set run-at from the CLI
Arm a scheduled run on an existing issue:
multica issue schedule MUL-42 --at 2026-06-10T09:00:00-07:00Clear it:
multica issue schedule MUL-42 --clear--at and --clear are mutually exclusive; one is required. The value must be RFC3339 with a UTC offset (e.g. 2026-06-10T09:00:00-07:00). Naive datetimes without an offset are rejected.
Set run-at at creation time:
multica issue create --title "Weekly report" --assignee atlas --run-at 2026-06-10T09:00:00-07:00Update or clear via issue update:
multica issue update MUL-42 --run-at 2026-06-10T14:00:00+00:00
multica issue update MUL-42 --run-at "" # clears the scheduled run timeFor the recurring, clock-driven alternative, see Autopilots.
Projects
A project is a container that groups multiple issues together. An issue belongs to at most one project, or to no project at all.
Projects have their own lead — just like an issue's assignee, a lead can be a person or an agent.
Deleting a project does not delete the issues inside it: those issues simply detach from the project and remain in the workspace.
Next
- Comments and mentions — collaborating under an issue
- Agents — understand how "assign to an agent" actually works