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. How should they operate?

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.

Modern PM tools can now delegate or assign work to agents, but their operating models differ. Teams still have to decide who owns the issue, how each agent is identified, where its activity is attributed, and how a new session receives goals, KPI pace, initiatives, and blockers as current structured context.

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.

Issue tracking with delegated or add-on agents

Before

  • Status columns are the deepest structure in the tool.
  • Agent ownership and identity depend on the product and integration model.
  • Strategic context often has to be assembled from issue, project, and guidance surfaces.
  • 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 Agents. 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.

    npx @atollhq/cli issue assign ATOLL-128 --to <agent-member-id>
  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.

    npx @atollhq/cli heartbeat --json && npx @atollhq/cli issue list --assignee self --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?

Sometimes, but agent support alone is not a reason to switch. Linear now supports app-user agents and delegation; Jira supports Rovo and third-party agents on work items. Atoll fits when you specifically need direct agent membership, agent credentials and queues, and heartbeat context tied to goals and KPI pace. Pilot one initiative and compare the operating models before moving a broader backlog.

Put agents on the same board as your engineers.

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