Agent work queues: Linear as a task board for AI

What is an agent work queue?

In a queue, tasks wait their turn and are processed in order. For AI agents, the queue replaces the habit of giving loose instructions in a chat, where the request gets lost in the history and nobody knows what was asked or what was done.

A useful queue has four properties:

• Each task is a record. It has an identifier, a description, a status and an owner.
• The order is visible. You know what comes next and what depends on what.
• The result returns to the same place. The agent leaves its progress, a link to its code or a blocker note on the task.
• A person is responsible. The queue does not decide on its own; someone reviews and accepts.

How do you build that queue in Linear?

According to Linear’s documentation, agents work like users of the application: an administrator installs them, chooses which teams they can access, and from then on anyone with access to those teams can interact with them. There are two ways to give them work: delegate an issue to them, or @mention them in a comment or description. Linear also lets you install third-party agents or build your own on its developer platform.

The key piece is delegation. According to the documentation, delegating means giving an issue to an agent while a person stays as the assignee: the person remains responsible for the work and the agent contributes on their behalf. You do it by choosing the agent in the assignment menu, and you can change or remove it at any time with the “No agent” option.

A delegated issue keeps appearing in the assignee’s “My Issues” view, so the responsible person does not lose sight of what is done on their behalf. To build the queue, Linear offers custom views you can filter by delegate and Insights reports you can slice by delegate. With that, “the queue” is a view: the issues delegated to an agent, sorted by priority and grouped by status.

Two details from the documentation worth knowing before you set it up. Agents are not billable seats, but each agent’s provider may have its own pricing, so check its terms before installing. And remember that an agent can only receive issues from the teams the administrator gave it access to at installation.

What does the agent see when you delegate a ticket?

Linear lets administrators and team leads write “additional guidance” in Markdown that agents receive when working on issues. It can apply to the whole workspace or to one team; when both exist, team guidance takes priority. It is useful for saying which repository to work in, how to reference the issue in commits and PRs, or what review is required. The documentation notes that how an agent applies that guidance depends on its integration.

If you build your own agent, the developer documentation describes the cycle: when the agent is delegated an issue or mentioned, Linear creates a session (AgentSession) and sends a webhook. The agent must acknowledge with a first activity within seconds; after that it reports progress with activities such as thoughts, actions and a final response. If it needs clarification, it emits a request for input and the person replies. Sessions show states visible to users, including pending, active, awaitingInput, error and complete.

For coding agents that connect another way, Linear also has an official MCP server; to understand the protocol, read MCP explained for designers.

What should a ticket look like for an agent?

A ticket an agent can take well answers four questions:

1. What is wanted? An objective in one sentence, not a topic.
2. How do I know it is done? Verifiable acceptance criteria: a test that passes, a screen that meets a rule.
3. What may I touch? Allowed folders, files or modules.
4. What do I do if I get stuck? For example, leave a blocker note and change the status, instead of improvising.

If the ticket says “improve sign-up”, the agent will invent what “improve” means. If it says “add email validation to the sign-up form, using the design’s error message in Figma, with tests for three cases”, you have a task you can review.

How do you order the queue?

A simple order works better than a complicated one:

• Blockers first. Whatever unblocks others goes on top.
• Independent tasks together. That way they can be parallelized without colliding.
• Reviews before new tasks. A PR waiting for review stalls the whole flow.

And limit the size of the queue. Fifty tickets for agents produce fifty results that nobody reviews. A practical limit: the queue should never hold more work than one person can review in a day.

When should you NOT use one?

• When the task has no acceptance criteria. The agent delivers something, but nobody knows whether it works.
• When the work changes every hour. The queue becomes stale and agents work on old assumptions.
• When nobody reviews. A queue without review only piles up unvalidated work.

Example

Illustrative example: a product team has five issues delegated to agents. Three are independent: adjust an empty state, add an accessibility test and update a help text. Two depend on a design decision that is not ready yet, so they wait with a note explaining what is missing. Each agent takes its issue and leaves a link to the PR and a summary of what it tested. The custom view filtered by delegate shows how much each agent holds, and the assignee reviews first the PRs that unblock others; only then do they open the issue for the pending decision.

Fernando’s blog has a case with two agents coordinated through file-based tickets, a two-agent workflow where Claude Opus 4.8 manages OpenCode. For the layer that decides who takes each task, read agent orchestration. To keep each agent’s changes isolated, see git worktrees for agents.

Common mistakes

• Giving tickets without acceptance criteria.
• Letting every agent take whatever it wants, without folder limits.
• Using the queue as an idea box. What is not ready belongs in a draft, not in the queue.
• Measuring success by how many tickets the agents closed. What matters is how many were accepted after review.
• Leaving delegated issues with no assignee who answers for the result.
• Installing an agent without checking which permissions and teams it was granted.

Sources

• Agents in Linear (official Linear documentation)
• Assign and delegate issues (official Linear documentation)
• Agents for developers (official Linear documentation)
• Agent interaction (official Linear documentation)
• Linear MCP server (official Linear documentation)