An agentic platform answers what must exist for agents to ship safely. Team Topologies answers who provides those pieces, and how teams should relate so the whole thing does not collapse into heroics.
Most of the conversation about AI in engineering still orbits tools: which model, which IDE plugin, which evaluation harness. Those choices matter. They are also the easy part. The harder question shows up the moment agents stop answering isolated questions and start producing change at machine tempo — plans, code, tests, pull requests, sometimes the path all the way to production. At that point the organisation has to decide who owns intent, who owns safety, and who absorbs the mess when the two disagree.
That is not a tooling problem. It is an architecture problem in the social sense: boundaries between teams, interfaces that outlive the meeting where they were drawn, and a platform that makes the boring path the default. I keep returning to the same conviction I have about services — get the boundaries wrong and no amount of clever technology rescues you.
The real problem is compression
Building software used to distribute difficulty across people and across time. Someone shaped the design. Someone else challenged the architecture. Testing asked its questions later. Operations asked theirs after that. The complexity was real, but it arrived in turns. Each role had a window in which to think.
Agents change the tempo. They do not wait for the next ceremony. They produce immediately, continuously, and without human rhythm. Every question that used to surface sequentially now has to be anticipated up front — mostly inside the short window of a prompt, a brief, or a ticket that an orchestrator will expand. Frame it poorly and the agent does not slow down. It ships fast and wrong.
Cognitive load, in that world, is no longer only a pile of complexity to spread across teams. It is also a throughput problem: a sustained flow of decisions that a single person cannot absorb alone. There is an anticipation burden before the agent starts, and a decision rate while it runs. Platform engineering has always been about reducing the number of things product teams must invent. Agentic production makes that job sharper. The platform has to absorb questions the human should not have to keep in working memory — security posture, deployment mechanics, coding standards, the shape of an acceptable change — so attention stays on the contested calls where judgment still matters.
Team Topologies is a useful way to reason about cognitive load as a structural quantity. I want to keep that model and extend it to the dynamic load of agentic work: not only who carries which subsystem, but who regulates the flow of decisions when generation is cheap and review is expensive.
What we keep, what we adapt
Borrowing Team Topologies without keeping its mechanics is how you end up with renamed squads and the same bottlenecks. Here is the line I would draw.
What stays intact:
- Cognitive load as the organising constraint.
- Four team types and three interaction modes.
- The journey from close collaboration toward a clear X-as-a-Service relationship as capabilities mature.
What changes in an agentic setting — and why:
- Stream-aligned teams stay engineering teams, but become more domain-centric as more technical load moves into the platform — not “business replaces engineering.”
- End-to-end “you build it, you run it” softens: the platform absorbs much of run, rollback, and systemic incident response.
- Enabling work becomes more structural, because domain experts are closer to production and need lasting help packaging context and reading platform feedback.
- Cognitive load is treated as a flow to regulate over time, not only a static volume to redistribute across org charts.
Those adaptations are not a betrayal of the original intent. They are what the model looks like when one of the producers does not get tired and does not know when to stop.
Four team types, one objective
The shared objective is straightforward: reliable applications that meet organisational standards, produced at a pace the business can actually use. The roles stay distinct on purpose.
Stream-aligned teams: driving production
Stream-aligned teams still own a value stream. That part of Team Topologies does not go away — and I am not arguing that they stop being engineering teams. The useful shift is compositional: as agents and platforms take on more mechanical delivery work, stream teams can spend a larger share of their attention on domain intent, product trade-offs, and judging whether the result is good enough for users. Engineering effort concentrates where leverage is highest — platforms, guardrails, evaluation, and the hard subsystems — while stream teams become more domain-centric, not non-technical.
Agents collapse a lot of the old translation layer between “what we want” and “what gets typed,” which pulls product and domain expertise closer to the production loop. That proximity is the upside. The downside is familiar: faster generation makes it easier to ship a change whose operational implications nobody has absorbed. The other team types exist so that gap does not become an outage.
Classic Team Topologies expects stream-aligned teams to own the stream end to end, including operations. I would split that more carefully here. The stream still owns the what — intent, domain quality, product trade-offs — and still needs engineers who can challenge an agent’s output. The platform owns more of the how — safe deployment, observability baselines, deterministic guardrails — so every stream is not reinventing an SRE and evaluation practice from scratch. On-call follows the same cut: platform for systemic failure; stream-aligned for product decisions in their domain.
The platform team: building the engine
If stream-aligned teams steer, the platform team builds the vehicle and the road. I would organise that work around five self-service pillars:
- Context — shared instructions, roles, patterns, examples, and memory agents can query without reinventing house style every run.
- Deterministic guardrails — security, reliability, compliance, and conventions enforced in code and pipeline, not only as polite suggestions in a system prompt.
- Agentic tooling — shared skills, MCP-style tool servers, CI/CD, evaluation harnesses, and the boring glue that makes agents useful beyond a demo.
- Observability — traces across agent steps, prompt and tool versions, evaluation results, audit logs, replay, and cost attribution. Agent platforms live or die by whether you can see what happened and reproduce it.
- Execution — the runtime that actually runs models and workflows with tenancy, isolation, and capacity in mind.
The engagement model should be X-as-a-Service: documented, versioned, consumable without a calendar invite. Design effort is spent once and leveraged across every agent-driven stream. That is the same product instinct good internal platforms already have — release path as a product, interfaces as promises — applied to a world where the consumer might be an agent as often as a human.
A platform is mature enough to absorb operational load when:
- Critical controls are hardcoded and testable, not only requested in natural language.
- Deployment and pipeline health are measured against internal SLOs.
- Most deliveries happen without a platform engineer in the loop.
- Capabilities are documented for agents as well as people — examples, schemas, failure modes.
- Every guardrail intervention leaves a trail: what blocked, which rule, which threshold.
- You can replay a run from stored prompts, tool calls, and model versions — and attribute cost to a stream, not a mystery bill.
Until those are true, pretend self-service is just a faster way to create shadow IT. Lean on enabling teams and keep operational responsibility closer to people who can still see the machinery.
Enabling teams: bridging the gap
Enabling teams help others become effective. In the classic model they are temporary — upskill, then leave. During an agentic transition they provision environments, teach people how to package context, explain what guardrails will and will not catch, and manually hold the line on quality until the platform can enforce it.
Here the model strains in a useful way. You can upskill stream engineers on agent workflows until they are autonomous with the platform. You cannot — and should not — expect every domain specialist pulled into the loop to become a platform engineer. The durable job of enabling is to find the floor of what stream teams should never have to reinvent, and turn that into a platform requirement. Training closes some of the gap; automation and observability close the rest. Pretending otherwise is how you get permanent pairing theatre.
Complicated-subsystem teams: optional deep tech
Complicated-subsystem teams encapsulate expertise that would wreck cognitive load if spread across every stream — fine-tuning, inference optimisation, serious evaluation science, red-teaming, data residency constraints that do not fit a managed API. If you are only wrapping a hosted model, you may not need this type. The moment you host weights, chase unit economics, or treat evaluation as a product surface, you do. Keep that talent concentrated. Diluting it is how platforms get clever and surprising, which is the opposite of what you want at midnight.
How the teams interact
Team types without interaction modes are just a prettier org chart. The three modes still earn their keep.
Collaboration is right while a capability is forming — platform and stream inventing a new guardrail together, enabling and domain experts shaping the first agent workflow. It is expensive on purpose. Use it to learn, then encode the learning.
X-as-a-Service is the mature posture for the platform: a clear interface, docs, examples, SLOs, and a support path that is not “ping me on Slack.” Agents make this stricter. If a human needs a meeting to use the platform, an agent will invent a workaround.
Facilitating is how enabling teams work — help others become effective, then step back. In agentic organisations that step back is partial. The relationship stays available because the knowledge gap is structural, even when individual workflows are smooth.
A healthy evolution looks familiar: early collaboration around a new surface, then a hard cut to service mode once the interface is honest. What should not happen is permanent collaboration disguised as “partnership,” where the platform team becomes a ticket queue with nicer language.
Boundaries are still promises
None of this requires believing that engineering leaves the stream, or that developers disappear. More engineering effort moves toward the platform and the deep subsystems — the conditions under which good software can keep being written — while stream teams keep ownership of the value stream and get more domain-centric in how they spend their time. That shift only works if the platform is boring, legible, and strict about the things that must not be left to vibe.
Architecture remains a social act. A boundary between stream and platform is also a boundary between two kinds of accountability. An interface is a promise you have to keep after the demo is over. Get those right and agents become leverage. Get them wrong and you have only accelerated the rate at which shortcuts compound.
The useful question is not whether agents will ship software. They already do. The useful question is who does what when they do — and whether your organisation designed an answer, or discovered one in an incident review.
Further reading: Martin Fowler on Team Topologies — a clear overview of the model this essay builds on.