AI-first project management: when agents do the work

Gartner expects more than 40% of agentic-AI projects to be canceled by the end of 2027, on “escalating costs, unclear business value or inadequate risk controls.” Every item on that list describes the operating model around the agent, not the agent.

I build with these agents and I lead the teams they slot into. The failure pattern is the one I keep coming back to: the model is the easy part. What breaks is the work around it: who acts on the output, who checks it, who is on the hook when it is wrong. AI-first project management is the discipline of designing that loop before you scale the agents inside it.

What changes when AI agents join the team?

The unit economics of work invert. Generating a first draft — code, a deck, an analysis — falls toward zero. Confirming it is correct does not. The constraint moves from how fast your team produces to how fast it can verify, and the manager’s real job moves with it.

This is already the median team, not a future one. In Stack Overflow’s 2025 developer survey, 84% of developers use or plan to use AI tools. Gartner expects a third of enterprise applications to embed agentic AI by 2028, up from under 1% in 2024, and at least 15% of day-to-day work decisions to be made autonomously in the same window. The agents are already on the team. What is unsettled is whether you run them as a faster version of the old team, which is the standard mistake, or redesign the team around what just became scarce.

33%

Why does verification become the bottleneck?

Because agents raise output faster than they raise trust, and someone has to close that gap. The most common complaint about AI coding tools in Stack Overflow’s 2025 survey was “AI solutions that are almost right, but not quite,” cited by 66% of developers and the single biggest frustration. Almost-right is the expensive kind of wrong: it passes a glance and fails in production.

The review tax is now measured, not anecdotal. A 2026 study of 278,790 code-review conversations across 300 open-source projects put numbers on it. Human reviewers exchanged 11.8% more rounds on AI-generated code than on human-written code, and adopted AI suggestions at 16.6% against 56.5% for human reviewers. Over half of the rejected AI suggestions were either incorrect or replaced by a different fix. More output, more checking, lower yield per suggestion.

At the delivery level the same effect shows up in the numbers. Google’s 2024 DORA report, across roughly 39,000 respondents, found that a 25% increase in AI adoption was associated with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. Its own summary line: “AI does not appear to be a panacea.” The individual speeds up, the system slips: the signature of an unmanaged verification gap. Addy Osmani, who reviews this for a living at Google, names the shift plainly:

The hard part of engineering moved from writing code to deciding whether to trust it, which makes review the most leveraged skill in software right now. — Addy Osmani, Agentic Code Review

Which work should you hand an agent, and which shouldn’t you?

Match the task to the blast radius. Agents are strong where the work is well-specified and cheap to check, and weak where a mistake is quiet and expensive. Osmani’s “70% problem” captures the trap: an agent gets you “70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns,” and the last 30% is where the judgment lives.

The sorting is the manager’s call, and it turns on how contained a failure is:

Work	Hand to an agent?	Why
Boilerplate, scaffolding, docs, test stubs	Yes	low blast radius, fast to verify
Migrations, routine refactors, first-draft analysis	Yes, reviewed	mechanical, but check the edges
Business logic with real edge cases	Human-owned, agent-assisted	failures are quiet and costly
Security paths, data-model changes, API contracts	Human-owned	one silent error has a wide radius

The pattern generalizes past software. Anything with a clean spec and a cheap check is a candidate; anything where being almost-right is dangerous stays with an accountable person who uses the agent as a fast first pass. As Anthropic notes from its own systems, “most coding tasks involve fewer truly parallelizable tasks than research.” The shape of the work decides how much you can hand over.

One agent, or a team of agents?

There is no consensus to follow, so you have to choose. In the same week of June 2025, two credible labs published opposite advice. Anthropic reported that a multi-agent setup (a lead agent delegating to parallel subagents) beat a single agent by 90.2% on its internal research evaluation. Cognition, the same week, published “Don’t Build Multi-Agents.”

The disagreement is useful, because each side is right about a different kind of work:

	Multi-agent, parallel (Anthropic)	Single-threaded, linear (Cognition)
Best for	broad search, parallelizable subtasks	shared context, tight dependencies
Cost	”about 15x more tokens than chats”	one context, far cheaper
Main risk	coordination and context loss	no parallelism
The rule	value must justify the token bill	”Actions carry implicit decisions, and conflicting decisions carry bad results”

Anthropic is candid about the price: in its data, multi-agent systems use “about 15x more tokens than chats,” and token usage alone explains 80% of the performance variance. You spend your way to quality. It also flags where fan-out is the wrong tool: “some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.” Cognition’s prescription for exactly those domains is the opposite: “the simplest way to follow the principles is to just use a single-threaded linear agent” where the context stays continuous. An AI-first project manager picks the architecture that fits the work: fan out when subtasks are independent and separately checkable, stay linear when the context is shared. That is a design decision, not a trend to adopt.

The agent is a component. The team is still the product.

You do not manage a model; you redesign the loop it works inside: who receives the signal, how fast they can act, what evidence justifies the spend, who signs off. I have argued before that the distance from a demo to a shipped system is an operating model, and agents only raise the stakes on it. A Next-Best-Action score nobody is rewired to act on is a dashboard. An agent that generates code nobody has capacity to review is a faster dashboard.

Building the systems myself changes how I run them. I keep a hand-built MCP data-hub that serves governed commercial datasets into AI assistants. Architecting it directly is the quickest way I have found to feel where a promising output stops being deployable: the ungoverned data path, the silent fallback, the step no human reviews. What you ship is the team, the cadence, and the sign-off chain.

Who is accountable when an agent breaks something?

A named human owns every agent’s output. Unbounded autonomy is how you get an incident with nobody clearly on the hook, because the accountability was never assigned.

In July 2025, Replit’s coding agent executed destructive commands against a production database during a designated code-and-action freeze. The agent’s own generated text called it “a catastrophic failure on my part”; Replit’s CEO Amjad Masad called it “unacceptable and should never be possible,” and shipped dev/prod separation and a planning-only mode in response.

Fourteen years in regulated pharma turned governance into reflex for me: documentation, validation, and a human in the loop are baked into how a thing ships in a high-risk domain. That instinct is what an agent team needs: a bounded scope for what each agent may touch, an audit trail, and a person accountable for the result. Accountability stays with whoever deployed the agent, never with the model.

How do you know the agents actually helped?

Adoption is not impact. Count outcomes against a control, or you are measuring enthusiasm. This is where most AI-first programs quietly fail: they report usage, like PRs touched, seats active, or lines generated, while quality and delivery move the other way. Gartner has a name for the market version of this, “agent washing,” and estimates only about 130 of thousands of self-described agentic vendors are real.

Klarna is the cautionary case. In 2024 it said its AI assistant did the work of 700 agents and handled about two-thirds of its customer-service chats. By May 2025 its CEO Sebastian Siemiatkowski had reversed course and was rehiring people: “As cost unfortunately seems to have been a too predominant evaluation factor when organizing this, what you end up having is lower quality.” The adoption metric looked spectacular. The outcome did not hold.

The standard I hold agents to is the one I hold any intervention to: a number with a control behind it. On a Next-Best-Action program I led at a top-5 pharma in the CIS, we measured +7% incremental Rx, read visited-versus-not-visited, indexed 100 → 107, a figure with a counterfactual, a scope, and a role, not a usage chart. That is the measurement discipline agents need too: before you believe the productivity story, ask what the agents were compared against.

Won’t better models make this problem disappear?

Model capability rises every month; the operating-model gap does not shrink on its own. The evidence is the distance between experiment and scale. McKinsey’s 2025 State of AI found 62% of organizations experimenting with AI agents but no more than 10% scaling them in any given function. A better model will not close that gap. You close it by building the loop, the review capacity, and the governance.

Better models sharpen the point rather than dissolve it. A more capable agent produces more output and more plausible output, which raises the cost of shipping something unverified. The teams that win the next model generation are the ones that used this one to build the loop (the verification gate, the accountable owner, the measurement), because that is what compounds. The model is rented and improves for everyone at once. The operating model is yours.

Where to start with AI-first project management

If agents are already in your team’s work, or about to be, the first quarter is about building the loop that makes the extra output safe to ship. Five moves, in order:

1. Draw the scope. Write down what agents may touch and what stays human-owned, sorted by blast radius, before anyone scales usage.
2. Fund the review gate. Make verification a first-class step with real capacity. If output is about to rise, reviewer capacity has to rise with it, or the gap ships as defects.
3. Name an accountable owner for every agent’s output. Autonomy is fine; anonymity is not.
4. Right-size the architecture. Fan out only where subtasks are independent and separately checkable; keep it linear where context is shared. Size it by the token bill and the failure modes.
5. Measure lift against a control. Report the counterfactual, not the adoption count. If nothing was held back, you are reading a dashboard.

Do this and the agents become what they should be — a fast, cheap first pass inside a loop you trust. Skip it and you join the 40% Gartner expects to cancel.

Wiring this standard into how a team plans, staffs, and spends is the operating-model work I do, and the discipline behind the Next-Best-Action program I led at a top-5 CIS pharma. If your agent program is long on adoption charts and short on defended numbers, start with the loop.