lanework/research/06-agents-and-tasks.md

# The AI-Agent + Task-Management Intersection

This document covers the segment Lanework's core bet actually lives in: how AI coding agents (Claude Code, Cursor, Codex, Copilot, Devin, aider) currently consume and update task/project state, the purpose-built tools emerging to serve that need, how mainstream trackers (Linear, GitHub, Jira/Atlassian, Notion) are courting agents, the multi-agent orchestration UIs that visualize agent work as boards, developer sentiment on the files-vs-API debate, and where the gaps sit for a human-grade native UI over agent-readable files.
Researched: 2026-08-01

## How agents are given task lists and project state today

- **Ad hoc markdown files (the default, no tooling required).** The most common pattern is still a plain `TODO.md`, `PLAN.md`, or `ROADMAP.md` at the repo root that a human or the agent itself writes and updates; Claude Code and similar tools read/edit it like any other file. Workflows described in the wild: "keep your tasks in a simple markdown file (todo.md) and let Claude Code implement them automatically," or a `ROADMAP.md` that gets updated as part of a "study codebase → update roadmap → do priority task" loop. Zero adoption friction (every agent already reads files) is the appeal; the cost is no structure — no dependencies, no status enum, no ownership, easy for the file to drift from reality across a long session.
- **AGENTS.md as the emerging cross-tool convention.** A markdown file at repo root giving agents project-specific context (build commands, conventions, architecture notes); as of 2026 it's read natively by 30+ tools including Claude Code, GitHub Copilot, Cursor, Devin, and aider. This is adjacent to task management (it's project *context*, not a task queue) but it's the closest thing to a cross-vendor standard that exists, and it establishes the pattern of "one markdown file every agent already knows to look for."
- **Claude Code's built-in TodoWrite/Tasks.** Claude Code ships a first-class in-session task list: the agent calls a `TodoWrite` tool with items carrying `content`/`activeForm`/`status` (pending/in_progress/completed), rendered live in the terminal UI so the human can see "where am I, what's next" turn to turn. As of Claude Code v2.1.16 (Jan 22, 2026) this was replaced/extended by "Tasks," which adds dependency tracking, filesystem persistence, and cross-session collaboration — i.e., Anthropic itself moved from an ephemeral in-memory todo list toward a durable, file-backed task model, which is a notable signal that even the agent vendor sees session-scoped todos as insufficient once work spans sessions.
- **Cursor / aider / Devin.** Cursor has no native task-tracker; a live "Simple Task Management" feature request thread on Cursor's community forum shows users want one and don't have it. aider is explicitly single-session/human-in-the-loop and doesn't attempt project-level task state. Devin instead plugs into whatever the team already runs — hand it a Jira ticket, bug report, or feature request and it manages that item's lifecycle, and teams can assign it 10 independent tickets to work in parallel sandboxes; Devin's task management is thus outsourced entirely to the host tracker rather than built in.
- **MCP servers as the connective tissue.** Rather than each agent vendor building tracker integrations one-by-one, the Model Context Protocol (MCP) has become the standard plug for wiring an agent to whatever tracker a team already uses — GitHub, Linear, Jira/Confluence, Notion all now ship official remote MCP servers (see below). This is the mechanism, not a tool in itself, but it's the dominant one as of 2026.
- **MCP Tasks extension (protocol-level, not tool-level).** The MCP spec itself added a Tasks extension formalizing a small state machine for long-running work — `working` / `input_required` / `completed` / `failed` / `cancelled` — with durable task IDs, polling, and TTL/poll-interval metadata, so a tool call that takes minutes or needs human approval doesn't require holding a connection open. It's infrastructure for async tool calls, not a project-management surface, but it shows the protocol layer itself is growing native task/state vocabulary.

## Purpose-built agent task tools

- **[Beads](https://github.com/steveyegge/beads) (steveyegge/beads).** A distributed, git-backed issue tracker built specifically to replace "messy markdown plans" with a dependency-aware graph so agents can handle long-horizon work without losing context. Storage is Dolt (a version-controlled SQL database) in embedded or server mode, with `.beads/issues.jsonl` as an export/interchange format, not the source of truth — data syncs across machines via `bd dolt push/pull` against git remotes. Dependency types include blocks, related-to, duplicates, supersedes, replies-to, and parent-child; IDs are hash-based (e.g. `bd-a1b2`) specifically to avoid merge collisions when multiple agents create issues concurrently; a "semantic compaction" feature summarizes closed tasks to conserve context windows. Created by Steve Yegge, released October 13, 2025; hit ~1,000 stars and ~50 forks in its first six days, and per a later check sits at roughly 25.8k stars / 1.7k forks — one of the fastest-growing tools in this whole space and the clearest signal of pent-up demand for "an issue tracker an agent can drive." Notably it explicitly rejects the "just use markdown" approach at scale, arguing a real dependency graph plus real merge semantics is needed once agents create issues faster than humans can triage them.
- **[Trekker](https://github.com/obsfx/trekker)** — a deliberately minimal reaction to Beads: a Claude Code plugin with a lightweight dashboard, built by a developer who used Beads, found "giving an agent a task tracker helps a lot with focus and continuity," but wanted a stripped-down alternative with fewer abstraction layers. Posted to Show HN Jan 22, 2026. Signals the space is already forking into "full dependency-graph database" vs. "minimal enough to not need one" camps.
- **[Backlog.md](https://github.com/MrLesk/Backlog.md)** — markdown-native task manager and terminal/web kanban visualizer for any git repo; explicitly "for humans and AI Agents," works with Claude Code, Gemini CLI, Codex, Kiro, and any MCP/CLI-compatible assistant. Tasks are per-file markdown (not one big TODO file) with acceptance criteria, milestones, and dependencies; ships both a CLI and an MCP server exposing task operations as typed tools ("the recommended approach for AI agents that support tool use"). 100% offline/private, git-native, no external services. Its Show HN thread (June 2025) is a good sentiment read: the creator's own success curve was 50% with docs alone → 75% with per-task markdown files → 95%+ once task generation was automated, and commenters converged on "lightweight, git-integrated markdown workflows suit AI-assisted development better than centralized platforms" — with the caveat that large markdown files blow agent context budgets, so atomic per-task files matter.
- **[claude-task-master](https://github.com/eyaltoledano/claude-task-master)** — an AI-powered task-management system dropped into Cursor, Lovable, Windsurf, Roo, etc.; parses a PRD into tasks and exposes MCP tools (`get_tasks`, `next_task`, `set_task_status`, `expand_task`, `parse_prd`, ...) in core/standard/full tool-count tiers (7/15/36 tools). One of the earliest and most-forked entries in the space (numerous community forks: vibehat/claude-task-manager, ben-vargas/ai-claude-task-master, developerz-ai's autonomous-orchestration fork, etc.) — the fork count itself is a signal of how much people want to bend this to their own workflow rather than adopt one opinionated shape.
- **Other MCP task servers**: `taskqueue-mcp` (structured task queue with optional human-approval checkpoints), Dooist (tasks carry intent/spec/desired-output/status so any session can pick one up), Tasks.md MCP server (plain-markdown Epics/Stories/Tasks/Milestones via MCP tools, no database), `madebyaris/agent-orchestration` (shared memory + task queue + resource locks for multi-agent collaboration). Long tail, mostly single-maintainer, mostly reinventing the same small set of primitives (queue, status enum, dependency edge, context blob).
- **GNAP — Git-Native Agent Protocol** ([farol-team/gnap](https://github.com/farol-team/gnap)) — an RFC-stage, zero-server coordination protocol where agents literally share a git repo as the task board: tasks live as JSON files in `board/todo/`, an agent claims one by moving it to `board/doing/`, and commits the result to `board/done/`; git history *is* the audit trail. Reference deployment: 4 agents (2 AI + 2 human) at "Farol Labs" coordinating 50+ tasks through one repo. Proposed as a bolt-on for Letta, OpenHands, Roo Code, Plandex, and others. This is the closest conceptual sibling to Lanework's own bet (state lives as files in a git-friendly tree, no server) but it's aimed at agent-to-agent coordination with no human-facing UI at all — it's infrastructure, not a surface.

## How mainstream trackers are courting agents

- **Linear.** Hosted MCP server (`mcp.linear.app`, built with Cloudflare + Anthropic) launched May 2025, covering every issue/project/cycle/comment/attachment the authorizing user can read; a Feb 2026 update added initiatives, milestones, and project updates/labels. As of April 23, 2026, "Linear Agent" can itself connect out to other tools via MCP, i.e. Linear moved from *being* an MCP target to *hosting* agents that call other MCP servers. Linear also became the standout proof point for "tracker as agent control plane": **OpenAI's Symphony** (open-sourced, openai.com/index/open-source-codex-orchestration-symphony) is a spec that turns a Linear board into the control plane for Codex — agents pull issues from "Todo," move them to "In Progress," open a PR and move to "In Review" on completion, and GitHub webhooks close the issue when the PR merges. OpenAI reported internal teams saw a **500% increase in landed pull requests** after adopting this pattern, with the caveat that the constraint became "humans writing executable tickets," not agent capability. This is arguably the single strongest piece of evidence in this whole research pass that structured, stateful trackers (vs. raw chat/markdown) meaningfully unlock agent throughput at scale — and that a *board with real states*, not a to-do list, is what did it.
- **GitHub.** Two tracks: (1) **Copilot coding agent** — assign it a GitHub Issue and it works autonomously in an Actions-powered sandbox, iterating through test failures and opening a PR for review with no further prompting; GA by 2026, used by ~90% of Fortune 100, Copilot overall at 20M users / 4.7M paid (+75% YoY as of Jan 2026). (2) **GitHub Agentic Workflows** (`github.github.io/gh-aw`) — repo automation written in plain Markdown that runs Copilot/Claude Code/Codex/Gemini inside Actions with sandboxed, read-only-by-default execution (e.g. an issue-triage workflow that labels and comments on new issues); and GitHub Projects now surfaces agent sessions directly in table/board views so a maintainer can see at a glance which items have an attached agent session and its status. GitHub's official `github-mcp-server` (19.9k+ stars) is the other half — issue/PR CRUD, repo search, and triage exposed as MCP tools for any client.
- **Jira / Atlassian (Rovo).** Rovo agents reached GA in Jira in 2026 — can be assigned work, @-mentioned in comments, and embedded in workflows, operating across Jira, Confluence, JSM, and 50+ connected apps (Slack, Drive, GitHub, Salesforce, Notion). Atlassian shipped an official remote MCP server (`atlassian/atlassian-mcp-server`, OAuth 2.1, built on Cloudflare's Agents SDK with Anthropic) connecting Jira/Confluence/JSM/Bitbucket/Compass to Claude, ChatGPT, Cursor, VS Code, etc. Framing at Atlassian Team '26 (May 2026, Anaheim) was explicit: AI moving "from assistance to active participation."
- **Notion.** Hosted MCP server (18 tools: search, page CRUD, database creation, comments, users) plus page content exposed as enhanced Markdown (`retrieve-page-markdown` / `update-page-markdown`) — notable because it means Notion, a database-backed product, deliberately presents itself to agents *as if* it were a markdown file store, echoing the "virtual filesystem" pattern seen elsewhere (see Files vs. API below). Notion Custom Agents (2026) can also participate in cross-tool workflows via pre-built partner MCP integrations (Linear, Figma, HubSpot) or custom servers.
- Pattern across all four: every major mainstream tracker independently converged on the same shape in the last ~12 months — official hosted MCP server + agents that can be assigned/mentioned/take actions inside the existing board — meaning "give the agent API access to our tracker" is now table stakes, not a differentiator. The differentiator is what happens on top (see Gaps, below).

## Multi-agent orchestration UIs

A genuinely dense cluster of tools now visualizes parallel-running coding agents as a board or queue — this is the segment closest to Lanework's own UI concept, though none of them treat the board itself as a portable, human-editable file tree the way Lanework does.

- **[Conductor](https://conductor.build)** (Melty Labs, YC S24) — free native Mac app; each new "workspace" runs `git worktree add` and starts Claude Code or Codex inside it, fully isolated; features include Checkpoints (rollback snapshots), Spotlight testing (sync a workspace's changes back to main for testing), and multi-model mode (run Claude and Codex on the same prompt side by side). Used by engineers at Linear, Vercel, Notion, Stripe, Life360 per its marketing. No plain-file board — the workspace list is the "board," implicitly, not a kanban.
- **Crystal → Nimbalyst** ([stravu/crystal](https://github.com/stravu/crystal), now deprecated/renamed) and **crystl** (a macOS-native Swift rewrite using Keychain, throttled off-screen rendering) — Electron/native apps for running multiple Claude Code/Codex sessions in parallel git worktrees, session-per-tab rather than card-per-task.
- **[Vibe Kanban](https://github.com/BloopAI/vibe-kanban)** — an open-source kanban board purpose-built for AI coding agents (Claude Code, Codex); each card is an agent task, parallel execution runs each in an isolated git worktree, one-click dev-server startup per card. Reported figures vary by snapshot but land around 8-9k GitHub stars, making it one of the most-starred tools in this whole document. Notably its creator (Bloop) shut down in April 2026 and the project transitioned to community maintenance — a caution flag that "hot open-source agent tool" and "sustainable business" are not the same thing yet in this space.
- **[Kanban Code](https://github.com/langwatch/kanban-code)** (LangWatch) — the closest direct conceptual neighbor to Lanework found in this research. Native macOS (SwiftUI, "liquid glass") + Windows (Tauri) app whose stated goal is "easing the context-switching bottleneck ... by centralizing all context needed for each Claude session into their cards." Each kanban card automatically links a Claude Code session, a git worktree, a tmux terminal, and a GitHub PR, flowing through Backlog → In Progress → Waiting → In Review → Done → All Sessions. Built with a clean unidirectional-data-flow architecture (`AppState`/`Reducer`/`EffectHandler`, a separated `KanbanCodeCore` Swift library) and an embedded terminal (SwiftTerm). Storage, notably, is *not* one-file-per-card the way Lanework or Backlog.md do it — it's `~/.kanban-code/settings.json` and `~/.kanban-code/links.json` (a central "links" record) plus scanning `~/.claude/projects/` for session discovery; the board state is app-owned JSON, not a portable folder of files a human or shell script would casually edit. ~300 stars / 31 forks, AGPLv3, explicitly synthesized from five predecessor projects by the same team. This is a real existence proof that "native Mac app, kanban-as-agent-orchestrator" is a validated shape people want — but it competes on session/terminal/worktree integration, not on being a human-grade editable-files surface.
- **A long tail of similar single-purpose boards**, mostly terminal (TUI) or small web apps, all converging on the same primitive (task = card = worktree = agent session): OpenKanban (TUI, TechDufus), agent-kanban ("mission control for your AI workforce," leader agent plans/assigns, workers claim and ship PRs), ai-agent-board (DanWahlin, drag-and-drop, multi-engine: Copilot/Claude/Codex/OpenCode), Cline's built-in `cline --kanban`, opencode-kanban (Rust TUI for OpenCode+tmux). None found with meaningful star counts beyond Vibe Kanban and Kanban Code; this is a "everyone is building the same toy" moment, which usually means the primitive is right but no single implementation has won yet.
- **Google Antigravity's Agent Manager ("Mission Control")** — not a kanban board but the same underlying need from a different angle: a dedicated surface (built on VS Code, powered by Gemini 3 Pro) to spawn/monitor/coordinate multiple agents working asynchronously across workspaces, flipping the usual "agent embedded in the IDE" relationship to "IDE surfaces embedded in the agent manager." Signals that even the big-lab-built IDEs are converging on "a board of parallel agents" as the primary developer-facing surface for agentic coding, not chat.
- **Enterprise-scale orchestrators worth noting from `awesome-agent-orchestrators`**: Fusion (kanban board + plan-review-execute gates + per-task worktrees + hierarchical missions), gastown (scales to 20-30 agents with a coordinator, git-backed issue tracking, Bors-style merge queue), multi-agent-shogun (tmux orchestrator, up to 10 parallel agents, zero coordination-API cost). These lean further into "swarm ops tooling" than "human-legible board."

## Developer sentiment: files vs. API/database, and "agents need issue trackers"

- **The core discourse has a name now**: multiple 2026 pieces frame it explicitly as "issue trackers as AI agent infrastructure" — the argument (from MindStudio, Nate B. Jones, and others covering Symphony) is that issue trackers already encode most of what an autonomous agent needs structurally: state, ownership, permission hierarchies, immutable history — things a raw chat context or a loose markdown file don't durably have. "A conversation has no durable state outside the context window" is the recurring one-liner.
- **Filesystem vs. API vs. database is being explicitly litigated**, not just assumed. An Arize engineering piece ("AI Agent Interfaces in 2026: Filesystem vs API vs Database") lands on: filesystems win as an *interface* not because they're theoretically best but because "everything else is worse" — agents have massive pretraining on bash/file operations, so a filesystem needs no schema explanation, while APIs burn context explaining endpoints and databases require query languages agents use less fluently. Its tradeoff table: filesystem = familiar but reinvents search/locking/validation poorly at scale; API = better for humans, context-expensive for agents; database = proper persistence/query but unfamiliar query surface. The resolving pattern it documents is a **"virtual filesystem"**: store data in a real database but expose it to the agent *as if* it were files (LangSmith is cited as doing this) — which is precisely what Notion's MCP server does by exposing pages as "enhanced Markdown" rather than raw JSON, and arguably what Backlog.md's MCP server does the other direction (real files, but with a typed-tool API layered on top for agents that prefer tool calls over `cat`/`grep`).
- **The Backlog.md and Beads reception both point the same direction**: plain markdown works great until (a) files get large enough to blow context budgets, or (b) multiple agents/humans are creating and closing issues fast enough that merge conflicts and lost updates start to matter — at which point people reach for atomic per-task files (Backlog.md's fix) or a real dependency graph with conflict-safe IDs (Beads' fix). Nobody in this research surfaced a strong voice arguing markdown-only *doesn't* scale to a single dev/small team; the scaling concern is specifically multi-agent-concurrent-writers and long-horizon-context.
- **Show HN threads as a sentiment proxy**: Trekker's post ("giving an agent a task tracker helps a lot with focus and continuity" — then building a *simpler* tool than Beads because Beads had drifted from what the poster actually needed) and Mission Control's post (commenters pushing on task provenance/auditability, and flagging that "agent completed the task correctly but solved the wrong problem" is a live failure mode current tools don't self-detect) both show a builder community actively iterating on primitives, not settled on one winner.
- **No one is defending Jira/enterprise-tracker UX on the merits for agent-driven work** in anything surfaced here — Jira/Linear/GitHub win this discourse specifically *because* they already have durable structured state and audit trails, not because their UI is considered good for the job; several pieces (and the Backlog.md thread) explicitly note enterprise users still want a *bridge* to Jira rather than abandoning file-based local tools, suggesting the two aren't seen as mutually exclusive.

## Gaps: what's missing

- **No one treats the board as a portable, human-editable file tree.** Every mainstream tracker (Linear/GitHub/Jira/Notion) exposes agent access via API/MCP over a server-owned database; every native-feeling orchestration UI found (Kanban Code, Conductor, Crystal, Vibe Kanban) stores its own state as app-owned JSON/SQLite, not as a folder of files a human could open in Finder, diff in git, or grep from a shell script independent of the app. Lanework's literal "boards are folders and Markdown files on disk" is not the pattern any competitor in this specific intersection actually ships, despite GNAP and Backlog.md gesturing at the same philosophy from the tooling/CLI side.
- **The CLI/MCP tools are agent-first with weak or no human GUI**; the GUI tools (Kanban Code, Vibe Kanban, Conductor) are agent-orchestration-first with app-owned state, not a general-purpose human kanban surface that happens to also be agent-legible. Nothing found combines "genuinely good native human kanban app" with "the underlying files are the actual source of truth, and any agent/script/editor can read and write them without going through the app's API or a bundled MCP server." That combination — first-class human UI *and* first-class agent-of-any-kind substrate, at once, with neither role privileged — is the gap Lanework's bet targets, and this research pass didn't surface a direct occupant of it.
- **Multi-agent-concurrent-write safety on plain files is still unsolved-ish.** Beads' entire reason to exist is that markdown/plain-file approaches degrade once agents create/close issues fast concurrently (merge collisions, lost updates); GNAP's answer (git as the coordination bus, todo/doing/done directories) is elegant but has no human review surface at all. A native app that could make git-mediated concurrent file edits legible and safely mergeable *for a human watching a board update live* is unaddressed.
- **Provenance/audit and "did the agent actually solve the right problem" surfaced as an explicit gap** in the Mission Control HN thread — current tools track task status (done/not done) but not whether the outcome matched intent, and rely on humans to catch scope drift. A board UI that made an agent's diff/PR trivially reviewable against the original card text (which Kanban Code and Symphony both gesture toward via PR-linking, but don't make the primary UI object) is only partially built out anywhere.
- **No dominant, sticky product yet.** Every purpose-built agent task tool in this document is either brand-new (Beads: Oct 2025), community-maintained after its creator shut down (Vibe Kanban), a low-star long tail (OpenKanban, agent-kanban, ai-agent-board, Kanban Code at ~300 stars), or a spec/RFC with a single reference deployment (GNAP, Symphony). The mainstream trackers (Linear/GitHub/Jira/Notion) have won the "agents can act on our data" layer but not the "this is where humans go to see agent work as a board" layer — that layer is still up for grabs, actively being prototyped by a dozen small teams, and none has separation yet.
- **Cross-repo / cross-project agent task state** was flagged as an open problem in the Backlog.md thread (users asking how to run one backlog across separate frontend/backend repos) and isn't solved by any tool surveyed — every file-based approach here is scoped to a single git repo.

## Sources

- [Backlog.md](https://github.com/MrLesk/Backlog.md), [Backlog.md Show HN thread](https://news.ycombinator.com/item?id=44483530)
- [Beads (steveyegge/beads)](https://github.com/steveyegge/beads), [Beads Show HN](https://news.ycombinator.com/item?id=46709872), [Beads coverage, Better Stack](https://betterstack.com/community/guides/ai/beads-issue-tracker-ai-agents/)
- [Trekker](https://github.com/obsfx/trekker)
- [claude-task-master](https://github.com/eyaltoledano/claude-task-master)
- [GNAP — Git-Native Agent Protocol](https://github.com/farol-team/gnap)
- [Mission Control Show HN](https://news.ycombinator.com/item?id=47165602)
- [Linear MCP changelog](https://linear.app/changelog/2026-04-23-linear-agent-mcp-support)
- [OpenAI Symphony announcement](https://openai.com/index/open-source-codex-orchestration-symphony/), [Symphony/Linear 500% PR increase writeup](https://www.mindstudio.ai/blog/openai-symphony-spec-linear-agent-control-plane-500-percent-pr-increase)
- [GitHub MCP Server](https://github.com/github/github-mcp-server), [GitHub Agentic Workflows](https://github.github.io/gh-aw/), [Assigning issues to Copilot coding agent](https://github.blog/ai-and-ml/github-copilot/assigning-and-completing-issues-with-coding-agent-in-github-copilot/)
- [Atlassian remote MCP server](https://github.com/atlassian/atlassian-mcp-server), [Rovo agents in Jira](https://www.atlassian.com/blog/rovo/ai-agents-in-jira)
- [Notion official MCP server](https://github.com/makenotion/notion-mcp-server)
- [Claude Code Todo/Tasks docs](https://code.claude.com/docs/en/agent-sdk/todo-tracking)
- [Conductor (Melty Labs)](https://conductor.build)
- [Vibe Kanban](https://github.com/BloopAI/vibe-kanban)
- [Kanban Code (LangWatch)](https://github.com/langwatch/kanban-code)
- [awesome-agent-orchestrators](https://github.com/andyrewlee/awesome-agent-orchestrators)
- [AI Agent Interfaces in 2026: Filesystem vs API vs Database, Arize](https://arize.com/blog/agent-interfaces-in-2026-filesystem-vs-api-vs-database-what-actually-works/)
- [Google Antigravity Agent Manager](https://antigravity.google/blog/introducing-google-antigravity)
- [AGENTS.md best practices](https://www.betterclaw.io/blog/agents-md-best-practices)