How to Design Linear Statuses for Agent Automation

Statuses Are An Automation Contract

Linear statuses are not just board columns when AI agent automation is involved. They become a contract between humans, Switchboard, and the agent run.

Linear""'s own docs describe issues as belonging to a team, having an identifier, title, and status, with other properties layered on top. Switchboard uses that issue context to decide what should be picked up, where it should run, and what should happen next. If the statuses are vague, automation becomes vague too.

A good status model makes it clear which issues are ready, which are running, which need human input, and which are ready for review.

The Minimum Useful Flow

Start with a small flow:

Backlog
Ready for Agent
Agent Running
Needs Human Input
PR Ready
Done

You may already have different names. The labels matter less than the meaning. What matters is that each status answers a specific operational question.

Ready for Agent means the issue has enough detail for Switchboard to pick it up. Agent Running means an automated run is active or recently started. Needs Human Input means the agent is blocked, the issue is unclear, or a decision is needed. PR Ready means the work exists and needs review.

Keep Pickup Explicit

Do not let automation pick up every issue in a broad """Todo""" column. That makes it too easy for half-written ideas to become agent runs.

Use a dedicated status, label, or both. The pickup signal should mean:

• The issue is scoped.
• The target repo is known.
• Acceptance criteria exist.
• The route is configured.
• A human is comfortable with an agent opening a pull request.

This extra gate prevents Switchboard from turning your entire backlog into a noisy automation queue.

Add A Blocked State

Automation needs a place to stop cleanly. Without a blocked status, failed runs either sit in the running column forever or get pushed back to backlog with no useful signal.

Needs Human Input should be used when:

• The issue lacks context.
• The route points to the wrong repo or daemon.
• Tests are failing for reasons outside the task.
• The agent needs an approval that should not be handled blindly.
• The diff is too broad for the original issue.

That status is not a failure. It is a safety valve.

Separate PR Review From Done

Do not move agent-completed work straight to Done. A pull request created by Claude Code or Codex still needs review. The useful status is PR Ready or equivalent.

That state tells humans:

• The agent has produced a branch or PR.
• The implementation is ready for review.
• The issue should not be picked up again.
• The next action is code review, not more generation.

This distinction matters because automation is not the same as acceptance. The agent can complete a task; your team still owns the merge decision.

A Practical Status Map

This map is intentionally simple. You can add more detail later, but start with statuses that make ownership obvious.

How Filters Help

Linear filters can narrow views by status, label, assignee, priority, project, and other properties. That means you can create views for automation candidates, blocked agent runs, and PRs waiting on review.

For example:

• Ready for Agent plus a repo label.
• Needs Human Input plus high priority.
• PR Ready plus the team that owns review.

Those views help keep automation visible without turning the whole team board into a machine queue.

Tradeoffs

More statuses can create process overhead. Too few statuses hide important state. The right balance is the smallest number that makes automation safe to operate.

Avoid making a separate status for every technical outcome. You probably do not need Agent Installing, Agent Testing, and Agent Creating Branch unless your team actually acts on those states. Junction and Switchboard can show run activity in more detail; Linear statuses should capture workflow ownership.

Where Junction Fits

Switchboard connects the Linear side to the agent execution side. It can route work by team and repo, spawn isolated worktrees, run Claude Code or Codex, and open pull requests. Your Linear statuses decide what enters that lane and what humans do next.

If you already have routes, read Configure Switchboard Route Settings for Team and Repo Routing. If your issue content is the weak point, start with Write Linear Issues Ready for AI Agent Automation.