Team Topologies in the AI Era: How AI Changes Engineering Org Design

Matthew Skelton and Manuel Pais published Team Topologies in 2019, and it became the default framework for engineering org design because it gave leaders a shared vocabulary for structuring teams around cognitive load and fast flow. The four team types and three interaction modes are still the right abstraction. What has changed is the calibration: AI shifts the cognitive load equation, and every team type moves in response.

Why did the cognitive load equation move?

Team Topologies sizes teams so that domain complexity, technical complexity, and interaction complexity fit within the team's cognitive capacity. Exceed it and the team slows down, makes mistakes, or burns out. The same fast-flow goal underpins the DORA research program, which ties delivery performance directly to how teams are structured and how work moves through them.

AI changes that equation in two distinct directions.

Implementation load drops

The cognitive load of writing code — remembering syntax, understanding library APIs, translating requirements into implementation — drops with AI augmentation. An engineer working with a coding agent spends less mental energy on "how to implement this" and more on "what to implement" and "whether this implementation is correct." That reduction is what makes smaller teams viable: a 3-person team with AI augmentation can absorb workload that used to require 7-8 people.

Integration load rises

Integration cognitive load — the overhead of understanding how a team's work connects to everyone else's — increases, because each team now ships more. More features, more APIs, more data models, more infrastructure changes per unit of time. A 5-person AI-augmented team producing at the rate of a traditional 12-engineer team creates a 12-engineer's worth of integration surface. The neighboring team has to track two to three times more change than before AI.

Less implementation load, more integration load: that asymmetry is the central adjustment behind everything below.

How do stream-aligned teams change in the AI era?

Stream-aligned teams own a stream of work tied to a business domain or user journey. Pre-AI, the recommended size was 7-9 people; the AI-era range is 3-5 senior engineers.

AI-era sizing: 3-5 engineers

A 3-5 person pod with AI augmentation can match or exceed the output of a 7-9 person traditional team, and coordination overhead within the team drops because fewer people means fewer communication channels. But domain cognitive load does not shrink with the team: a 3-person team owning a billing domain still needs the same business rules, edge cases, and compliance knowledge a 9-person team needed. That knowledge is now concentrated in fewer heads.

Two practical consequences follow:

• The hiring bar rises. Engineers need to hold more domain context on their own; mid-level engineers who leaned on seniors to explain the domain do not fit well in 3-person pods.
• Bus factor worsens. Losing one person from a 9-person team costs roughly 11% of domain knowledge; from a 3-person team, roughly 33%. Documentation (AI-maintained), cross-pod familiarity sessions, and never letting domain knowledge live in a single head are the mitigations.

Full-stack ownership becomes practical

Stream-aligned teams historically had to hand off infrastructure or specialist work to other teams. With AI augmentation, a 4-person pod can plausibly write and maintain its own infrastructure as code (AI drafts the Terraform, engineers review and customize), build and maintain its own CI/CD pipeline on top of platform-team primitives, handle basic data-engineering tasks, and integrate straightforward ML features. This cuts inter-team dependencies — the core goal of the stream-aligned pattern — at the cost of each pod making more infrastructure decisions, which puts more weight on the platform team's defaults and guardrails.

Less collaboration, more self-service

Stream-aligned teams increasingly skip the collaboration interaction mode in favor of self-service: instead of scheduling weeks of joint work with the platform team to stand up a new service, the team runs a CLI tool that provisions everything from a template. That is a net gain for flow, provided the platform team has invested in the tooling, documentation, and AI-assisted onboarding that make self-service actually work. A poorly designed self-service path pushes teams back toward ad hoc workarounds — the same fragmentation Team Topologies was built to prevent.

Why do platform teams become the center of gravity?

In the original framework, platform teams were a supporting role: infrastructure and tooling so stream-aligned teams could focus on business value, useful but secondary. In AI-era orgs, platform teams move to the center, because AI coding agents need consistency to be effective, and the platform team is the organizational unit that provides it.

Why platform teams matter more with AI

AI coding agents read context — codebase, documentation, API specs — and generate code that fits it. When the context is consistent (same deployment patterns, same auth mechanisms, same API conventions, same testing frameworks), agents are measurably more effective; every deviation from the standard requires custom context and degrades output quality. In practice this roughly doubles the platform team's ROI: standardization that used to save a stream-aligned team 10-15% of infrastructure overhead now improves AI effectiveness by an estimated 20-30% per team, because the leverage compounds across every AI-assisted change that team makes.

Three concrete examples of what this looks like in practice:

• Service templates with AI context. A new service created from the platform template ships with a project-level instruction file describing the org's conventions, API patterns, authentication approach, and deployment process, so an agent is productive on day one instead of spending the first stretch of every task inferring local conventions.
• Standardized API patterns. When every service follows the same request/response format, error handling, pagination, and versioning, agents generate correct API client code without per-service customization. Teams without that standardization report AI-generated API integrations failing at a notably higher rate.
• Unified deployment. One deployment pipeline that behaves identically for every service lets agents generate deployment configs, rollback scripts, and monitoring dashboards without service-specific knowledge.

Platform team scope expands

The platform team's remit grows to include AI-specific infrastructure: an LLM API gateway that centralizes rate limiting, cost tracking, model routing, and fallback (without it, each stream-aligned team manages its own keys and has no visibility into org-wide AI spend); context-engineering templates that stream-aligned teams inherit and customize; evaluation frameworks for comparing models and validating AI-generated code before human review; and cost-monitoring dashboards that break down AI spend by team, model, and use case.

Platform team sizing

Traditional Team Topologies guidance put roughly one platform engineer per 10-15 stream-aligned engineers. AI-era orgs tend to run closer to one platform engineer per 8-10, because the scope is larger and the ROI per platform engineer is higher.

Org size	Traditional platform team	AI-era platform team
20-30 engineers	0-2 people	2-3 people
30-60 engineers	3-5 people	4-6 people
60-100 engineers	5-8 people	8-10 people
100-200 engineers	8-15 people	12-20 people

Why do enabling teams become permanent?

Enabling teams originally existed to help stream-aligned teams develop new capabilities, and were deliberately temporary: work with a team for a few weeks, transfer the knowledge, move on, avoid creating a long-term dependency. AI-era orgs have a reason that team type did not have in 2019 to stay permanent: the tooling landscape changes every quarter, and someone needs to continuously evaluate, integrate, and train on new capability. The individual role shifts this creates inside stream-aligned teams are covered in Building AI-Native Engineering Teams.

The AI enabling team

A dedicated AI enabling team of 2-4 people typically covers tool evaluation (new coding agents ship monthly; the team runs controlled pilots and recommends adoption or rejection), context-engineering standards (maintaining the org's instruction-file templates, spec formats, and prompt libraries), training and workshops (sharing prompting patterns, running monthly sessions on new capability), effectiveness measurement (tracking AI-adoption metrics across teams and flagging teams under-utilizing the tooling), and cost optimization (monitoring AI API spend, negotiating enterprise agreements, and advising on model selection for different use cases).

Why this team stays permanent

In the original framework, enabling teams were temporary because the capabilities they taught were stable — you learned containerization once. AI capability is not stable: the prompting patterns, context-engineering approaches, model capabilities, and pricing that were current a year ago are meaningfully different today. A team that disbanded after teaching "how to use AI" would need to reform a quarter later to teach the new version of the same thing.

The cost of skipping this function is measurable. Without a dedicated AI enabling team, each stream-aligned team spends an estimated 10-20% of its time independently evaluating tools and building ad hoc workflows; a centralized enabling team can bring that down to roughly 2-5% per team by doing the evaluation once and sharing the result.

Facilitating with a self-service layer

The enabling team's primary interaction mode is still facilitating, but AI-era enabling teams add a self-service layer — documentation, recorded workshops, AI-assisted onboarding, curated prompt libraries — that teams draw on without needing direct interaction. That layer is what lets the team scale: a traditional enabling team of three could support 6-8 stream-aligned teams through direct facilitation; with a strong self-service layer, the same team can support 10-15.

Why are complicated-subsystem teams dissolving?

Complicated-subsystem teams existed because certain technical domains — ML pipelines, real-time video processing, financial calculation engines, low-level performance work — required specialist knowledge that generalist stream-aligned engineers did not have. This is the team type most affected by AI.

AI handles most specialist implementation

AI coding agents now handle an estimated 60-70% of the specialist implementation work that used to require a dedicated team. Agents generate ML training pipelines, feature-engineering code, and model-serving infrastructure, letting an engineer who understands the concepts but can't write the framework code from memory build production ML systems with assistance. They generate WebSocket handlers and event-streaming configuration, lowering the bar from deep protocol expertise to a working understanding of event-driven architecture. They identify and fix common performance bottlenecks — query optimization, caching, concurrent processing — leaving genuinely unusual cases to humans. And they generate and maintain infrastructure-as-code, reducing the specialist DevOps knowledge a team needs to hold in-house.

What still requires a specialist

Not everything transfers to a generalist team with AI. Novel algorithm design, where the problem doesn't match existing training-data patterns, still needs humans who can reason from first principles. Hardware-adjacent optimization — GPU kernels, SIMD work, custom hardware integration — needs a feedback loop ("does this actually run faster on this hardware") that AI can't reliably close on its own. Regulatory-compliance implementation needs human legal judgment. And security-critical systems — cryptography, authentication protocols — carry too much downside if an agent hallucinates a vulnerability.

Embed, don't isolate

Rather than maintaining standalone complicated-subsystem teams, AI-era orgs increasingly embed the specialist directly in the stream-aligned pod: four generalist engineers plus one ML specialist, with AI bridging the knowledge gap between them. This eliminates the handoff that was historically the biggest source of delay — spec written by the stream-aligned team, interpreted (often differently) by the subsystem team, implemented, handed back, and found not quite to match. The cases that still justify a standalone team are the ones serving multiple stream-aligned teams at once (a shared ML platform, a central search engine) that can't be decomposed per team — and even there, AI typically shrinks the team from 5-8 specialists to 3-4.

How do interaction modes change in the AI era?

Team Topologies defines three interaction modes — collaboration, X-as-a-Service, and facilitating — and all three shift.

Collaboration narrows to novel problems

Collaboration was the most common mode in traditional orgs: two teams working closely to build a shared capability or migrate infrastructure. In AI-era orgs, routine collaboration needs — "help us set up a new service," "help us integrate with your API" — get absorbed by self-service tooling and AI-assisted onboarding, and collaboration mode narrows to problems genuinely too novel for that path. A useful test: can a competent engineer with AI tools work this out from documentation and self-service tooling in under two days? If yes, don't open a collaboration engagement; fix the documentation or tooling instead.

X-as-a-Service becomes the default

AI pushes teams toward X-as-a-Service — one team provides a capability, others consume it through a defined interface — for three reasons: AI-assisted documentation makes comprehensive, current docs cheaper to maintain; AI-assisted interfaces (CLI tools, chatbots, self-service portals) handle the "how do I use this" function that used to require a human from the providing team; and AI-generated integration code lets a consuming team turn a service's API spec directly into working integration code. The platform team's job increasingly becomes maintaining interface quality — clear APIs, working examples, AI-readable context files — rather than staffing direct support.

Facilitating gets shorter and sharper

Facilitating survives but compresses: the enabling team provides curated context files covering most of the knowledge transfer, the stream-aligned team works through AI-assisted tutorials beforehand, and the facilitation session itself focuses on the organizational context, political considerations, and judgment calls that require a human. Facilitation engagements that took three to four weeks in traditional orgs often run one to two weeks in AI-era orgs, with comparable or better transfer outcomes.

How does Conway's Law apply in the AI era?

Conway's Law — organizations design systems that mirror their communication structures — still holds, but "communication structure" now includes AI-mediated channels: project-level instruction files that communicate architectural decisions and conventions to agents, API specs that serve as both human documentation and AI input, and automated documentation that keeps system knowledge current without manual effort. Teams that maintain high-quality AI-readable artifacts produce better-integrated systems, because their agents carry better cross-team context — which makes the platform team's context-engineering standards a direct lever on system architecture, not just a productivity nicety.

The Inverse Conway Maneuver — structuring the org to produce the architecture you want — gets stronger with AI, because AI amplifies whatever organizational pattern is already in place. Teams with well-defined domain boundaries and explicit API contracts get agents that reinforce those boundaries. Teams with fuzzy, implicit boundaries get agents that take the ambiguity at face value and produce coupling, because there's no human negotiating the fuzzy edges through conversation the way there used to be. Formal team APIs and explicit domain boundaries have gone from a nice-to-have to a requirement for that reason alone.

What does an AI-era team topology look like at scale?

Putting the pieces together, here is roughly how an AI-era engineering org's topology looks at three scales.

20-30 engineers (3-5 stream-aligned pods)

Team type	Count	Size	Focus
Stream-aligned	4-6	3-4 each	Product delivery
Platform	1	2-3	Deploy, observability, templates
Enabling (AI)	0-1	1-2	AI workflow, part-time
Complicated-subsystem	0	-	Embedded in stream-aligned

50-80 engineers (10-16 stream-aligned pods)

Team type	Count	Size	Focus
Stream-aligned	10-16	3-5 each	Product delivery
Platform	1-2	4-6 each	Infra, AI platform, DX
Enabling (AI)	1	2-3	AI adoption, evaluation
Complicated-subsystem	0-1	3-4	Only if shared ML/search

100-200 engineers (20-40 stream-aligned pods)

Team type	Count	Size	Focus
Stream-aligned	20-40	3-5 each	Product delivery
Platform	2-3	5-8 each	Core infra, AI platform, DX, data
Enabling (AI)	1-2	3-4 each	AI adoption, security, DevRel
Complicated-subsystem	1-2	3-4 each	Shared ML, search, compliance

How do you migrate to AI-era topologies?

An organization with an existing Team Topologies implementation should not reorganize everything at once. A four-phase migration path holds up in practice, and the org-design thresholds that drive the pacing are covered in more depth in Scaling Engineering Teams in the AI Era.

Phase 1: pilot (month 1-3)

Pick one stream-aligned team, shrink it from 7-9 to 4-5 engineers, and add heavy AI augmentation. Move the reassigned engineers to other teams or a new pod. Measure the pilot's output against a comparable traditional team for one quarter to calibrate expectations and surface problems before scaling the approach.

Phase 2: platform investment (month 2-4)

While the pilot runs, invest in platform capability: the service template with AI context files, a standardized deployment pipeline, self-service provisioning tools. This needs to lead the stream-aligned migration by one to two months, because smaller pods depend on platform consistency to be effective from day one.

Phase 3: gradual migration (month 4-9)

Migrate stream-aligned teams pod by pod, two to three per month, each following the same pattern: shrink, add AI, redistribute. After each batch, check whether the smaller pods are maintaining output, whether cross-pod dependencies are manageable, and whether the platform team is keeping pace with demand.

Phase 4: topology refinement (month 9-12)

Once all stream-aligned teams have migrated, assess the complicated-subsystem and enabling-team changes: dissolve subsystem teams no longer justified, stand up the AI enabling team if it doesn't exist yet, and adjust platform-team sizing to actual demand.

What mistakes do teams make migrating to AI-era topologies?

• Shrinking teams without adding AI augmentation. A smaller team without AI tooling is just understaffed. The size reduction only works if AI actually absorbs the implementation workload.
• Skipping platform investment. Smaller, faster teams without platform standardization create more fragmentation than existed before. Platform investment needs to lead or run parallel to the stream-aligned migration.
• Eliminating every complicated-subsystem team. The 60-70% figure is an average across domains. Some specialist work genuinely still needs a dedicated team; assess each subsystem on its own merits.
• Treating AI enabling as temporary. The tooling landscape changes quarterly. A team disbanded after "teaching AI" reforms a quarter later to teach the new version of the same thing.
• Keeping the same interaction modes. Shrinking teams while keeping collaboration-heavy interaction patterns leaves the gain on the table. The shift to X-as-a-Service is what lets smaller teams hold their velocity.

The calibration, not a replacement

Team Topologies remains the strongest available framework for engineering org design; the four team types and three interaction modes are still the right level of abstraction. What changes in the AI era is the calibration. Stream-aligned teams get smaller. Platform teams become more important. Enabling teams become permanent. Complicated-subsystem teams partially dissolve. The dominant interaction mode shifts from collaboration to X-as-a-Service.

The organizations that adapt successfully are the ones that internalize the cognitive load shift: less implementation load, more integration load. Size teams for the implementation load — smaller. Invest in platform and coordination structures for the integration load — more. Get both right and the result is an organization that produces more with less while holding architectural coherence.

For help calibrating Team Topologies for an AI-augmented engineering organization, get in touch.

Frequently asked questions

Is Team Topologies still relevant with AI?

Yes, with adaptation. The four team types (stream-aligned, platform, enabling, complicated-subsystem) and three interaction modes remain the right abstraction for engineering org design. What changes is sizing, timing, and relative importance: stream-aligned teams get smaller, platform teams become more critical, enabling teams shift focus to AI adoption and stop disbanding, and complicated-subsystem teams largely dissolve. Interaction modes shift toward more X-as-a-Service because AI enables self-service patterns that previously required direct collaboration.

How does AI change the cognitive load model?

Team Topologies sizes teams to manage cognitive load. AI changes the equation in two directions: it reduces implementation cognitive load (engineers spend less mental energy on syntax and library APIs) but increases integration cognitive load (each team ships more, which grows API surface area and cross-team dependencies). Net effect: teams can be smaller because implementation load drops, but they need stronger architectural thinking because integration load rises.

Should platform teams own AI infrastructure?

Yes. AI infrastructure — LLM API gateways, prompt and context-file registries, evaluation frameworks, and cost monitoring — belongs in the platform team. Letting every stream-aligned team build its own AI infrastructure recreates the fragmentation problem platform teams exist to solve. The platform team provides standardized AI primitives; stream-aligned teams consume them and add domain-specific context.

What happens to Conway's Law with AI?

Conway's Law still holds: organizations design systems that mirror their communication structures. AI adds a channel to that structure. Coding agents read context files, documentation, and API contracts rather than sitting in meetings, so the 'communication structure' now includes human-to-human, human-to-AI, and AI-to-API paths. Teams that maintain high-quality, consistent AI-readable artifacts tend to produce more coherent systems, because their AI agents work from compatible information across teams.

How do interaction modes change with AI?

The three modes — collaboration, X-as-a-Service, and facilitating — all shift toward more X-as-a-Service. AI enables self-service patterns that previously required direct human collaboration: platform teams can expose AI-assisted interfaces (CLI tools, self-service portals, automated provisioning) that stream-aligned teams use without scheduling a meeting. Collaboration mode narrows to genuinely novel problems. Facilitating mode shifts from general capability-building to AI workflow optimization.

When should an organization reorganize existing teams into the AI-era topology?

Gradually, not all at once. Start with one stream-aligned team as a pilot: reduce it to 3-5 engineers, add AI augmentation, and measure output against a comparable traditional team for one quarter. Use the pilot to calibrate platform-team investment and enabling-team focus, then expand pod by pod over the following two to three quarters. Reorganizing the entire org at once tends to create a productivity dip that takes months to recover from.