How to structure teams for agentic AI: roles, pods and seams

In this lesson you'll learn:

• why agentic AI needs no new roles, and which two boundaries between roles move;
• how to split product teams, a platform team and governance;
• why the system's seams follow the org chart, and what to do about it.

Sound familiar?#

• A central "AI team" builds agents for other departments, and neither side owns the result.
• Every team built its own model integration, and nobody can say what the organisation spends.
• The multi-agent design has one agent per department, and the hand-offs between them are where it breaks.

Each is an organisational decision showing up as a technical defect.

What changes in the organisation?#

Less than the market implies. Five roles; none is new, none disappears. What moves is the boundary between them, in two places: the product manager stops approving things they cannot evaluate, and QA gains a veto that is arithmetic rather than opinion. A slice whose lower bound is below its bar does not pass. Almost everything else is the discipline you already have, applied to a product that is now partly probabilistic.

Structure it, step by step#

Step 1 · Keep the five roles, and move the two boundaries#

Product manager, solution architect, engineering lead, QA lead, DevOps and platform, plus a sponsor. Write down, per role, what is theirs and what is not, and remove the approvals people cannot evaluate. Who signs what

Step 2 · Give each product one team that owns it end to end#

A small product team (a pod of four, plus DevOps support) owns one product, or one agent, from framing to operation: the pain, the spec, the build, the proof and the running system. The decisions that matter most (the bar, autonomy per action) are business decisions, so they belong with the team that owns the business outcome, not with a separate AI group.

Step 3 · Build a platform team for what every product team needs#

Everything that should be the same everywhere goes to one platform team: the model gateway with its per-call log, the landing zone and cost tags, the harness template, flags and traces. The one decision to take centrally is not which assistant (teams can choose their own editor) but that every model call in production passes through one layer you own. The gateway is a fortnight of work, and without it a surprise invoice is a mystery rather than a diagnosis.

Step 4 · Put the seams where the teams are#

A system's structure tends to copy the communication structure of the organisation that builds it: Conway's law. In agentic AI that means agent boundaries follow team boundaries: one agent per department is often an org chart, not a design. Decide the seams on purpose. Start with one agent per product and give each hand-off a named limit; n agents have n(n − 1) ÷ 2 possible hand-offs, and so do n teams.

Step 5 · If you have a central AI group, make it enable rather than build#

A central group earns its place by coaching the method across teams and by providing the platform, not by building other people's agents, which separates the model from the business decisions it depends on. That is the difference between an enabling or platform team and a bottleneck.

Step 6 · Name one governance owner#

Governance spans the whole lifecycle and belongs to no delivery role. Name the sponsor who owns it. If the answer is "we all do", nobody does.

Where you'll use it#

• When an organisation starts its second or third agentic product and the first one's shortcuts start to hurt.
• When costs or model integrations have fragmented across teams.
• When a multi-agent design mirrors the org chart: check whether that was a decision.

Why it matters#

Agentic AI needs no reorganisation to start, and a wrong structure makes it expensive to scale: agents owned by nobody, integrations duplicated everywhere, hand-offs placed where departments meet rather than where the work divides. The structure above keeps decisions with the people who own the outcome, and the shared machinery in one place.

Key takeaways#

1. No new roles, none disappears, and two boundaries move: the PM stops approving code, QA's veto is arithmetic.
2. Product teams own products end to end; a platform team owns what every team needs.
3. Seams follow team boundaries: decide them on purpose, and name one governance owner.

FAQ#

How should we structure teams for AI agents?#

A small product team per product (product manager, architect, engineering lead and QA lead) owning it from framing to operation; a platform team providing the model gateway, landing zone, harness and traces for everyone; and a named sponsor owning governance.

Do we need an AI centre of excellence?#

A central group helps if it enables and provides (coaching the method and running the shared platform) rather than building agents for other departments, which separates the agent from the business decisions it depends on.

What new roles does agentic AI create?#

Fewer than expected. The five delivery roles and the sponsor remain; what changes is what each owns. The work of writing precise specs, deriving bars and enforcing limits in code is spread across existing roles.

What is Conway's law?#

The observation, from Melvin Conway in 1968, that organisations design systems whose structure copies their own communication structure. In agentic AI it predicts that agent boundaries will follow team boundaries unless someone decides otherwise.

Apply it in your role#

Across the enterprise. Split a central AI group into a platform team and an enabling team, and let product teams own their agents end to end, including the decisions about what a mistake costs.

The ten-minute workflow. Test your design against Conway's law:

Here are our org chart and our agent architecture: <paste both>. Map every agent boundary and hand-off to
the team boundary it follows. List each hand-off with no named limit, each agent that no product team
owns, and each shared service that has been built more than once. Suggest the smallest change to either.

Sources and credits#