AI-generated summary of Linear for Agents - Developer Session, Linear. Not written or verified by the author.
Takeaways: Linear for Agents - Developer Session
2026-11-04 · Source: Linear for Agents- Developer Session.srt (auto-captions, so names and terms may be misheard) · Linear, event page https://luma.com/ikff9tvq. Session date not stated in the transcript or on the event page.
Gist
Linear's beta webinar for developers building agents on the Linear for Agents API. Tom, the project's engineering lead, demos the Codegen agent turning an issue into a PR, then covers the API surface, best practices from about six weeks of beta use, and ideas under exploration. Lena (community lead) moderates and Leela (engineer) joins the Q&A. The pitch: agents are workspace members you can mention, assign, and collaborate with like a teammate.
Beta, no results reported. No adoption, quality, or usage numbers. The demo is one simple issue ("we really want the button to be blue"). Roadmap items are ideas Tom says may not "come to fruition." Everything below is the speakers' claim, not checked here.
Takeaways
- Agents are real users. Installed by an admin, managed by all admins. They get user pages listing assigned work, and views can filter on agent users "to create insights into how these things are working for your team."
- Parallel and competing work. Nothing stops you assigning 10 issues at once, or mentioning several agents on one issue to "have them all compete" and pick the best.
API surface
- Agents are still OAuth apps. Pass
actor=appat authorization; the admin then picks which teams the app can reach. Start with one team, widen access "as you gain confidence." - Two new scopes,
app:mentionableandapp:assignable, so an app can be mentionable without being assignable. Exact scope spelling not checked. - Two new webhooks: inbox notifications (mentions, replies in threads the agent is in) and permission changes. Admins can add or remove teams any time, so don't assume access is stable.
- Each install creates a user with its own ID per workspace, distinct from the OAuth app ID and client ID. Query
viewer { id }with the app token and store it. - Don't detect mentions by username. Human-like names clash and get changed on install, and admins can rename agents. Use the ID.
- Everything goes through the GraphQL API: "anything that is available as a GraphQL mutation today... an agent can do." Two limits: no signing in to the UI (no Puppeteer clicking), no admin tasks like inviting users or changing workspace settings.
- Rate limits match other users, counted per token, so per workspace, not per OAuth app.
- Webhooks need public HTTPS. Local LLMs need a cloud proxy; use a tunnel in development (captions say "Enro", likely ngrok). Linear uses Cloudflare Workers, which deploy "in like 20 seconds." Tom says the plumbing is "still only a few hundred lines of code."
Best practices from the beta
- Respond in first person. The UI will still mark it as an AI.
- Acknowledge at once. Codegen reacts with an emoji on the triggering comment.
- Answer "help" with what the agent can do, since "discoverability of what they're capable of can be a little tricky."
- When work starts, move the issue to In Progress: "take kind of control of the issue." Users "have expectations about how linear functions."
- Coding agents get Git automations free by putting the issue identifier in the branch name or PR title.
- When work ends, update the status and comment so the user gets notified.
- Use collapsible markdown sections to tuck away detail, or "stuff that they were maybe less sure about."
- On failure, comment with an apology and a retry or support pointer. Tom calls this "okay for now."
Ideas beyond reactive agents
- Proactive agents listening to all comments, e.g. creating an issue when someone says "let's create an issue for that." Target: "any kind of like busy work."
- An agent as project lead that keeps a project's RFC current from meeting notes.
- A research agent inside an issue leaves its reasoning in the issue history, so teammates "see how you got to the conclusion."
- Gap: no team- or project-level comments, so cycle-to-project-completion agents lack a natural kickoff surface.
Under exploration (not shipped)
- Showing an agent's thinking steps and tool use inside Linear, optional to expand, visible to everyone, easier to interrupt, and consistent across agents.
- Explicit streaming APIs for agent progress. No live cursors, but API edits to descriptions and documents merge with live sessions.
- Delegation: assigning to an agent loses "which human is ultimately responsible." The idea keeps a human assignee who delegates part of the work to an agent.
- An SDK that hides webhook plumbing (instantiate a class, respond to events), and a Cloudflare starter repo for internal agents.
Directory and trust
- Low bar to list in the directory, high bar for Linear to promote. Tom's test: a "true agentic loop" with tools. Keyword matching "is kind of like Slack 2015."
- To be listed as an agent, not a plain integration, it must be both assignable and mentionable.
- No security or compliance requirements from Linear. Installing is "at your own risk"; vet each agent yourself.
- Auto-merge after agent review: possible, but Tom would keep "a human in the loop."
- "How do agents follow the Linear Method?" The API only exposes things that are part of it, so "it's by default."
Patterns
- make the automated actor a peer so existing tools apply unchanged ← "like any other member of the team"
- widen an actor's permissions as trust grows ← "as you gain confidence with it"
- key on stable IDs, never on display names ← "you can't rely on the username"
- acknowledge a request at once, before the slow work ← "just to let us know"
- move visible state when work starts and ends ← "take kind of control of the issue"
- delegating work must keep one accountable human ← "which human is ultimately responsible"
- the interface's limits enforce the method ← "only expose things in our API"
- leave reasoning where the team works, not in private tools ← "see how you got to the conclusion"