Known vs Linear

Linear is a fast, opinionated issue tracker for software teams. Known is a shared model of your company, where issues are one kind of record next to your customers, decisions and conversations. Choose Linear for a polished board, cycles and GitHub automation. Choose Known when your agents need to see why an issue exists, not just the ticket. Many teams can use both.

Facts about Linear come from Linear's own docs and pricing page, read on 27 October 2026.

When to choose Linear

• Your engineering team plans in cycles and lives on a board.
• You want pull requests to move issues automatically: Linear links branches, PRs and commits by issue ID and changes status on review and merge.
• You want notifications in an inbox, on mobile, in Slack and by email.
• You want intake from Slack, email, forms, Zendesk or Intercom (Linear's Business plan).
• You want agents in the tracker itself: in Linear you assign or delegate an issue to an agent like a teammate, and agents aren't billed as seats.

When to choose Known

• Your agents work issues and need the context around them: the customer who reported it, the decision behind it, the last call with that customer. In Known these are linked records an agent follows; in Linear they're in other tools.
• You track more than engineering work in the same place: a sales pipeline, a fundraise, hiring, all as tables with schemas you write.
• You want to define the fields yourself. Known's tables take any JSON Schema; Linear's model is fixed by design (statuses in five fixed categories, metadata through labels, priority and estimates).
• You want every change versioned with who made it, person or agent, on every plan.

Set it up in one sentence

Connect Known to your agent (Claude, ChatGPT, Cursor and others) and paste:

Known: set up issue tracking from https://github.com/future-unknown/skills/blob/main/skills/issue-tracking/SKILL.md

The agent asks which wiki to use, your issue prefix and how your team groups work, shows you what it will create, and waits for your OK. Then it creates the issues table with its schema and rules, and publishes an issues site in Known: a list and a board in your workflow's order, each issue with its links and history, updating live as people and agents change issues. The site shows issues; you change them through your agent or in Known. To set it up by hand instead, see Set up issue tracking in Known.

Side by side

	Linear	Known
What an issue is	A Linear issue in a team, project and cycle	A record in a table you define
Fields	Fixed model; labels, priority, estimates	Your schema; any fields, checked on every write
Statuses	Custom per team, in five fixed categories	An enum you define
Views	List, board, timeline (projects)	Table (sort and filter), record pages, backlinks; with the issue-tracking skill, an issues site with a list, a board, each issue's history and live updates (it shows issues; changes go through your agent or Known)
Links to other work	Projects, initiatives, related issues	Links to any record: customers, meetings, decisions, plans
GitHub	Automatic PR and commit linking and status changes	None built in; agents add commit and deploy links
Notifications	Inbox, desktop, mobile, Slack, email	None
Agents	Official MCP server; agents as assignable teammates; Linear Agent built in	MCP server for the whole wiki; agents act as the person who connected them
History	Per-issue activity; audit log on Enterprise	Every record versioned with who changed it, on every plan
Export	CSV (without attachments), Markdown, API	Records as JSON over the CLI and API

Using both

Keep the board in Linear and the context in Known. Connect both MCP servers to your agent, and ask it to read the customer and the decision in Known before it picks up the Linear issue. When it ships, it updates the Linear issue and records what happened in Known.

Moving from Linear

Set up issue tracking first, in one sentence (above). Linear exports issues as CSV, up to 250 at a time for members and 2,000 per view for admins; attachments aren't included. Give the CSV to your agent and ask it to create one record per row in your issues table, following the table's schema; they show up on the issues site as they arrive.

Sources

Linear: conceptual model, workflows, pricing, MCP, agents, GitHub, notifications, exporting. Read 27 October 2026.