Projects, goals & issues

The three levels

Projects are containers. They scope budgets, team permissions, file storage, and everything agents produce under them. A project is a unit of work you care about: “Launch the pricing page”, “Competitor research for Q2”, “Refactor the billing module”. Projects are long-lived. You might have five active projects and dozens of archived ones.

Goals are high-level objectives inside a project, written in plain English. A goal is one sentence describing a desired end state. “Launch the new pricing page by end of quarter” is a goal. “Cut build time from 14 minutes to under 5” is a goal. You write them, agents read them.

Issues are discrete pieces of work. They’re what actually gets done. Each issue has a title, a description, a status, an assignee, and (optionally) dependencies on other issues. Issues are what agents execute — the Project Manager breaks a goal into issues, picks an assignee for each one, and the assignees do the work.

A project might have three goals and thirty issues. Or one goal and two issues. Or fifty issues and no goals at all if you prefer to skip the goal layer and create issues directly. The hierarchy bends to your workflow.

The issue lifecycle

Every issue moves through a predictable series of statuses:

The normal happy path is Open → InProgress → PendingReview → Resolved. Dependencies add WaitingOnDependency to the mix. Reopening flips PendingReview back to InProgress.

You can set issues to any status manually from the dashboard. Agents generally only move them one step forward at a time.

Assignees

Every issue has an assignee — the entity responsible for doing the work. An assignee can be:

• A specialist agent — the agent picks up the issue on its next heartbeat and starts executing
• A human user — the issue appears in that user’s inbox; the platform waits for them
• Unassigned — the issue sits in Open until something or someone claims it

When the assignee is an agent, execution happens automatically on the agent’s heartbeat cycle. You don’t click anything — the issue goes Open → InProgress on its own, and the agent streams progress into the issue timeline as it works.

When the assignee is a human, the issue is a task on that person’s list. It won’t execute on its own.

Unassigned issues that sit in Open for too long are picked up by auto-dispatch — a background service that finds orphan issues and routes them to a best-fit agent. The default dispatch strategy hands the issue to your Project Manager, which assigns it using the full project context.

Dependencies

Issues can link to each other. The relationship that matters most is blocks / blocked-by:

Issue A: Draft the pricing copy
Issue B: Implement the pricing page  ← blocked by A
Issue C: Test the pricing page       ← blocked by B

When B is blocked by A, B stays in WaitingOnDependency status until A reaches Resolved. The moment A is resolved, B automatically transitions back to Open and becomes eligible for execution. Same for C when B finishes.

This is how you express ordered workflows without needing a formal DAG. Chain issues together with blocks/blocked-by and Exolvra enforces the ordering automatically.

Other link types — related-to and duplicate-of — are informational only. They show up in the UI but don’t affect execution.

How autonomous execution actually runs

The loop, from the platform’s point of view:

1. You (or the Project Manager) assign an issue to an agent
2. The agent’s heartbeat fires; it sees the new assignment and transitions the issue Open → InProgress
3. The agent uses tools to do the work: search the web, read files, write to the data store, send emails, call other tools
4. Intermediate progress streams into the issue’s activity timeline and comments — you can watch it live
5. When the agent decides it’s done, it writes a final comment and transitions the issue to PendingReview
6. A human reviews the result. Approve → Resolved. Reopen with feedback → InProgress again.
7. Resolution unblocks any dependent issues, which flip back to Open and become eligible for execution on their assignee’s next heartbeat

This loop runs in the background continuously. You can close the browser tab and come back to a finished project.

Completion criteria

Some issues have structured completion criteria — a checklist the agent is asked to satisfy before marking the issue done. Completion criteria are optional: most issues don’t need them. Use them for issues where “done” is ambiguous: “All three APIs documented”, “Staging deploy verified”, “Test coverage above 80%”. Agents read the criteria alongside the description and can self-check.

The activity timeline

Every issue has an activity timeline: a chronological record of status changes, tool calls, comments, attachments, and any notable events. It’s the audit trail. When you want to know what did the agent actually do?, the activity timeline is the answer.

When to skip the goal layer

Goals are helpful when you have multi-step, multi-specialist work. They’re overhead when you have a single ad-hoc task. For quick work, skip straight to issues:

1. Open the project
2. Click New issue, write what you want done
3. Assign it to an agent
4. Watch it execute

For larger initiatives, goals let the Project Manager do the decomposition work for you:

1. Open the project
2. Click New goal, write one sentence about the outcome
3. Walk away; come back when the PM has created and assigned issues

Both are valid.

Where to go next

• Your first project — the step-by-step for running through this loop end-to-end
• Projects — the dashboard reference
• Issues — issue detail view, statuses, comments
• Agents & chatbots — who does the work
• Orchestration patterns — the Star pattern is the PM-driven shape described above