Who Does What? Team Topologies for the Agentic Platform
Pangram verdict · v3.3
We believe that this document is mainly AI-generated, with some AI-assisted content.
AI likelihood · overall
AIArticle text · 1,788 words · 5 segments analyzed
The agentic platform defines what needs to be provided. Team Topologies defines who provides it, and how teams interact to make it happen.
In the first article of this series, we asked the what: which systemic capabilities (context, guardrails, tooling) are needed to produce reliable applications at scale. The answer was the agentic platform, and at its core, the agentic factory: the mechanism where agents plan, code, test, and ship. But a platform does not build itself, and more importantly, it is not consumed the same way it is built. A fundamental question remains: who does what? The real problem: the cognitive load of agentic production Before asking who does what, we need to understand why the question is different this time. Building an application used to mean orchestrating roles over time: one person designed, another challenged the architecture, a third tested, a fourth deployed. The complexity was real, but distributed — across several people, and spread over time. Each role asked its questions in turn. Agents change the equation. They do not ask questions: they produce answers, immediately. They never tire, never rest, never wait. Their speed is their strength, and their trap. All the questions that roles used to raise sequentially, the human steering the agent must now anticipate upfront, in parallel, in the short window of a prompt. Poorly framed, an agent does not slow down: it produces fast, and off target. Cognitive load does not disappear with AI — it transforms. It first becomes an anticipation burden: everything the human must foresee before launching the agent, or the output will fall short. And because the agent produces continuously, without human rhythm, it also becomes a cognitive throughput problem: a sustained flow of decisions over time. The real challenge of agentic production at scale is not that complexity grows — it is that complexity compresses, onto a single person and into a timeframe they cannot absorb alone. This is exactly what the platform addresses. It absorbs part of the anticipation burden by making itself queryable by the agent: “don’t worry about security” means the agent will ask the platform how to proceed, and deterministic controls will enforce the outcome downstream.
The platform does not eliminate thinking — it narrows the set of questions the human must carry, letting them focus on what truly matters: the contested, structural decisions where human judgment remains irreplaceable. Cognitive load is therefore no longer just, as Skelton and Pais describe, a quantity to distribute across teams. In the agentic world, it is also a throughput to regulate over time. Team Topologies tells us how to distribute; we still need to say how to absorb. That is the subject of this article. Team Topologies, an answer to the load To tackle this load problem, we draw on Team Topologies1, an organizational model that defines four team types and three interaction modes. This is no coincidence: its founding argument is precisely cognitive load — a team can only be effective if it carries no more complexity than it can absorb. Skelton and Pais reason about structural load, to be distributed across teams; we extend it to the dynamic load of the agentic production act, described above. The model gives us the grid for distributing what can be distributed, and identifying what the platform must absorb. Let us state our position upfront: what follows is a forward-looking conviction, the organizational target toward which, in our view, application production by agents is heading. The question is no longer what the factory needs, but who operates it. This is exactly what the agentic platform does: it absorbs technical complexity so that business teams carry only the cognitive load of their domain. The developer shifts: they build the platform that enables others to produce. Symmetrically, application production opens up to business teams through agents. What we keep and what we adapt Applying Team Topologies to the agentic context requires clarity about our departures. To avoid hollowing out the model while claiming its name, here is the line. What we keep intact: the guiding principle of cognitive load; the four team types; the three interaction modes; the shift from collaboration to X-as-a-Service at maturity.
What we adapt, and why:
stream-aligned teams can be non-technical (business), because the platform absorbs the technical load; they do not carry end-to-end operational responsibility (run, incidents), which the platform absorbs; enabling is not merely transient: it is structurally compensated by the platform, since the producer is no longer a developer; cognitive load is no longer just a quantity to distribute across teams, but a throughput to regulate over time: the platform absorbs the anticipation burden upstream of agentic production.
These adaptations do not betray Skelton and Pais’s intent: they apply it to a context they had not anticipated — one where agents produce, and humans orchestrate. Four team types, one objective The objective is shared: produce reliable applications, consistent with organizational standards, at scale. But the roles are distinct.
The four Team Topologies team types applied to the agentic platform. Each team plays a specific role in the production chain. Stream-aligned teams: producing applications Stream-aligned teams are product teams. They drive the AI orchestrator (the engine of the agentic factory described in the first article), define business intent, and supply the dynamic context: specifications, product-specific guardrails, domain knowledge. The transformation runs deep: these teams no longer need to be composed of developers. Increasingly, they are business teams (domain experts, product managers, analysts) who directly drive production through agents. This shift brings production closer to the need, but it carries a risk: these teams may not always appreciate the implications of putting an application into production. This is precisely why the other team types exist. A point of rigor is in order. In classic Team Topologies, a stream-aligned team is responsible end to end for a value stream, including operations and incidents. Here, the platform absorbs operational responsibility (deployment, monitoring, rollback). The stream-aligned team remains responsible for the what (intent, business quality); the platform guarantees the how (reliable production deployment). This split requires a sufficiently mature platform. On-call duty is distributed accordingly: the platform team handles systemic incidents (infrastructure, guardrails, pipelines); business decisions (content removal, product rollback) stay with the stream-aligned team. This what/how boundary is more porous than it appears. Brand consistency, for example, is a business concern (the what), but its verification is automated by the platform (the how).
The platform guarantees minimums; it does not guarantee business excellence. The platform team: industrializing capabilities The platform team provides the three systemic pillars as X-as-a-Service:
Systemic context: instructions, roles, shared business knowledge, memory, examples and patterns Systemic guardrails: security, reliability, brand consistency, conventions Tooling and skills: MCP servers, CI/CD pipelines, evaluations, shared skills
The model is self-service: documented, versioned, consumable without friction. Design effort is invested once, then applied to every project. A platform is “mature” when… To keep the word from remaining an empty promise, here are the observable criteria:
Guardrail coverage: critical dimensions (security, reliability, brand consistency) are covered automatically, not by verbal agreement Pipeline reliability: deployment success rate is measurable and tracked (internal SLA) Self-service share: the majority of deployments happen without platform team intervention Documentation completeness: every exposed capability is documented and accompanied by examples Decision traceability: guardrails produce an audit trail (why a deployment was blocked, which rule was applied, what threshold was breached)
Until these criteria are met, the platform cannot absorb the operational responsibility of stream-aligned teams, and the model relies on enabling to compensate. Enabling teams: bridging the gap The enabling team is temporary by nature. Its goal is not to become indispensable, but to make product teams autonomous. In practice:
Environment provisioning: tools, access, configuration Training: on context packaging, guardrails, orchestrator operation Shift-left on practices (security, testing, quality) until they are encapsulated by the platform
It bridges the gap between business intent and quality requirements. Its role diminishes as product teams gain proficiency and the platform matures. An important nuance: in the agentic world, stream-aligned teams often remain predominantly non-technical. The gap therefore never closes entirely through upskilling alone — it is structurally compensated by the platform. This is not a failure of the model; it is an adaptation to a context where the application producer is no longer a developer. Complicated subsystem teams: mastering technical complexity Complicated subsystem teams work on the most technically demanding aspects of the AI infrastructure. Their expertise is deep and specialized: it must not be diluted across product teams. This team type is not universal. An organization that exclusively consumes model APIs may not need one.
However, as soon as it manages its own models, optimizes inference costs, or faces sovereignty constraints, this team type becomes essential — as it does for evaluation, red-teaming, advanced RAG engineering, or fine-tuning. They collaborate with the platform team on model efficiency, KV cache, sovereign inference, cost optimization, and evaluation. Their work never reaches product teams directly: it flows through the platform. The three interaction modes Team Topologies defines three interaction modes between teams: Facilitating: the enabling team facilitates stream-aligned teams. A temporary interaction, oriented toward autonomy: the enabler teaches the product team to do it themselves. X-as-a-Service: the platform delivers its capabilities as self-service. This is the target interaction — the one that enables scaling. Collaboration: the complicated subsystem team collaborates with the platform team. A deep interaction, justified during the construction phase. At maturity, it evolves into X-as-a-Service: AI efficiency capabilities become consumable services, not permanent construction sites.
Making the model last Defining teams and their interactions is not enough. An organizational model has value only if it outlives its launch. The journey toward autonomy The enabling team’s role is designed to shrink: that is the sign the system is working.
The three interaction modes evolve together: facilitating fades, collaboration gives way to X-as-a-Service, which becomes the dominant mode. This evolution follows two parallel axes that must be distinguished: team maturity and platform maturity. They reinforce each other, but do not progress at the same pace. At startup:
Team side: product teams are discovering context packaging and orchestrator operation. Enabling is omnipresent. Platform side: capabilities are basic (a few guardrails, partial documentation, a still-fragile pipeline). The platform is not yet mature by the criteria defined above.
During maturation:
Team side: product teams have mastered the fundamentals. Enabling becomes targeted (advice on a specific guardrail, feedback on a complex prompt). Platform side: guardrails expand, self-service progresses, documentation takes shape. Collaboration with complicated subsystems starts transforming into integrated services.
At autonomy:
Team side: product teams are autonomous. Enabling is optional, limited to occasional expertise. Platform side: self-service is complete, guardrails cover critical dimensions, traceability is in place. The dominant interaction is X-as-a-Service.
Enabling disappears because it succeeds, not because it fails.