Who Does What? Team Topologies for the Agentic Platform

owulveryck1 pts0 comments

Who Does What? Team Topologies for the Agentic Platform - Unladen swallow - Olivier Wulveryck

Skip to content

owulveryck's blog

Who Does What? Team Topologies for the Agentic Platform

Olivier Wulveryck — 2026-06-22 — https://blog.owulveryck.info/2026/06/22/who-does-what-team-topologies-for-the-agentic-platform.html

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...

platform agentic team load topologies cognitive

Related Articles