Hamloy vs Linear

When to choose which

Choose Linear when a team plans and tracks product work: issues that outlive any one session, projects with milestones, cycles, triage, and a record people outside engineering read. Linear also lets you hand a whole issue to an agent that works on it elsewhere and comes back with a pull request. Linear's free plan takes 250 issues and 2 teams; paid plans start at $10 per user a month, billed yearly (pricing).

Choose Hamloy when the work happens in agents on your own machine, often several at once, and the list changes every few minutes: an agent adds the plan, claims a step, asks you something, ticks it, and the next session picks up where it stopped. That is a working list, not a plan of record, and it would be noise in a team's tracker.

Use both when you have a team in Linear and run agents yourself. See "Using them together" below.

What Linear does

From Linear's own site, read on 10 October 2026:

• An MCP server at https://mcp.linear.app/mcp, with tools for "finding, creating, and updating objects in Linear like issues, projects, and comments". Its page lists Claude, Claude Code, Codex, Cursor, VS Code, Windsurf and Zed, among others, and signs in with OAuth (Linear MCP).
• Agents as members of the workspace. You assign or @mention an agent on an issue, and it works on it; Linear says "delegate issues, but not accountability", and the person stays the issue's assignee. It names Cursor, Codex, Devin, Sentry and others, and agents don't count as billable seats (Agents, Agents in Linear).
• An agent can ask you. Inside an agent's session, it can request clarification or confirmation, and your reply goes back to it (agent interaction).
• GitHub. A branch named with the issue's ID links it; by default an issue moves to In Progress when its pull request opens and to Done when it merges, and each team can set its own rules (GitHub integration).
• Its own agent, Linear Agent, which answers questions about your issues and code, writes issues, and on paid plans can start a coding session that returns a draft pull request (Linear Agent).

We found nothing in Linear's agent docs about stopping two agents from working on the same issue at once.

What Hamloy does

Hamloy is one project's lists (tasks, requests and questions) that every agent on it calls through the same tools. A task is claimed before it's started, and the claim holds across tools:

What's yours to decide comes as a question with options and the one the agent recommends. It sits in Questions, not in a session, so you can answer it tomorrow from your phone, and whichever agent is working then carries on:

What only you can do (an account, a key, a deploy) goes on Requests with the exact steps, and the board shows which tasks wait on it (requests). Hamloy follows each task through git: ticked on a branch, merged on one computer, and pushed are three states the board tells apart (git).

Using them together

Linear and Hamloy don't connect to each other; your agent connects to both. A way that works:

1. The issue lives in Linear: "Offline sync" in this cycle, assigned to you.
2. You start a Claude Code session on it, on the branch Linear's "Copy git branch name" gives, so the pull request moves the issue for you.
3. The agent writes the plan into Hamloy as tasks under a heading named after the issue, claims the first, and asks you the open decisions as questions.
4. A second session, or Codex, takes the next ready task; neither takes the other's.
5. When the branch merges, Linear marks the issue Done, and Hamloy shows every task on that branch as merged.

Linear keeps what the team planned; Hamloy keeps the agents' steps, which only you and your agents need to see. With both servers connected, ask your agent to put the Linear issue's ID in the heading or a task's notes, so either side leads to the other.

Moving issues over

With Linear's MCP server and Hamloy both connected, ask your agent to bring a project's issues in. It reads them from Linear and brings them in one import: a heading for each project or cycle, open issues as tasks, done ones done, sub-issues as subtasks, and what blocks what as what waits on what. Bring them in again later and what the list already has by title is left out.