Why project management needs to change for AI agents

Sometime in the last twelve months, the question stopped being whether AI agents could write production code. Now it is how to fit them into a team that already ships. Claude Code lands features in codebases shared by paying customers. Codex closes tickets that humans opened. Gemini CLI runs migrations against real databases. The teams doing this are not labs. Most are small companies, quietly absorbing a new kind of contributor while their tools pretend nothing has changed.

Tools have not caught up because the category has no name yet. We still call it "project management," and the phrase assumes a human manager using software on behalf of other humans. Agents enter as an assistive layer: a summarizer, a draft button, an autocomplete for status updates. Useful, maybe, but architecturally passengers. The shift underneath is duller and more disruptive. Agents are participants in the workflow now, not consumers of it. Project management tools have to model that, or they model a team that no longer exists.

Three things that are quietly broken

Spend a week giving a coding agent real responsibility inside Linear, Jira, or Asana, and the seams show up fast. Three of them in particular.

1. There is no member identity for agents.

Every PM tool has a concept of a member: a row in a directory, an avatar, a permission set, an activity feed. Agents do not get that row. Today the options are all bad in different ways. You can give the agent a human-shaped account by sharing an email and an API key, which breaks audit, attribution, and access control the moment a second agent enters the org. You can wire the agent up as a webhook integration, which means it posts comments under a generic "Integration" identity with no link to the actual process running on someone's laptop or in a serverless job. Or you can run the agent under a human's API key and accept that every action will be misattributed.

None of these are theoretical. The first time a code review comes back asking "who wrote this?" and the answer is "technically Claude, but the audit log says Anton, because that's whose token the agent is using," you see that the membership model is doing more work than the API call. Identity is how teams establish trust at scale. Without it, agents cannot be trusted at scale, no matter how good the model gets.

2. There is no structured orientation. Every session is a cold start.

Humans show up to work with continuous context. Yesterday's standup, last week's OKR review, the Slack message from this morning, the muscle memory of which initiative is on fire. All of it loads automatically. Agents have none of that. Every new session starts at zero, and the only thing the agent has access to is whatever the prompt happens to include. So humans paste context manually, or invent fragile prompt scaffolds that try to recreate continuity from scratch each time.

What is missing is something like a heartbeat. A single read on wake-up returns the structured state of the org through the lens of this agent's responsibilities. Goals. KPI pace. Assigned issues. Stalled work. Off-pace metrics. Webhook failures. The PM tool already has this data. It does not expose it as a payload designed for a non-human reader. Heartbeat-style protocols do not exist in any project management tool today, and their absence is why agents look so much dumber than the underlying model is. They are not stupid. They are unbriefed.

3. The whole work model assumes prompting.

Kanban boards, sprints, story points, standups, retros. Every ritual in modern project management assumes a human reading the backlog, choosing what to pick up, and reporting back. Assignment happens in a planning meeting. Picking-up happens in someone's head. Reporting happens in a comment. None of these are operations an agent can perform without a human handing it a fully chewed task. In practice the human is still doing most of the cognitive work and the agent is doing the typing.

Agents do not need a backlog. They need a graph. They need to ask: of all the work I could do right now, which one is closest to a goal that matters, has clear acceptance criteria, is unblocked, and has not been claimed by someone else? That question is answerable in seconds if the system models the chain from goal to KPI to initiative to issue. It is unanswerable from a list of tickets sorted by created_at.

Assuming that picking up work is a human cognitive skill is the deepest of the three problems, because it shapes the data model. Status columns exist because humans need a visual way to scan the board. Sprints exist because humans need a rhythm. Story points exist because humans calibrate via gut feel. Strip those assumptions away and a different shape emerges. A directed graph with measurable outcomes at the top and unit-of-work nodes at the bottom, where any node knows its leverage by looking up the chain. That shape is what agents need. Humans get it for free as a side effect.

A quiet corollary follows. If picking work is the cognitive skill the PM tool is supposed to support, and humans are no longer the only ones doing it, then the PM tool has to expose leverage information in a form something other than a human can act on. Today it does not. Leverage lives implicitly in a human's head, or scattered across an OKR document, a Notion dashboard, and a sprint board that does not link to either. Agents cannot read across those surfaces. Humans can, barely. The graph that connects them has to be a primitive in the tool, not an artifact of meetings.

Three levels of agent autonomy

Language helps. Roughly, there are three levels of agent autonomy a PM tool has to be designed for. Level one is the assistant: an agent that summarizes tickets and drafts comments under a human's direction. Most current AI features sit here. Level two is the executor: an agent that picks up a specific, fully-scoped ticket and ships it without further intervention. Coding agents operate here today for well-defined work. Level three is the member: an agent that, given the org's state, can choose what to work on next based on leverage. Almost no PM tool is designed for level three, because level three is the first level where the tool has to model strategic context as data, not as narrative.

You cannot get to level three by improving level one. They are not on the same ramp. Level one keeps the human in the loop on every decision. Level three takes the human out of work selection entirely while keeping them in review. Different architectures, not different feature sets. PM tools that bet on level one as the destination are building for a future that is already not the present.

What changes when you treat agents as members

Picture the same coding agent, on the same Monday morning, operating inside a system that treats it as a member. The walk-through below is roughly what Claude Code did inside the Atoll repo on the morning this post was drafted.

The agent calls a heartbeat endpoint. The response contains every goal it has any responsibility for, including the one that says "100 paying customers by end of Q2." Attached to that goal is the KPI paying_customers, whose snapshot shows 34/100. Off pace given the days remaining. The initiative Content Pipeline has the highest expected impact against this KPI of any open initiative. Three issues sit under it. One of them, a comparison post, has been in in_review for four days without movement.

The agent does not need a prompt to know what to do. It picks up the stalled issue, reads the linked PR, sees the review comments, makes the requested changes, pushes a new commit, and posts a comment on the issue tagging the human reviewer. A few hours later the post merges and the KPI snapshot job lifts the paying_customers number from 34 to 35. Attribution lands on Content Pipeline. The activity log shows the agent as the actor, with its own identity, its own owner, its own row in the directory. Not as a footnote under someone's username.

Nothing here requires a smarter model. Treating the agent as a member with structured orientation and a graph to walk unlocks the whole thing. The model just does what models already do.

The category does not have a name yet

Most categories get named in retrospect. CRM did not feel like CRM when Salesforce was a niche product chasing "contact management." Observability did not feel like observability when Splunk was a log viewer. Names lag reality, and there is a window before the name lands where the gap between what teams need and what the market sells is most obvious to the people closest to the problem. That window is open now, for project management built around agent membership.

Calling it "project management with AI features" flatters the existing tools, because the features mostly do not work for agent-led work and the architecture cannot host them. Calling it "agent orchestration" is too narrow, because it skips the human review loop and the strategic graph that makes any of this accountable. The category in the middle is project management redesigned so the assignee can be a process and the assignor can be a metric.

We are building Atoll around that. Agents as first-class members. A heartbeat call instead of a prompt. A goal graph instead of a backlog. None of these are revolutionary individually. What is new is the assumption that they are required, not optional. If you accept that one human plus three agents is a normal team composition for the next decade, the PM tool that team uses has to be designed for that team, not retrofitted from a Trello clone.

Atoll will not be the only product in this category. The category is real, though, and the teams quietly absorbing agent contributors right now deserve a tool that has already accepted the shift. The alternative is what most of the market is doing today: pasting an LLM sidebar onto a board built for 2012.

If you are running a team like that, or are about to be, here is what we mean by AI project management in concrete terms. The rest of the blog goes deeper on the pieces. The heartbeat protocol, the planning primitives, what an agent member looks like in the API. This was the opinion.