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

Team Topologies Meets AI

Matthew Skelton and Manuel Pais published Team Topologies in 2019. It became the default framework for engineering org design because it solved a real problem: it gave leaders a shared vocabulary and a set of patterns for structuring teams around cognitive load and fast flow.

Seven years later, the framework is still sound. The four team types and three interaction modes remain the best abstractions we have for thinking about engineering organization design. But the sizing, timing, and relative importance of each team type have shifted because AI fundamentally changes the cognitive load equation.

This is not a "Team Topologies is dead" article. It is a calibration guide. If you are already using Team Topologies (or considering adopting it), this tells you what to adjust for AI-augmented engineering.

The Cognitive Load Shift

Team Topologies is built on a cognitive load model. Teams should be sized so that their domain complexity, technical complexity, and interaction complexity fit within the team's cognitive capacity. When the load exceeds capacity, the team slows down, makes mistakes, and burns out. The same fast-flow goal underpins the DORA research program, which ties delivery performance to how teams are structured and how work moves through them.

AI changes the cognitive load equation in two distinct ways:

Implementation Load Drops

The cognitive load of writing code — remembering syntax, understanding library APIs, translating requirements into implementation — drops significantly with AI augmentation. An engineer with Claude Code or Cursor spends less mental energy on "how to implement this" and more on "what to implement" and "whether this implementation is correct."

This is the reduction that enables smaller teams. A 3-person team with AI augmentation can handle the implementation workload that used to require 7-8 people because AI absorbs the routine implementation cognitive load.

Integration Load Rises

But integration cognitive load — the mental overhead of understanding how your work connects to other teams' work — increases. Why? Because each team ships more. More features, more APIs, more data models, more infrastructure changes per unit time. The integration surface area grows proportionally with output.

A 5-person AI-augmented team producing at the rate of 12 traditional engineers creates 12 engineers' worth of integration surface area. The team next to them has to track 2-3x more changes from their neighbors than they did before AI.

This asymmetry — less implementation load, more integration load — is the central insight for adapting Team Topologies to the AI era. It changes every team type differently.

Stream-Aligned Teams: Smaller, Faster, More Autonomous

Stream-aligned teams are the primary team type in Team Topologies. They own a stream of work aligned to a business domain or user journey. In pre-AI orgs, the recommended size was 7-9 people.

AI-Era Sizing: 3-5 Engineers

The implementation cognitive load reduction from AI justifies smaller teams. A stream-aligned pod of 3-5 senior engineers with AI augmentation handles the workload of a 7-9 person traditional team. The output is comparable or better. The coordination overhead within the team drops because fewer people means fewer communication channels (n*(n-1)/2 formula).

But — and this is important — the domain cognitive load does not shrink. A 3-person team owning a customer billing domain still needs to understand all the business rules, edge cases, and compliance requirements that a 9-person team needed to understand. The knowledge is concentrated in fewer heads, which means each person carries more domain context.

This has two practical implications:

• Hiring bar rises. You need engineers who can hold more domain context. Mid-level engineers who relied on seniors to explain the domain context do not work in 3-person pods. Everyone needs to understand the full domain.
• Bus factor worsens. In a 9-person team, losing one person costs 11% of domain knowledge. In a 3-person team, it costs 33%. Mitigate this with documentation (AI-maintained), cross-pod familiarity sessions, and ensuring no domain knowledge exists solely in one person's head.

Full-Stack Ownership Becomes Viable

In traditional Team Topologies implementations, stream-aligned teams often needed to hand off infrastructure or specialist work to other teams. With AI augmentation, full-stack ownership becomes practical for stream-aligned teams because AI handles the specialist implementation they previously lacked expertise for.

A 4-person stream-aligned pod with AI can:

• Write and maintain their own infrastructure as code (AI generates Terraform, engineers review and customize)
• Build and maintain their own CI/CD pipeline (built on platform team primitives)
• Handle basic data engineering tasks (AI generates ETL pipelines, engineers validate logic)
• Implement basic ML features (AI handles model integration, engineers handle evaluation and monitoring)

This reduces inter-team dependencies, which is the core goal of stream-aligned teams. The trade-off is that each pod makes more infrastructure decisions, which requires the platform team to provide strong defaults and guardrails.

Interaction Mode Shift: Less Collaboration, More Self-Service

Stream-aligned teams in AI-era orgs interact with other teams differently. The collaboration interaction mode (two teams working closely together for a period) becomes less common because AI enables self-service patterns. Instead of scheduling 3 weeks of collaboration with the platform team to set up a new service, the stream-aligned team runs a CLI tool that provisions everything from a template.

This is a net positive for flow, but it requires the platform team to invest heavily in self-service tooling, documentation, and AI-assisted onboarding. If the self-service path is poorly designed, teams work around it, creating the same fragmentation problem that Team Topologies was designed to solve.

Platform Teams: The Center of Gravity

In the original Team Topologies framework, platform teams were a supporting role. They provided infrastructure and tooling so stream-aligned teams could focus on business value. Important, but secondary to the stream-aligned teams that delivered user-facing features.

In AI-era orgs, platform teams become the center of gravity. The reason is structural: AI agents need consistency to be effective, and the platform team is the organizational unit that provides consistency.

Why Platform Teams Matter More With AI

AI coding agents work by reading context (codebase, documentation, API specs) and generating code that fits that context. When the context is consistent — same deployment patterns, same auth mechanisms, same API conventions, same testing frameworks — AI agents are significantly more effective. Every deviation from the standard requires custom context, which reduces AI output quality.

This creates a multiplier effect for platform teams. In traditional orgs, platform team standardization saved each stream-aligned team maybe 10-15% of their infrastructure overhead. In AI-era orgs, platform team standardization improves AI effectiveness by 20-30% per stream-aligned team. The ROI roughly doubles.

Concrete examples of what this looks like:

• Service templates with AI context: When a stream-aligned team creates a new service from the platform template, it comes with a CLAUDE.md file that describes the org's conventions, API patterns, authentication approach, and deployment process. AI agents start productive immediately instead of spending the first 20% of every task figuring out local conventions.
• Standardized API patterns: When every service follows the same API design (request/response format, error handling, pagination, versioning), AI agents can generate correct API client code without per-service customization. In orgs without this standardization, AI-generated API integrations fail 30-40% of the time because of inconsistent conventions.
• Unified deployment: A single deployment pipeline that works identically for every service means AI agents can generate deployment configurations, rollback scripts, and monitoring dashboards without service-specific knowledge.

Platform Team Scope in AI-Era Orgs

The platform team's scope expands in AI-era orgs to include AI-specific infrastructure:

• LLM API gateway: A centralized proxy for LLM API calls that handles rate limiting, cost tracking, model routing, and fallback. Without this, each stream-aligned team manages their own API keys, hits rate limits independently, and has no visibility into org-wide AI costs.
• Context engineering templates: Standardized project-level instruction files, spec templates, and prompt patterns that stream-aligned teams inherit and customize for their domain.
• Evaluation frameworks: Tools for measuring AI output quality, comparing models, and running automated validation on AI-generated code before human review.
• Cost monitoring: Dashboards showing AI API spend per team, per model, per use case. This becomes critical at scale because AI costs grow with headcount and usage intensity.

Platform Team Sizing

In traditional Team Topologies, the rule of thumb was roughly 1 platform engineer per 10-15 stream-aligned engineers. In AI-era orgs, the ratio shifts to roughly 1 platform engineer per 8-10 stream-aligned engineers because the platform 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

Enabling Teams: From Capability Building to AI Adoption

Enabling teams in the original framework existed to help stream-aligned teams develop new capabilities. They were temporary: work with a team for a few weeks, transfer the knowledge, move on. The goal was to avoid creating long-term dependencies.

In AI-era orgs, enabling teams have a permanent justification that did not exist in 2019: the AI tooling landscape changes every quarter, and someone needs to continuously evaluate, integrate, and train on new capabilities.

The AI Enabling Team

A dedicated AI enabling team (2-4 people) handles:

• Tool evaluation: New AI coding tools and agents ship monthly. The enabling team evaluates them against the org's needs, runs controlled pilots, and recommends adoption or rejection.
• Context engineering standards: Maintaining and evolving the org's CLAUDE.md templates, spec formats, prompt libraries, and AI workflow documentation.
• Training and workshops: Running monthly workshops on new AI capabilities, sharing effective prompting patterns, and helping stream-aligned teams optimize their AI workflows.
• Effectiveness measurement: Tracking AI adoption metrics across stream-aligned teams, identifying teams that are under-utilizing AI, and providing targeted support.
• Cost optimization: Monitoring AI API costs, negotiating enterprise agreements, and advising teams on model selection for different use cases (when to use Opus vs Sonnet vs Haiku).

Why This Team Stays Permanent

In the original framework, enabling teams were temporary because the capabilities they taught were stable. You learned containerization once. You learned microservice patterns once. The knowledge did not expire quarterly.

AI capabilities are not stable. Claude Code in January 2026 is fundamentally different from Claude Code in January 2025. The prompting patterns, the context engineering approaches, the model capabilities, the pricing — everything changes on a quarterly cycle. An enabling team that disbands after teaching "how to use AI" would need to reform 3 months later to teach "how to use the new version of AI."

The cost of not having this team is measurable. Without a dedicated AI enabling function, each stream-aligned team spends 10-20% of their time independently evaluating tools, attending vendor webinars, and developing ad-hoc AI workflows. An AI enabling team reduces that to 2-5% per team by centralizing the evaluation and sharing the results.

Interaction Mode: Facilitating With a Self-Service Layer

The enabling team's primary interaction mode is facilitating, consistent with the original framework. But AI-era enabling teams add a self-service layer: internal documentation, recorded workshops, AI-assisted onboarding tools, and curated prompt libraries that teams access without needing direct interaction with the enabling team.

This self-service layer means the enabling team scales better. In traditional orgs, an enabling team of 3 could support 6-8 stream-aligned teams through direct facilitation. In AI-era orgs, the same team supports 10-15 stream-aligned teams because 60-70% of the knowledge transfer happens through self-service resources.

Complicated-Subsystem Teams: The Dissolving Category

Complicated-subsystem teams are the most affected team type in the AI era. These teams existed because certain technical domains (ML pipelines, real-time video processing, financial calculation engines, low-level performance optimization) required specialist knowledge that generalist stream-aligned team members did not have.

AI Handles Most Specialist Implementation

AI coding agents now handle 60-70% of specialist implementation work that previously required a dedicated complicated-subsystem team. Specific examples:

• ML pipeline code: AI agents generate training pipelines, feature engineering code, model serving infrastructure, and monitoring dashboards. A senior engineer who understands ML concepts but cannot write PyTorch code from memory can now build production ML systems with AI assistance.
• Real-time processing: AI generates WebSocket handlers, event streaming code, and real-time data pipeline configurations. The specialist knowledge required drops from "deep expertise in Kafka internals" to "understanding of event-driven architecture concepts."
• Performance optimization: AI identifies performance bottlenecks and generates optimized code for common patterns (database query optimization, caching strategies, concurrent processing). The cases that still require human specialists are genuinely unusual.
• Infrastructure as code: AI generates and maintains Terraform, CloudFormation, and Kubernetes configurations. The specialist DevOps knowledge required drops significantly.

What Remains

Not everything can be absorbed by stream-aligned teams with AI. The 30-40% of specialist work that still requires dedicated teams:

• Novel algorithm design: When the problem does not match existing patterns in AI training data, you need humans who understand the underlying mathematics and can design from first principles.
• Hardware-adjacent optimization: GPU kernel programming, SIMD optimization, custom hardware integration — these require deep knowledge that AI agents cannot reliably provide because the feedback loop (does it actually run faster on this specific hardware?) requires physical experimentation.
• Regulatory compliance implementation: Financial regulations, healthcare data handling, privacy law compliance — these require human judgment about legal interpretation that AI cannot be trusted with.
• Security-critical systems: Cryptographic implementations, authentication protocols, and security-sensitive infrastructure where an AI hallucination could create a vulnerability.

The Practical Approach: Embed, Don't Isolate

Instead of maintaining standalone complicated-subsystem teams, AI-era orgs increasingly embed specialists in stream-aligned teams. A pod of 4 generalist engineers plus 1 ML specialist handles both the product feature work and the ML-specific implementation, with AI bridging the knowledge gap between the generalist and the specialist.

This approach has a specific advantage: it eliminates the handoff between stream-aligned and complicated-subsystem teams. In traditional orgs, that handoff was the primary source of delays and miscommunication. The stream-aligned team writes a spec, the complicated-subsystem team interprets it (often differently), implements it, hands it back, and the stream-aligned team discovers it does not quite match their needs. Embedding the specialist eliminates this cycle.

The cases where you still need a standalone complicated-subsystem team: when the specialist work serves multiple stream-aligned teams (a shared ML platform, a central search engine, a common recommendation system) and cannot be decomposed into per-team responsibilities. Even here, AI reduces the team size from the traditional 5-8 specialists to 3-4.

Interaction Modes in the AI Era

Team Topologies defines three interaction modes: collaboration, X-as-a-Service, and facilitating. All three shift in AI-era orgs.

Collaboration Mode: Reserved for Novel Problems

Collaboration (two teams working closely together for a defined period) was the most common interaction mode in traditional orgs. Teams collaborated to build new shared capabilities, design cross-team features, or migrate shared infrastructure.

In AI-era orgs, collaboration mode becomes reserved for genuinely novel problems. The routine collaboration needs — "help us set up a new service," "help us integrate with your API," "help us adopt this new framework" — are absorbed by self-service tooling and AI-assisted onboarding.

The test for whether collaboration is warranted: "Can a competent engineer with AI tools figure this out from our documentation and self-service tooling in less than 2 days?" If yes, do not start a collaboration engagement. If no, fix the documentation or tooling first. Only if the problem is genuinely too novel for self-service should you enter collaboration mode.

X-as-a-Service Mode: The Default

X-as-a-Service (one team provides a capability that other teams consume through a well-defined interface) becomes the dominant interaction mode. AI enables this shift because:

• AI-assisted documentation: Platform and enabling teams can maintain comprehensive, current documentation with AI assistance, making self-service viable for more use cases.
• AI-assisted interfaces: CLI tools, chatbots, and self-service portals powered by AI handle the "explain how to use this" function that previously required a human from the providing team.
• AI-generated integration code: When a stream-aligned team needs to integrate with a platform service, AI generates the integration code from the service's API spec. The "how to use this" knowledge transfer happens through AI, not through human collaboration.

The platform team's primary job becomes maintaining the service interface quality: clear APIs, comprehensive documentation, working examples, and AI context files that enable stream-aligned teams to self-serve effectively.

Facilitating Mode: AI-Augmented Knowledge Transfer

Facilitating (an enabling team helps a stream-aligned team develop a new capability) becomes more efficient with AI but does not disappear. The enabling team's facilitation sessions are shorter and more focused because:

• The enabling team provides curated AI context files that cover 60-70% of the knowledge transfer
• The stream-aligned team prepares by working through AI-assisted tutorials before the facilitation session
• The facilitation session focuses on the 30-40% of knowledge that requires human-to-human transfer: organizational context, political considerations, judgment calls

Net effect: facilitation engagements that took 3-4 weeks in traditional orgs take 1-2 weeks in AI-era orgs, with the same or better knowledge transfer outcomes.

Conway's Law in the AI Era

Conway's Law states that organizations design systems that mirror their communication structures. This is as true in AI-era orgs as in traditional ones, but the "communication structure" now includes AI-mediated channels.

AI as a Communication Channel

In AI-augmented engineering, communication does not only happen through meetings, Slack, and documents. It happens through:

• AI context files: CLAUDE.md, cursor rules, and similar project-level instruction files that communicate architectural decisions, coding conventions, and organizational standards to AI agents (and indirectly to the engineers who read AI output).
• API specs: OpenAPI specifications, GraphQL schemas, and protocol buffers that serve as both human documentation and AI input. AI agents use these to generate integration code, test suites, and mock servers.
• Automated documentation: AI-generated and AI-maintained documentation that keeps system knowledge current without manual effort. This documentation mediates between teams by providing a shared, always-current understanding of each team's interfaces.

The practical implication: teams that maintain high-quality AI context artifacts produce better-integrated systems because their AI agents have better cross-team context. The platform team's context engineering standards directly improve system architecture through Conway's Law.

The Inverse Conway Maneuver With AI

The "Inverse Conway Maneuver" (structuring your organization to produce the system architecture you want) becomes more powerful with AI because AI amplifies organizational patterns. If you structure teams around well-defined domain boundaries with clear API contracts, AI agents reinforce those boundaries by generating code that respects the contracts. If you structure teams with fuzzy boundaries and implicit contracts, AI agents produce code that creates coupling because the boundaries are not explicit in the context.

This is a strong argument for formal team APIs and explicit domain boundaries. In traditional orgs, implicit boundaries worked at small scale because humans negotiated the fuzzy edges through conversation. In AI-era orgs, implicit boundaries fail faster because AI agents take the ambiguity at face value and produce code that does not respect the intended separation.

The AI-Era Team Topology Map

Putting it all together, here is how a typical AI-era engineering org topology looks at different 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

Migrating to AI-Era Topologies

If you have an existing Team Topologies implementation, do not reorganize everything at once. The migration path:

Phase 1: Pilot (Month 1-3)

Pick one stream-aligned team and shrink it from 7-9 to 4-5 engineers. Add heavy AI augmentation. Move the "extra" engineers to other teams or a new pod. Measure the pilot team's output against a comparable traditional team for one quarter. This calibrates your expectations and surfaces problems before you scale the approach.

Phase 2: Platform Investment (Month 2-4)

While the pilot runs, invest in platform team capabilities. Build the service template with AI context files. Standardize the deployment pipeline. Create the self-service provisioning tools. The platform investment needs to lead the stream-aligned team migration by 1-2 months because the smaller pods depend on platform consistency to be effective.

Phase 3: Gradual Migration (Month 4-9)

Migrate stream-aligned teams pod by pod. Each migration follows the same pattern: shrink, add AI, redistribute. Do 2-3 teams per month. After each batch, assess: Are the smaller pods maintaining output? Are cross-pod dependencies manageable? Is the platform team keeping up with demand?

Phase 4: Topology Refinement (Month 9-12)

After all stream-aligned teams have migrated, assess the complicated-subsystem and enabling team changes. Dissolve complicated-subsystem teams that are no longer justified. Stand up the AI enabling team if you haven't already. Adjust platform team sizing based on actual demand.

Common Mistakes

These are the errors I see most often when organizations adapt Team Topologies for AI:

• Shrinking teams without adding AI augmentation. Making teams smaller without providing AI tools just makes them understaffed. The team size reduction only works if AI absorbs the implementation workload.
• Skipping platform investment. Smaller, faster teams without platform standardization creates fragmentation that is worse than what existed before. The platform team needs to lead or parallel the stream-aligned team migration.
• Eliminating all complicated-subsystem teams. Some specialist work genuinely requires dedicated teams. The 60-70% figure is an average; assess each subsystem individually.
• Treating AI enabling as temporary. The AI tooling landscape changes quarterly. The enabling team needs to be permanent, or you lose the evaluation and training function every time you disband them.
• Keeping the same interaction modes. If you shrink teams but keep the same collaboration-heavy interaction patterns, you have not gained anything. The shift to X-as-a-Service is essential for the smaller teams to maintain their velocity.

Conclusion

Team Topologies remains the best framework for engineering org design. The four team types and three interaction modes provide the right level of abstraction for thinking about how to structure engineering organizations.

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. And the dominant interaction mode shifts from collaboration to X-as-a-Service.

The organizations that adapt Team Topologies successfully for AI are the ones that understand the cognitive load shift: less implementation load, more integration load. Size your teams for the implementation load (smaller). Invest in platform and coordination structures for the integration load (more). Get both right, and you have an engineering organization that produces more with less while maintaining architectural coherence.

---

For guidance on implementing Team Topologies in your AI-augmented engineering organization, schedule a consultation.

Frequently Asked Questions

Is Team Topologies still relevant with AI?

Yes, but it needs adaptation. The four fundamental team types (stream-aligned, platform, enabling, complicated-subsystem) remain valid abstractions. What changes is the sizing, timing, and relative importance of each type. Stream-aligned teams get smaller, platform teams become more critical, enabling teams shift focus to AI adoption, and complicated-subsystem teams largely dissolve. The interaction modes (collaboration, X-as-a-Service, facilitating) also 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 argues that teams should be sized to manage cognitive load. AI changes the cognitive load equation in two ways: it reduces implementation cognitive load (AI handles routine coding, so engineers think less about syntax and library APIs) but increases integration cognitive load (each team ships more, creating more API surface area and more cross-team dependencies to track). 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 registries, evaluation frameworks, cost monitoring, context engineering templates) belongs in the platform team. Letting each stream-aligned team build its own AI infrastructure creates the same fragmentation problem that platform teams were invented 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 (organizations design systems that mirror their communication structure) still holds, but AI adds a new wrinkle. AI agents communicate through code, documentation, and API contracts, not through Slack and meetings. This means the 'communication structure' that shapes system design now includes human-to-human, human-to-AI, and AI-to-API channels. Organizations that standardize their AI-readable artifacts (specs, context files, API schemas) produce more coherent systems because the AI agents across teams are working from compatible information.

How do interaction modes change with AI?

The three interaction modes (collaboration, X-as-a-Service, facilitating) shift heavily toward 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 needing to schedule a meeting. Collaboration mode becomes reserved for genuinely novel problems. Facilitating mode shifts from capability building to AI workflow optimization.

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

Do not reorganize 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 your platform team investment and enabling team focus. Then expand pod by pod over 2-3 quarters. Reorganizing the entire org simultaneously creates a productivity dip that takes 6+ months to recover from. Gradual migration lets you learn and adjust.