Connect your workspace and a new issue can start an agent that implements it. Inside the session the agent reads and writes Linear directly, so it pulls the issue, comments its progress, and moves the status without a human relaying anything.
One trigger block and a filed issue becomes a running agent. The ticket your team already wrote is the prompt, so nobody translates a description into instructions before the work can begin.
trigger: type: react linear_issue: on: [opened]The linear_issue trigger, in the agent's own config
The agent reads the issue, works the problem in its own sandbox, opens a pull request linked back to the ticket, and comments what it did. The issue moves because the agent moved it, not because someone remembered to.
The issue, the change, and the status stay in step
Linear is not just the trigger. Any session on a connected account can read issues and comments, update fields, move statuses, and file new issues, so a nightly audit lands in your backlog instead of a log nobody opens.
Issues, comments, statuses, projects, and people
One authorization covers the trigger, the mentions, and the tools agents use to write back.
Authorize Ellipsis in Linear and you are connected. It acts as its own application user, so everything it posts is attributed to Ellipsis, not to you.
Every team is enabled at connect time, and the same page toggles which teams Ellipsis interacts with.
A linear_issue react trigger starts an agent when an issue is created. That is the whole trigger vocabulary today.
The trigger takes a for: selector, so an agent can react only to issues from certain accounts.
The agent gets the title, description, labels, and team without anyone rewriting the ticket into instructions.
A comment leading with @ellipsis starts or continues a durable conversation on that issue. Ask why something behaves the way it does, or tell it to fix what the issue describes.
The comment must lead with the mention, so a mirrored GitHub thread never summons Ellipsis twice.
Sessions get Linear tools: read issues and comments, create issues, update fields, and move status.
The same tool set reaches projects, cycles, milestones, labels, documents, and users, not just issues.
A cron agent can open Linear issues for what it finds, so a nightly audit lands in the backlog instead of a log file.
Linear tools reach every session by default; an account setting can limit them to the agents that ask for them in their config.
The agent opens its pull request on GitHub and links it to the issue, so the ticket and the change reference each other.