LINEAR put a Slack agent in front of Linear data so users can create issues and ask workspace questions without leaving Slack.
2
Providing a small amount of nearby Slack context worked better than giving the agent broad access to the full conversation history.
3
The agent handles summaries and titles, while application code handles fixed business rules, data shaping, and formatting.
Summary
Kristin Boyer describes how LINEAR experiments with AI features and focuses on a Slack-integrated Linear agent. The agent lets users ask questions about their workspace and create issues from Slack threads. The team found that giving an agent too much Slack and Linear data made it less reliable, so they provide nearby messages, preserve thread continuity, and pass along the relevant Linear entity. They also route requests early, separating issue creation from other tasks. For issue creation, the agent is given a narrow prompt and is allowed to summarize the thread into a title and description. Users preferred reviewing and editing the first result over confirming every field through a conversation. LINEAR keeps fixed business logic in program code, including team selection, while the model handles work that benefits from language understanding. Boyer closes with open questions about research workflows, response speed, and how to present longer agent activity inside Slack.
LINEAR puts the agent inside Slack so users can work with Linear data without switching tools
The project started from where users already communicate: Slack. The agent can answer questions about a workspace and create issues from Slack threads. In the example, it reads a thread about product capabilities, turns the request into an issue, and assigns it to the engineer who initiated the request. Boyer says the team wanted users to interact with their Linear data without leaving Slack, even though Slack offers fewer interaction surfaces than a product the team controls directly.
A small amount of nearby conversation context worked better than unrestricted history search
The team initially gave the agent a tool for searching Slack history and instructed it to use that context. It followed the instruction most of the time, but sometimes read only the current message and made a decision. Boyer says most requests were scoped to a local part of a thread, so LINEAR began with about 10 messages and treated the current request as the next message. That removed the need to search history in most cases, while leaving the full-history tool available when needed.
The agent needs continuity and a small amount of invocation context
A Slack thread can mention Linear, continue with a short exchange, and mention the agent again later. The team wanted the agent to retain that thread history as though it had been present throughout. They also pass along the ID of the issue, project, or initiative connected to the Slack thread. Boyer says those entities provide enough context for the agent to use other tools for data aggregation and research without receiving the entire surrounding system.
Early request routing reduces prompt size and prevents unrelated tool calls
The original setup gave one agent tools for issue creation, data lookup, and search. When asked to create an issue, it sometimes searched for arbitrary information to fill in fields. LINEAR added an early decision that separates issue creation from other requests, using a small model for that classification. The issue path then needs less system-prompt guidance. Boyer says this produced higher issue-creation accuracy and faster responses because the agent made fewer unrelated tool attempts.
Users preferred a useful first draft over repeated confirmation
The team first asked for confirmation after a user requested an issue, including checking every field. Internal users disliked the back-and-forth and wanted to review a first attempt themselves. The approach worked because the agent was generally right about the main details, especially when it summarized the thread into a title and description. Users could then change a priority or assignee. Boyer presents this as a practical division of labor between generated content and human edits.
Application code should handle fixed business rules and difficult data shapes
Boyer says LINEAR spent too much time trying to make the model understand complex schemas and fixed workflow rules. The team moved preprocessing and postprocessing into code. For example, choosing a default team can depend on project membership and issue counts, but the expected fallback is known programmatically. The model is told to fill fields only when it is certain or when it has been asked to summarize. Titles and descriptions are suitable model tasks, while stable business logic stays outside the model.
Returning simple structured data makes formatting faster and more predictable
Formatting instructions created another source of unnecessary difficulty. Boyer gives the example of wanting a bulleted list except when there is only one item, in which case the result should be a sentence. Instead of making the model produce the final presentation, LINEAR can ask it for an array of ideas and format that output in code. This reduced the team's effort and sped up the process.
The team is still balancing agent depth with Slack's expectation of speed
Future experiments may involve web research for product requirement documents and other longer workflows. Boyer says those sources could change how the agent behaves and raise a presentation problem inside Slack. Users expect quick responses, but an agentic workflow may take longer and need visible progress. The team is still deciding when to favor speed, when to run a longer workflow, and how to show that activity without sending users to another tool.
"Titles, descriptions, those are great things for the LLM to do. Very specific business logic that doesn't change, that's something that we would want to handle on our own."Kristin Boyer13:08
Who should watch
You are putting an AI assistant into Slack and need to decide how much thread history and workspace context to provide.
Your agent creates records with fields governed by fixed business rules, and you are seeing unnecessary tool calls or incorrect defaults.
You are deciding whether users should confirm every generated field or review and edit a first draft.
