Linear with Agents: Connecting Your Backlog to AI Without Losing Control
Linear connects to AI agents through its official MCP server or by delegating issues, with read or write permissions. How to use it safely, step by step.
How does the connection work?
Linear hosts its own MCP server. According to its documentation, the main endpoint is mcp.linear.app/mcp over streamable HTTP; the /sse endpoint is deprecated. Authentication uses OAuth 2.1: the first time, your browser asks for approval. You can also use a token or an API key in the authorization header, which is useful for programmatic setups.
According to the documentation, the server can find, create, and update objects such as issues, projects, and comments. The page also mentions documents and says more functionality is on the way. Linear lists Claude, Claude Code, Codex, Cursor, VS Code, Windsurf and Zed, among others, as supported clients.
Linear Agent, its own agent, can also connect to other MCP servers from the agent’s personalization settings or from triage automations (an April 2026 addition). Admins control access with allowlists and workspace-level MCP permissions.
What if I want to delegate the issue instead of connecting my own agent?
Linear has two different paths, and it helps not to mix them up:
- MCP (you bring the agent to Linear): you open Claude Code, Codex, Cursor or another client, and it reads and writes in Linear under your account.
- Agent platform (Linear brings the work to the agent): a workspace admin installs an agent from the Integrations Directory and chooses which teams it can access. Then you can assign (delegate) an issue to it or @mention it in a comment. On Linear’s integrations page, Codex appears as an agent you delegate issues to and Cursor as an agent that turns issues into pull requests; Claude is listed as an AI client that connects through MCP.
Installed agents are not billable seats, although their providers may charge separately. They cannot sign in to the app, access admin functions or manage users. Linear also lets you write workspace-level and team-level guidance with your conventions; if both exist, team guidance takes priority. To track what each agent did, you can filter custom views by “Delegate.”
Which Linear plan do I need?
According to Linear’s pricing page in November 2026, MCP access, Linear Agent and the agent platform are included in every plan, including Free. The cloud coding agent and Loops require AI credits. The paid plans cost $10 (Basic) and $16 (Business) per user per month billed yearly; Enterprise is custom. Prices change, so confirm them on the page before you decide.
What can an agent do with Linear, and why does it matter to a designer?
An agent can read an issue, propose a plan or update its status. It matters to a designer because the backlog is where a design idea becomes work. If the agent reads the full issue, with its comments and criteria, it can propose a plan that you review before any code is touched. That shortens the path from “what needs to happen” to “how it will look,” and it makes the decision visible.
This fits the idea of agent orchestration: the backlog is the source of instructions, and the agent executes. The better the issue is written, the better the work that comes out of it.
Some uses that integration guides describe:
- Start from a ticket: read the issue and its comments and propose a plan before coding.
- Update on merge: move the ticket to review and leave a summary of the change.
- Triage: list unstarted issues in the current cycle, or those blocked by another.
- Create or edit: open issues or comments from a research finding.
For design, the most valuable use is usually the second: a clear summary of what changed and which acceptance criterion it meets, left on the ticket.
What risks does it carry, and when should you not use it?
Writes use your permissions. The agent can change what you can change, and it cannot see teams you cannot access. It is still write access.
Other points to watch:
- Unscoped requests: “show me the backlog” can fill the agent’s context and waste tokens.
- Stale data: the MCP returns snapshots; if someone changed the issue while you work, the agent does not know. Re-read before you write.
- Incomplete context: what is not written in the ticket or its comments does not reach the agent. Decisions made in Slack or in a meeting are invisible to it.
- Credentials: keep tokens out of repositories and revoke the ones you no longer use.
When NOT to use it:
- When the backlog holds confidential information that must not reach an external agent.
- When the team has no acceptance criteria: the agent will invent its own.
- When you want the agent to set priorities. That is the team’s job.
- When issues are too thin to give context: the agent will work on assumptions.
How does it apply to a project?
A cautious setup:
- Connect the MCP with read-only permissions for the first week.
- Put the acceptance criteria and the scope of the change in the ticket.
- Ask the agent for a plan, not code, and review it.
- Only when the plan is right, enable writes for the status change and the final comment.
- Review Linear’s change history after each session.
If your flow includes coding agents, also read about Claude Code or Cursor to understand where the work runs.
How to write an issue an agent can execute. An agent works only as well as the issue it receives. A simple format for design work:
- Problem: what happens today, with a quote or a screenshot.
- Expected outcome: what must be true when it finishes, in observable terms.
- Scope: which screens or components are in and which are out.
- Acceptance criteria: three to five conditions someone can check.
- References: a link to the prototype, to the design system component, and to the previous decision.
If the issue has no checkable criteria, the agent will invent them. And if it does not say what is out of scope, the change will grow out of control. Before you assign an issue to an agent, ask whether another person on the team could execute it with that information without calling you.
Example
Illustrative example: a designer has an issue “Improve the empty state for notifications” with clear criteria and a link to the prototype. He connects the MCP in read-only mode and asks his agent to read it and propose a plan using existing components. He reviews the plan, which proposes reusing the empty-state component from the design system. Then he enables writes, the agent leaves a comment with the approved plan, and moves the ticket to “In progress.”
What he learned: the short plan before coding caught that the agent wanted to create a new component when one already existed.
Common mistakes
- Granting write access from day one.
- Asking the agent for “the whole backlog” in a single query.
- Writing issues without acceptance criteria and expecting good results.
- Forgetting that the agent cannot see what was decided in Slack or in a meeting.
- Leaving active tokens on machines nobody uses anymore.