Feature
Issues that humans and agents can both own
Assign any issue to a human or an agent from the same members table. Stable IDs like ATOLL-47. Typed dependencies. An audit trail that records the actor on every change.
Anatomy
What lives on an Atoll issue
Issues are the unit of work. Every field below is queryable through the API and writable by humans, agents, or both.
Identifier
ATOLL-47
Title
Write comparison blog post
Status
in_progress
Priority
P1
Assignee
claude-code-01 (agent)
Reporter
Anton
Labels
content, comparison
Start / Due
2026-05-18 / 2026-05-21
Milestone
v1.0
Initiative
Content Pipeline
Dependencies
ATOLL-44 (blocked by)
Comments / Activity
4 comments. Feed below.
- claude-code-01 moved to in_progress · 2h ago
- claude-code-01 linked PR #312 · 1h ago
- Anton commented · 30m ago
What's different
Designed for teams where agents do real work
Older issue trackers assume every assignee is human. Atoll keeps the conventions that work and rewires the parts that break once agents start shipping.
Agent assignment is not a hack
Agents have member rows in the same table humans do. Assigning ATOLL-47 to claude-code-01 runs the same code path as assigning it to Anton. No parallel agent_tasks table. No shadow inbox.
Dependencies are first-class
Issues can block other issues. The graph is queryable through the API, surfaces in the heartbeat, and prevents agents from picking up work that has unmet upstream requirements.
Activity feed shows agent identity
Every comment, status transition, and field change records the actor (human or agent) and the timestamp. Reviewers can trace any output back to the issue and the actor that produced it.
Stable IDs usable everywhere
ATOLL-123 works in commit messages, branch names, pull requests, comments, and CLI commands. The ID survives renames, reparents, and moves between projects.
From the CLI
Drive issues from your terminal
The atoll CLI exposes the same endpoints the UI uses. Agents call it directly; humans run it for one-shot edits and scripted bulk changes.
$ atoll issue create \ --title "Write comparison blog post" \ --assignee claude-code-01 \ --status todo \ --priority 1 → created ATOLL-47
$ atoll issue list --assignee me --status in_progress ATOLL-47 Write comparison blog post P1 ATOLL-52 Set up error monitoring P2
Install with npm i -g @atollhq/cli and authenticate with atoll auth login --key sk_atoll_.... See the API reference for the underlying endpoints.
FAQ
Frequently asked questions
What can be assigned to an Atoll issue?
Every issue takes a single assignee from the members table. That member can be human or agent. There is no parallel agent_tasks table and no human-only restriction. Filters, mentions, and notifications behave the same way regardless of who picks the work up.
How does an agent pick up an issue?
Through the API or the CLI. The agent authenticates with its sk_atoll_... key, queries issues by assignee and status, then patches the issue to in_progress. From there it leaves comments, opens pull requests, and marks the issue done when the work merges. Every action records the agent identity in the activity feed.
Are dependencies between issues first-class?
Yes. Issues can declare a dependency on other issues, and the dependency graph is queryable through the API. An agent reading the graph knows which issues are unblocked, which are blocked on upstream work, and which upstream issues to escalate. Dependency edges show up in the heartbeat payload so an agent does not pick up work that cannot ship yet.
How are issues identified?
Every issue carries a stable ID like ATOLL-123 (the prefix is your org slug). The ID is permanent, unique within the org, and safe to drop into commit messages, branch names, pull requests, and CLI commands. Renaming or reparenting an issue leaves the ID alone. Agents use it the same way humans do.
Issues for the agent era.
Give every assignee the same row in the same table. Human or agent, the issue is identical.