Phase 6ADLC course

Phase 6. Formation: the PM agent assembles the agent team

The architecture is ready. Before cutting the work into tasks and assigning them (that's phase 7), we need to figure out who to assign to: what team the product actually needs. This is the first of two articles about the PM role. Here — team design for the job. Cutting and assignment come in phase 7.

In the human world this is the slowest and most irreversible part: hiring. Finding people, assembling them, dividing zones, building how they work together — months of work and decisions that are hard to walk back later. In ADLC, team formation changes nature entirely: it's no longer hiring, it's configuration. And what changes isn't speed — it's reversibility.

The human role today

An engineering manager, a tech lead, or — early on — the founder. They decide what roles the product needs, hire or assemble a team, divide areas of ownership, set up how the team works and its rituals. Classically this is a hiring plan, an org chart, dividing zones, setting up team processes.

The bulk of the complexity here comes from people being scarce, expensive, slow to hire, and poor at reconfiguring. Org structures get built for years, because redoing them hurts. A large share of a formation manager's work is managing the scarcity and irreversibility of the human resource.

What we hand to the agent

The PM agent holds the role of team formation. Against architecture and backlog, it designs the composition of specialized agents: roles, specializations, a model per role, tools and permissions, topology (who orchestrates, who executes), and the interaction and escalation protocol. It decides: how many agents, of what kind, who hands off to whom, where the sync points are.

The nature of the decision changes. Scarcity disappears: spinning up another engineering agent is a matter of configuration and inference budget, not months of hiring. Irreversibility disappears: the team spins up for an epic and winds down when it's done. The org chart goes from a monument built for years to an ephemeral assembly for a specific piece of work.

Agent architecture

Phase state-machine

Inputs

architecture + ADR (phase 5), prd/backlog (phase 4), a catalog of available agent types and models with their cost and strengths.

The agent holds the role

Tools: role design; model selection per role (cost/quality trade-off); topology design (orchestrator ↔ executors); tool and permission assignment; inference budget estimation for the team.

Artifact

team-spec — the agent team's composition, roles, models, tools, permissions, interaction and escalation protocol.

Handoff: team-spec → Planning (who gets which tasks, phase 7) and Orchestration (the meta-loop, phase 14). team-spec is, in effect, org structure as code. What lives in headcount plans and staffing tables for people becomes, here, a declarative description that can be versioned, diffed, and rebuilt. Org structure becomes an artifact for the first time, not an institution.

Inputs: architecture + ADR (phase 5), prd/backlog (phase 4), a catalog of available agent types and models with their cost and strengths.
Tools: role design; model selection per role (cost/quality trade-off); topology design (orchestrator ↔ executors); tool and permission assignment; inference budget estimation for the team.
Artifact: team-spec — the agent team's composition, roles, models, tools, permissions, interaction and escalation protocol.
Trigger: completed architecture.
Handoff: team-spec → Planning (who gets which tasks, phase 7) and Orchestration (the meta-loop, phase 14).

team-spec is, in effect, org structure as code. What lives in headcount plans and staffing tables for people becomes, here, a declarative description that can be versioned, diffed, and rebuilt. Org structure becomes an artifact for the first time, not an institution.

Where it breaks

No one gets hired — but someone pays for inference. The budget for the agent team is a human decision. The agent tends to assemble a "rich" composition with margin, because for it an extra agent is nearly free in the moment. The economics of the composition — how much we're actually willing to spend on inference for this product — is set by the principal.

Over-provisioning and sprawl. Without a cap, the PM agent bloats the team: a dedicated agent for every specialization, a dedicated reviewer for every check. This runs into not technique, but budget and observability: the more autonomous agents there are, the harder it gets for the human above the loop to understand what's happening (a problem picked up by phase 14).

Permissions and access the agent hands out itself. The PM agent assigns tools and permissions to subordinate agents — up to and including access to production and money. Who authorizes an engineering agent getting deploy rights? Distributing permissions inside an autonomous team is a point where governance (phase 14) has to be present from the start, not show up later.

What stays human

Approving the team budget and the boundaries of permissions and access. A candidate for compression is the composition and topology design itself; the durable remainder is authorizing the budget and distributing sensitive permissions, and it's woven into the principal's governance loop (phase 14).

human remainder ≈ 60%

Provocation / thesis

"Assembling a team" stops being hiring and becomes configuration. Both properties that made this work heavy for humans — scarcity and irreversibility — disappear: exactly the right composition of agents spins up for the job and winds down when it's done. Org structure goes from a monument built for years to an ephemeral assembly for an epic, versioned like code. What stays non-transferable isn't team design — it's the signature on its budget and permissions, because permissions inside an autonomous team reach money and production too fast.

Running case

Vitrina in this phase

The PM agent reads Vitrina's architecture (monolithic backend, database, queue, payment integration) and spins up a composition: two backend agents (catalog/cart and payments/webhooks), one frontend agent (storefront builder and payment screen), one QA agent, one reviewer, and one DevOps agent. Routine tasks get a cheap, fast model; the payment loop, where mistakes are costly and where the critical idempotency ADR lives, gets a strong model for both the executor and the reviewer (so author and critic don't make the same mistakes — a setup for phase 9).

The agent distributes permissions on the principle of least privilege: deploy access only to the DevOps agent, payment-key access only to the payments backend agent. It doesn't authorize these assignments itself — they go into the governance loop for the principal to approve. Here the course shows for the first time that phase 14 isn't a final add-on, it's a layer that has to be present already at team assembly.

Artifact → Vitrina's team-spec. A team that didn't exist an hour ago, and will wind down once Vitrina is built.

In practice

How it actually works — engineering breakdowns

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

How to Control What AI Agents DoHow to control what AI agents do — the basis for agent-team topology.
The Skill That Onboards Other SkillsA skill that onboards other skills — assembling the team's capabilities.

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 →