Issues

An issue is the core unit of work in a workspace: a request, a task, a bug, a line of a plan. It has a title, a description, a status, a priority, an assignee, and a thread. If you have used a tracker like Linear or Jira, the shape is familiar.

Bounc differs in one point: the assignee can be an agent or a team, not only a person. Human work and AI work then run down one list, under the same statuses and the same history.

An issue's fields

• Title and description — the description supports formatting and attachments.
• Status — where the issue stands right now.
• Priority — how much it matters.
• Assignee — a member, an agent, or a team.
• Team — decides the issue's identifier (ACME-123) and where it sits in the structure.
• Dates — a start date and a due date. The Gantt view and the overdue marker are built from them.
• Project — an issue can belong to one project.
• Labels — as many colored tags as you need.
• Sub-issues — the breakdown of larger work.
• History — who filed it, when it was created and updated, every status and assignee change.
• Runs and usage — if an agent worked on it: its runs with their transcripts, and the tokens spent.

Statuses

There are seven. Every transition is allowed: Bounc imposes no route and will not stop you from moving an issue straight from the backlog to Done.

An agent that picks an issue up moves it to In progress itself, and to Done when it finishes. You can change the status by hand at any time.

Priorities

Five levels, and the list sorts by them by default: Urgent, High, Medium, Low, and no priority.

The assignee

• A person — the ordinary case: the issue shows up in their My issues, and the assignment comes to their notifications.
• An agent — assigning starts the work automatically, within seconds. The agent posts its progress as comments and moves the status itself.
• A team — the work goes to a group of agents, and the leader decides who takes it.

Two rules worth knowing up front:

• An issue in the backlog does not start. The assignment sticks, but the agent only begins once the issue moves to an active status.
• Not everyone can assign a private agent — only its owner and the workspace's admins and owners. See Members and roles.

Sub-issues

Larger work is broken into sub-issues. Nesting is one level deep: a sub-issue cannot have sub-issues of its own.

A sub-issue is a relationship, not a special type: it has its own number, status, priority, and assignee, and it can go to an agent like any other issue.

Labels

A label is a reusable colored tag. The set is defined once per workspace (Settings → Labels), and labels then go on any issue and drive the filters — slicing the list by area, by kind of work, or by whatever else the team tracks.

The feed and bound threads

An issue has one feed: events, comments by people and agents, and the assignee's work. Conversations about the issue are bound to it: a chat with an agent (Bind to a task in the chat's header) or a message from a direct message or a channel (its branch). A bound thread lives as a widget in the issue's feed: collapsed to one line or expanded with its own input and artifacts. Anyone who sees the issue can write in it, and it no longer shows separately in Chats. An issue has no "New thread" of its own: ask an agent a short question with @ in a comment, and hold a long conversation in Chats and bind it.

The input row at the bottom writes to the assignee agent: the message goes to it as work, and its chip can be taken off for one message, which then is a plain comment. With a person assignee, no assignee, or an agent you may not run, the row writes a comment. Next to the assignee, the issue's header shows how the work goes and one action: Stop, Continue, Run again or Start.

• A thread is bound to at most one issue; moving it to another and unbinding ask for confirmation.
• Unbound, the thread goes back where it was born, and everyone who wrote in it stays a member.
• From a message of a direct message or a channel the issue sees only that message and its replies; the rest of the conversation stays closed.
• Waiting for an answer · N counts the agents' questions and permissions in the feed and the widgets; Next takes you to the next one.
• A bound thread has a short summary: a person writes it, and an agent can propose its version beside it.

Agent runs

Every handoff to an agent — an assignment, an @-mention, an autopilot firing, a workflow step, an Assetflow — produces a run: one execution of that agent on this issue. The same issue can go to an agent many times, and each time is a new run with its own history.

An issue's runs are listed in its properties, under Runs.

Run statuses

What a run leaves behind

• A transcript — an ordered log of everything the agent did and said: its reasoning, the tools it called, and what they returned.
• Usage — the tokens spent, per model. The aggregate picture is in Monitoring.
• The result on the issue — comments, a changed status, new related issues.

Continuing the context

Handing the same issue to the same agent again continues the earlier conversation instead of starting over: Bounc keeps the session on the issue-and-agent pair and returns the agent to it. You can force a clean start when you want one. How fully a session resumes depends on the provider.

Limits and deadlines

• One active run per issue and agent. A repeat trigger, while the previous run has not started yet, does not double the work.
• Concurrency is capped by the runtime's capacity; the excess waits in the queue rather than failing.
• Stuck runs clear themselves: one not started within 5 minutes of being handed to the runtime, and one working for over an hour, are marked failed; one never claimed from the queue within 24 hours expires.

Why a run failed

A failure always carries a reason, and it is visible on the issue:

Failures of runs started by an autopilot additionally reach your inbox.

A run in flight can be stopped — the issue stays, and the partial result is kept.

Views and filters

The same list of issues is shown in several ways:

• List — issues in status groups. Groups with no issues are hidden; «Show empty groups» in Display options brings them back.
• Board — columns by status or another grouping field.
• Gantt — bars from the start and due dates; available in the issues section and inside a project. The issue name and the assignee are pinned on the left; drag the edge of the name column to resize it.
• Eisenhower matrix — the four important/urgent quadrants, in the issues section.

Any view takes grouping (by status, assignee, project, or parent issue), ordering (priority, due date, start date, creation date, title, or manual), and filters — status, priority, assignee, creator, project, initiative, label. A separate My issues page narrows the list to what is assigned to you, filed by you, or handed to your agents.

The issue menu and keys

A right click on an issue in any view, on a sub-issue on an issue's page, or ⋯ opens one menu: properties, sub-issues, copying, subscribing and pinning, deleting. An item shows its key on the right. A key acts on the issue under the pointer, or on the open issue on its page; with issues selected, S, P, A and delete act on all of them.

Issue numbers

An issue's identifier is its team's identifier plus a number: ACME-123. The number is assigned at creation and changes only when the issue moves to another team — and the old identifier keeps opening. The details are in Workspaces.

Deleting an issue

Next

• Assigning and mentioning — the two ways to hand work to an agent.
• Comments — the thread under an issue.
• Projects and initiatives — grouping issues into larger bodies of work.