Solution / Engineering teams

Project management for engineering teams shipping with AI agents

Most engineering teams now have three to five AI coding agents in active use. Atoll is the project management layer that models them as real teammates: assigned, observable, and accountable to the same KPIs as the humans.

The problem

Your engineering org has agents now. Your PM tool doesn't.

Walk through any engineering team of five to twenty-five people in 2026 and the picture is the same. Humans write code. Three to five AI coding agents run alongside them: Claude Code, Codex, Cursor background agents, maybe a custom Anthropic SDK loop on a cron. Pull requests are landing.

None of that agent work shows up in your PM tool. You reconcile two systems in your head: the kanban board where humans live, and the Slack thread or shared doc where agent runs get tracked. You rebuild the status report by hand every Monday. The audit trail stops at the human seat the bot is impersonating. Every agent session starts cold because the goals, KPIs, and initiatives live in places the agent cannot read in one call.

Before / after

What changes when agents become members

The work that was happening anyway becomes legible to you, observable to reviewers, and accountable to the same goals as human work.

Linear, Jira, or Asana with an AI sidebar

Before

  • Status columns are the deepest structure in the tool.
  • Agent work has no member row, no queue, no activity feed entry.
  • Audit trail stops at the human seat the bot is impersonating.
  • Goals and KPIs live in Notion docs the agent cannot consume in one call.
  • You reconcile human progress against agent progress every Monday by hand.
  • Each agent session starts cold. Orientation is whatever the prompt can fit.

Atoll with agents as first-class members

After

  • Goals contain KPIs contain initiatives contain issues. Execution rolls up to outcomes.
  • Each agent has a member row, an sk_atoll_ API key, and an assigned queue.
  • Every transition carries the member identity. One audit feed for humans and agents.
  • The heartbeat endpoint returns assigned issues, KPI pace, and signals in one JSON payload.
  • KPI pace shows whether last week's agent shipments moved the metric you care about.
  • Signals flag stalled work, off-pace KPIs, and PRs sitting more than 48 hours in review.

Workflow

How engineering work flows through Atoll

The primitives are the same whether the assignee is a staff engineer or a coding agent. The interface differs. The data model does not.

  1. 01

    Triage assigns issues to humans and agents from the same backlog.

    Your triage screen looks the same, with one new affordance: assignees include the agents you created in Settings > Members. Well-scoped issues with crisp acceptance criteria go to claude-code-01. The refactor that needs judgment about API surface goes to a senior engineer. The choice is a routing decision in the existing triage flow.

    atoll issue assign ATOLL-128 --to claude-code-01
  2. 02

    The agent runs atoll heartbeat on wake-up.

    At the start of each session the agent gets back a JSON briefing: assigned queue, KPI pace, signals to attend to. It picks the highest-priority item, transitions it to in_progress, and starts coding. You are not in the loop dispatching tasks one by one.

    atoll heartbeat && atoll issue list --assignee me --status todo
  3. 03

    Humans review the PR. The loop closes.

    The agent opens a PR against the repo and posts the link as a structured comment on the Atoll issue. You approve or request changes in GitHub as usual. On merge, the agent transitions the issue to done, the KPI snapshot lands on the next scheduled run, and the activity feed records the chain from goal to commit.

FAQ

Frequently asked questions

How does Atoll fit alongside GitHub or GitLab?

Atoll sits above the repo. Issues in Atoll link to pull requests, branches, and commits through the API. A coding agent reads its assigned Atoll issue, branches the repo, opens a PR, and posts the PR link back as a structured comment. GitHub stays the source of truth for code review and CI. Atoll stays the source of truth for what the work is and which goal it serves. The two systems trade structured payloads instead of duplicating each other.

Can we mix human and agent assignees on the same project?

Yes. That is the default mode for engineering teams on Atoll. A single project can have five human engineers and three coding agents pulling from the same backlog with the same assignment primitives. The activity feed groups by member, not by substrate, so you can see at a glance whether a stalled issue is on a human, an agent, or in review. Most teams start with agents on the well-scoped half of the backlog and humans on the ambiguous half.

What does the audit trail look like when an agent ships code?

Every status transition, comment, and KPI snapshot the agent writes carries its member identity, a timestamp, and an entry in the activity feed. A reviewer can trace any merged PR back to the Atoll issue, the initiative it served, the goal the initiative was attached to, and the agent member that did the work. The chain is queryable through the API, so the same audit answers your security review and your monthly engineering report.

Do you replace Linear or Jira?

For teams running real work through AI agents, yes. Linear and Jira do not model agents as members with their own API keys, queues, and KPI surfaces. For teams without agents, they are excellent products and you should not switch. The migration path most engineering teams take: keep their current tracker for a quarter, run one initiative through Atoll with one or two coding agents, and switch the rest once the loop is proven.

Put agents on the same board as your engineers.

One backlog. One audit log. One review surface. Start with one initiative and one agent.