Team Topologies for Human-Plus-Agent Teams: Where Agents Actually Fit

By Victor Hoang · Updated Sep 22, 2026

Team Topologies is Matthew Skelton and Manuel Pais's framework for organizing teams around four types (stream-aligned, enabling, complicated-subsystem, and platform) so that work flows with the least possible coordination overhead. Applied to teams where an AI agent does part of the work, the same four types still hold, but two things change: cognitive load gets a new category (owning output you didn't personally produce), and Conway's Law now applies to a system where part of the "team" doing the work is software, not just people. This is the structural half of a broader shift covered in what is the future of work.

Key Facts

• Team Topologies defines four fundamental team types: stream-aligned (aligned to a flow of business value), enabling (helps a stream-aligned team overcome obstacles and detects missing capabilities), complicated-subsystem (owns work needing deep specialist or mathematical expertise), and platform (provides a compelling internal product that accelerates stream-aligned teams). Source: Team Topologies, "Key concepts and practices"
• Melvin Conway's 1968 paper stated the original thesis: "Any organization that designs a system... will inevitably produce a design whose structure is a copy of the organization's communication structure." He also noted that possible communication paths in a group grow roughly with the square of its size. Source: Melvin Conway, "How Do Committees Invent?" (Datamation, 1968)
• In DORA's 2025 research, 90% of organizations have adopted at least one internal platform, and the report found a direct correlation between high platform quality and an organization's ability to get value from AI adoption. Source: Google Cloud, announcing the 2025 DORA Report
• Microsoft's 2026 Work Trend Index found organizational factors (culture, manager support, and talent practices) account for more than twice the measured impact on AI outcomes that individual factors do, and identified "Frontier" professionals, workers where individual capability and organizational readiness reinforce each other, as roughly 19% of the AI-using workforce surveyed. Source: Microsoft WorkLab, "2026 Work Trend Index"

What Team Topologies Actually Says

Skelton and Pais built Team Topologies to solve a specific problem: org charts are usually drawn around reporting lines, not how work actually flows, and that mismatch shows up as slow deployments, unclear ownership, and teams that can't ship without three other teams' sign-off. Their answer is to organize around exactly four team types and be deliberate about how those teams interact, rather than letting interaction patterns emerge by accident.

A stream-aligned team owns a slice of business value end to end and is set up to deliver it with minimal hand-offs. An enabling team exists to close a capability gap in another team, on purpose and temporarily, then step back once the gap is closed. A complicated-subsystem team takes on the piece of the system that genuinely needs deep, narrow expertise (the payments engine, the recommendation model, the pricing algorithm) so that stream-aligned teams don't each need their own specialist. A platform team builds the internal product, the shared infrastructure, tooling, and self-service capability, that lets stream-aligned teams move fast without reinventing the same plumbing five times over.

None of that vocabulary needs to change to describe a team where some of the "work" is done by an AI agent instead of a person. What needs adding is a clear answer to two questions Skelton and Pais weren't writing for: where does the agent's work actually sit inside these four types, and what happens to cognitive load when a person is accountable for output they didn't personally produce.

Cognitive load was always the real constraint

Team Topologies treats team size and scope as downstream of one variable: cognitive load, the total mental effort a team can sustain before quality and speed both degrade. A stream-aligned team that gets handed a fifth unrelated responsibility doesn't get more capable, it gets slower and sloppier at all five. That's why the framework insists on narrow, well-bounded team responsibilities rather than broad ones.

Agents change what fills that budget without necessarily reducing the total. A team that used to spend its cognitive load producing a deliverable now spends part of it specifying the task precisely enough for an agent to attempt it, and part of it verifying output that looks confident whether or not it's correct. From Doer to Orchestrator covers this shift at the level of one person's job. At the team level, the same shift means a team's cognitive load has a new line item: accountability load, the ongoing cost of owning a decision or an artifact that an agent, not a teammate, actually generated. Ignore that line item when sizing a team and you get a stream-aligned team that looks lightly staffed on paper and is quietly drowning in unreviewed agent output.

Where Agents Sit in Each Team Type

The honest answer is that agents don't create a fifth team type. They change the internal composition and the interaction load of the four that already exist.

Stream-aligned teams: the agent works inside the flow, a human still owns the outcome

This is where most agent use lives today, and it should stay the default. An agent drafts the code, the campaign copy, the support reply, or the first-pass analysis, and a named person on the team remains accountable for what ships. The team's scope doesn't change; its internal division of labor does. Watch for scope creep in the other direction: a stream-aligned team that quietly starts building and maintaining its own agent infrastructure (prompt libraries, evaluation harnesses, tool connectors) on top of its real product work has taken on a second, unbounded job it didn't sign up for. That's the augmentation, not automation pattern working as intended, until the infrastructure work outgrows the team's cognitive budget.

Enabling teams: agents make the skill transfer faster, not automatic

Skelton and Pais designed enabling teams to be temporary by nature: they exist to close a specific capability gap and disband or move on once the gap is closed. In a human-plus-agent context, this is the team that teaches other stream-aligned teams how to write a usable agent brief, how to set an evaluation bar, and how to catch a plausible-but-wrong output before it ships. The temptation is to let an enabling team quietly become a permanent shadow platform, doing the work rather than transferring the skill. That defeats the purpose and hides the real cognitive load inside a team nobody is tracking against the framework.

Complicated-subsystem teams: the specialist rarely gets replaced, their reach gets extended

A complicated-subsystem team exists because some piece of the system genuinely requires deep, hard-to-distribute expertise. Agents are a poor fit to own that subsystem outright, precisely because the reason the team exists is that mistakes there are expensive and hard to catch without the specialist knowledge in the first place. Where agents help here is reach: a specialist reviewing ten AI-drafted first passes of a pricing model change is a different, and often better, use of scarce expertise than that same specialist hand-building all ten from scratch. That's human-in-the-loop working as intended: the specialist stays the final check, not a rubber stamp. The subsystem team's headcount might shrink or its output might grow, but its ownership boundary and its verification standard should not move.

Platform teams: why an internal AI platform team shows up almost immediately

This is the team type that expands fastest once more than two or three stream-aligned teams start using agents independently. Left alone, each team tends to solve the same problems separately: which model to call, how to handle credentials and cost limits, how to log what an agent did for audit purposes, how to connect it to internal data and tools safely. DORA's 2025 research found this pattern isn't unique to AI: 90% of organizations had already adopted at least one internal platform for this reason, and platform quality directly predicted whether AI adoption became real performance gain or scattered, duplicated effort.

An internal AI platform team forms for the same reason a shared DevOps platform team forms: building the plumbing once, well, and offering it as a self-service capability beats every stream-aligned team building its own. What it typically owns: shared connections to model providers, an MCP-based interop layer so agents reach internal tools and data consistently instead of through five one-off integrations, cost and usage guardrails, and a shared evaluation and logging standard so nobody reinvents "how do we know this output is good enough" from scratch. It's also the natural owner of anything involving multiple agents coordinating on a task, the kind of shared, high-stakes plumbing no single stream-aligned team should own alone. Rework treats this the same way on the product side: standardizing agent-facing workflows and MCP interop is Work Ops territory, because that plumbing shouldn't live redundantly inside every team that touches it.

Conway's Law When Part of the Team Is Software

Conway's original 1968 observation was about people: an organization designing a system tends to produce a design that mirrors its own communication structure, because the interfaces between modules end up matching the interfaces between the teams that built them. He also pointed out something less quoted but just as useful: the number of possible communication paths in a group grows roughly with the square of its size, which is exactly why large, loosely coordinated groups produce sprawling, poorly-integrated designs.

That logic doesn't stop applying once an agent does part of the work. An agent's tool connections and access boundaries are themselves an interface, structurally no different from the API boundary between two human teams. If five stream-aligned teams each wire up their own version of "an agent that can read the CRM and draft an email," you get five slightly different integrations, five failure modes, and five places a security review has to check separately. That's Conway's Law playing out exactly as predicted, with an agent's tool access standing in for a communication channel.

The useful move here is the same one Team Topologies borrows from Conway's original insight: the inverse Conway maneuver, deliberately shaping the org structure you want in order to get the system architecture you want, rather than discovering your architecture by accident after the org chart is already set. If the goal is one coherent, auditable way agents connect to internal systems, the org has to draw a clear boundary (usually the platform team) that owns that interface, instead of leaving five stream-aligned teams to independently reinvent it and calling the resulting mess "flexibility."

Four Team Patterns for Human-Plus-Agent Work

None of these are prescriptions to copy exactly. They're recognizable shapes, and most organizations will run more than one at once, at different maturity stages.

A useful diagnostic: if you can't say which of these four shapes a given piece of agent work currently sits in, that's usually the actual problem, not the model you're using or the prompt someone wrote.

Signs Your Topology Hasn't Caught Up

A few symptoms show up reliably in organizations that added agents to their workflows without revisiting team structure:

• Silent duplication. Multiple stream-aligned teams have each built their own version of the same agent capability, because no platform team exists to offer it once. This is the fragmented-Conway pattern above, and it usually surfaces first as a security review finding five different ways agents touch the same customer database.
• Invisible accountability load. A team's staffing plan still reflects "how much work can this team produce," with no accounting for time now spent verifying agent output. This is the team-level version of the AI productivity paradox: activity rises while trustworthy throughput doesn't move the way the activity metrics suggest it should.
• An enabling team that never leaves. A temporary skills transfer has quietly become a team that does the agent work for everyone else, defeating the point of an enabling team and hiding real headcount need inside a team nobody tracks against its actual scope.
• A crossed subsystem boundary. Someone outside the specialist team started using an agent to generate output in a domain that used to require the subsystem team's sign-off, and nobody updated who's actually accountable for the result.

How to Start Applying This

The order matters less than doing it deliberately rather than letting it happen by accident:

1. Map current teams against the four types, honestly, not aspirationally. Most organizations find informal platform work already happening inside two or three stream-aligned teams, unlabeled and uncoordinated.
2. Ask where accountability load has shifted, and check that against actual staffing. If verification time has grown and headcount hasn't, that team's real cognitive load is higher than its org chart suggests.
3. Decide, on purpose, when a platform team is worth standing up. DORA's finding that platform quality predicts AI's organizational payoff is a useful gut check: visible duplication across teams usually means the investment pays for itself.
4. Give enabling teams an exit condition before they start. Define what "the gap is closed" looks like up front, so the team has a natural point to disband rather than becoming a permanent, unaccounted-for function.
5. Protect the complicated-subsystem boundary explicitly. Write down which decisions still require the specialist team's sign-off regardless of what generated the first draft, and treat skipping that boundary as an incident, not an efficiency win.

None of this is a one-time reorg. Microsoft's own framing of the "agent boss" role and the frontier firm treats human-agent structure as an ongoing operating question, not a chart drawn once and filed away, and building an AI-ready culture is what keeps it from drifting back into old habits within a quarter. Human-agent teams already covers the norms and trust side of this shift, how people build working relationships with agents day to day. This is the structural half of the same problem, and the two only work if someone actually owns the org-design decision rather than each team improvising its own answer.

A team chart that never gets redrawn after agents show up isn't neutral. The duplication, the unaccounted verification time, and the unclear ownership happen anyway, quietly, inside whatever structure existed before anyone thought to ask the question on purpose.