Phase 7ADLC course

Phase 7. Planning: the PM agent cuts and assigns work

This is the course's flagship article. Not because planning is the hardest phase, but because this is where the "no human" provocation lands on the most defended role of all. That an agent writes code doesn't shock many people anymore. But that an agent *runs the project* — schedules calls, writes to stakeholders, transcribes meetings, cuts work into tasks, assigns owners, and checks on their status — is where the real argument starts. Because project manager is a role people conventionally believe rests on something exclusively human: relationships, politics, "team feel."

This article argues the opposite. Most of a project manager's job is maintaining shared state and routing information between people. And a machine doesn't do either "not worse" — it does both better.

The human role today

A project manager — and alongside them a scrum master, a delivery lead, partly a tech lead — exists so that a single shared picture lives in the team's heads and artifacts: what we're doing, in what order, who's on what, what's blocked, what's been promised externally and by when. They cut the backlog into tasks, estimate, assign, run the board, hold standups, write status reports, catch blockers, escalate, and negotiate timelines and scope with stakeholders.

Look closer and almost all of this is work with state and communication. The manager compensates for the fact that project state is smeared across the heads of people who forget, are busy, live in different time zones, and aren't always honest with each other about progress. Half of management's rituals — standups, statuses, groomings — are a synchronization protocol for people who share no common memory.

What we hand to the agent

The PM agent takes the project manager role whole, not in pieces. It reads the backlog and team-spec, cuts stories into tasks, estimates them, assigns them to specific agents on the team, and runs the board as an external state machine rather than a reflection of someone's memory. It initiates outbound communication: schedules a call with a stakeholder when uncertainty needs resolving, formulates and sends questions, transcribes the meeting, distills the agreements into tasks, updates the plan. It catches blockers — not when they're reported at standup, but the moment a task stops moving — and escalates.

The key shift: planning stops being an event (sprint planning every two weeks) and becomes a continuous process. The agent has no sprints, because a sprint is a way of cutting time to fit human attention rhythms. The agent replans on every state change.

Agent architecture

Phase state-machine

Inputs

prd/backlog (phase 4), team-spec (phase 6), architecture + ADR (phase 5), the project's current state (board, task statuses, communication history).

The agent holds the role

Tools: story-to-task decomposition and estimation; a task tracker as an external state machine (statuses queued → assigned → in_progress → review → done | blocked); a meeting scheduler with calendar access; stakeholder communication channels (email, messaging); transcription and meeting-summary synthesis; a blocker detector (a task hasn't changed status past a threshold) and an escalation mechanism.

Artifact

a living plan + task board + a stream of stakeholder status reports.

Handoff: assigned tasks → Implementation (phase 8); aggregated status and time budget → Orchestration (phase 14). Note the shape of the artifact. A task board with explicit statuses isn't a UI for humans — it's the heart of the phase: the single source of truth about project state, living outside anyone's head. It's precisely the move of state out of people's heads and into an external machine that makes the manager role transferable. As long as state lived in people, you needed a person to collect it.

Inputs: prd/backlog (phase 4), team-spec (phase 6), architecture + ADR (phase 5), the project's current state (board, task statuses, communication history).
Tools: story-to-task decomposition and estimation; a task tracker as an external state machine (statuses queued → assigned → in_progress → review → done | blocked); a meeting scheduler with calendar access; stakeholder communication channels (email, messaging); transcription and meeting-summary synthesis; a blocker detector (a task hasn't changed status past a threshold) and an escalation mechanism.
Artifact: a living plan + task board + a stream of stakeholder status reports.
Trigger: team-spec and backlog appear; after that the agent runs continuously — this isn't a one-time planning act, it's an ongoing process of reconciling state.
Handoff: assigned tasks → Implementation (phase 8); aggregated status and time budget → Orchestration (phase 14).

Note the shape of the artifact. A task board with explicit statuses isn't a UI for humans — it's the heart of the phase: the single source of truth about project state, living outside anyone's head. It's precisely the move of state out of people's heads and into an external machine that makes the manager role transferable. As long as state lived in people, you needed a person to collect it.

Where it breaks

The course has to be honest here, because this is the phase where it's easiest to slide into hype.

Stakeholder politics. Prioritizing under conflicting interests isn't optimization — it's choosing a side. When the founder wants a feature for the investor demo and the data says fixing churn matters more, someone has to decide not "what's optimal by the metric" but "whose interest wins right now." The agent tends to average and seek compromise where a choice is required. This isn't a model bug — it's the model's lack of legitimacy to make a political decision.

Outbound commitments. When the PM agent tells a stakeholder "we'll have it by Friday," who made that promise? A subject is accountable for a missed deadline given on behalf of the team. The agent may compute a realistic date better than a human — but it can't be the one held to their word.

The trust of live participants. As long as there's even one human in the loop — stakeholder, principal — there's a question of whether they consent to being "managed" by an agent: it taking their time, asking them questions, summarizing their words. That's a question of consent, not technique.

Cascading coordination errors. With a human manager, a priority mistake gets dampened by slow communication — by the time it reaches everyone, someone will have questioned it. An agent will broadcast a wrong priority to the entire team instantly and without friction. Coordination speed is both a strength and an error multiplier.

What stays human

The honest remainder is narrow and contested: the signature on outbound commitments and arbitration of political priority conflicts. Everything else in the manager role — decomposition, estimation, assignment, status reconciliation, running the board, transcripts, blocker escalation — isn't merely transferable to the agent, it's performed better by it.

And even this remainder is unstable. Once the loop closes on a single human principal (phase 14), "priority arbitration" collapses into rare check-ins with them rather than a standing role. A separate human manager between the principal and the agent team disappears first — it was itself a synchronization layer, and there's nothing left to synchronize.

human remainder ≈ 53%

Provocation / thesis

Project management is predominantly maintaining shared state and routing information between executors. A machine handles both better: it doesn't forget, it's available around the clock, it doesn't distort the picture to serve its own political interests, and it holds state in an explicit external machine rather than in someone's head.

"Project manager" as a separate human role is an artifact of an era when project state lived in people's heads and there was no one but another person to reconcile it. Remove that constraint and the role dissolves. What's left isn't a manager, but a single lever: the one accountable for promises and who resolves conflicts of interest. That's no longer a job — it's an authority.

Running case

Vitrina in this phase

The PM agent takes the "payment capture" epic from Vitrina's backlog and cuts it into tasks: payment-provider integration, transaction idempotency, status webhooks, the payment screen, notifications. It estimates, assigns two tasks to backend agents, the screen to the frontend agent, and sets dependencies (webhooks not before the base integration).

Then it runs as a process. It schedules a weekly fifteen-minute call with the founder — the only human in the loop — because per the gtm-plan, payment methods depend on the launch region, and that's the founder's call. It transcribes the call, pulls out the agreement "start with one provider, local methods in v2," updates the plan and priorities. A day later it detects a blocker: the idempotency task has been stuck for two days — the backend agent hit the fact that the provider doesn't guarantee webhook key uniqueness. The PM agent doesn't wait for a standup: it escalates, raises the question with the provider, and simultaneously reassigns the blocked agent to webhooks so it isn't idle.

There isn't a single point in this loop where a human manager is required. There's one point where the founder is needed — and that's a decision about region and money, not team management.

In practice

How it actually works — engineering breakdowns

Standalone howto from practice, showing this phase on real code and a working artifact.

Spec Kit as Engineering Discipline: Spec Before CodePlanning as an explicit workflow phase, not a one-off act.
Agent Builds Executable Deterministic WorkflowsThe agent builds deterministic executable workflows — managed work slicing.

Building AI-driven delivery in-house?

Designing the ADLC loop: where the agent holds the role and where the human principal remains — for your team and product.

Email me

The transition engine

Next Move Engine — the system that takes a team to an autonomous delivery loop.

Next Move Engine →