{"slug": "who-does-what-team-topologies-for-the-agentic-platform", "title": "Who Does What? Team Topologies for the Agentic Platform", "summary": "The article extends Team Topologies to agentic platforms, arguing that AI agents compress cognitive load onto individuals, requiring platforms to absorb technical complexity and regulate decision throughput. It proposes using the framework's team types and interaction modes to distribute structural load and identify what the internal platform must handle.", "body_md": "The agentic platform defines what needs to be provided. Team Topologies defines who provides it, and how teams interact to make it happen.\n\nThis is a second version more human written. The first version was roughly a translation made by AI. This version is human-edited. Hopefully it will be easier to read by a human.\n\nIn [the first article of this series](https://blog.owulveryck.info/2026/06/19/vibe-coding-at-scale-engineering-strikes-back.html), 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.\n\nBut 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?**\n\n*Before asking who does what, we need to understand why the question is different this time.*\n\nBuilding a software application is about orchestrating roles over time: a designer, an architect, a tester, and an operations engineer. The overall complexity is real, but it is **distributed** across several people and spread out over time. Each role asks its questions in turn.\n\nAI agents change the equation. They move beyond answering isolated questions to continuously generating output. Because they execute instantly, the traditional sequential process of problem-solving breaks down. All those questions must now be anticipated by the human in command and fit into the short window of a prompt. If poorly framed, an agent does not slow down: it produces fast, but off-target.\n\nCognitive load does not disappear with AI: it transforms. It becomes an **anticipation burden** (everything the human must foresee before launching the process) combined with a **cognitive throughput problem** (sustaining a high-velocity flow of decisions). The real challenge of agentic production at scale is not that complexity grows; it is that complexity compresses onto a single person over a timeframe they cannot absorb alone.\n\nThis is exactly what the platform addresses. It absorbs part of the anticipation burden by making itself **queryable by the agent**: telling the agent “don’t worry about security” means it 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 handle**, letting them focus on what truly matters: the contested, structural decisions where human judgment remains irreplaceable.\n\nCognitive 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 figure out how to absorb. That is the subject of this article.\n\nTo tackle this bottleneck, we can leverage *Team Topologies* 1, an organizational model that defines four team types and three interaction modes.\n\n“All models are wrong, but some are useful.” — George Box\n\nThis framework has a proven track record in engineering organizations. Its founding argument **is precisely cognitive load**: a team can only be effective if it carries no more complexity than it can absorb.\n\nSkelton and Pais reason about *structural* load, which is distributed across teams. I want to extend this to the *dynamic* load of agentic production. The model gives us a framework for distributing what can be distributed, and identifying what the internal platform (defined in the previous article) must absorb.\n\nTo be clear: what follows is a **forward-looking conviction**. It is the organizational target toward which I believe AI-driven application production is heading. The question here is no longer *what the factory needs*, but *who operates it*.\n\nThis is exactly the purpose of the agentic platform as I envision it: it **absorbs technical complexity** so that business teams only carry the cognitive load of their specific domain. The role of the developer shifts: they build the platform that enables others to produce. The mirror effect is that application development opens up to business teams, empowered by an AI-based agentic development team.\n\nApplying *Team Topologies* to an AI-driven context requires clarity on where we follow the model and where we diverge. The goal is to preserve the core mechanics, not just borrow the buzzwords.\n\n**What stays the same:**\n\n**What changes, and why:**\n\nThese adaptations do not betray Skelton and Pais’s original intent. They simply project it into a reality they hadn’t anticipated: a combination of work from human and AI that do not suffer from cognitive load.\n\nThe shared objective across these teams is clear: produce reliable, standardized applications at scale. Their roles, however, remain strictly distinct. Here is a synthesis of how they interact, presented as a “map” (apologies to Simon Wardley, I know this isn’t a real map).\n\n*The four Team Topologies team types applied to the agentic platform. Each team plays a specific role in the production chain.*\n\nNow let’s navigate through all the teams and their roles.\n\nStream-aligned teams are the product teams responsible for delivering core business value. In this model, they drive the AI orchestrator (the engine of the factory described in the previous article), define the business intent, and supply the **dynamic context**: specifications, product-specific guardrails, and domain knowledge.\n\nThe introduction of AI agents fundamentally transforms these teams: they no longer need to be staffed with software engineers. Instead, they are composed of **business experts** (domain specialists, product managers, analysts) who generate applications directly via agents. The traditional translation layer between business requirements and developer implementation is eliminated; the business *builds* the application. While this brings production infinitely closer to the user need, it introduces a major risk: non-technical teams rarely understand the implications of pushing code to production. This is exactly why the other team types are necessary.\n\n**Deviation from the original model:** In classic *Team Topologies*, a stream-aligned team owns the value stream end-to-end, including operations and incidents (“You build it, you run it”). In this agentic model, the **platform absorbs operational responsibility** (deployment, monitoring, rollbacks). The stream-aligned team owns the *what* (business intent and quality); the platform guarantees the *how* (safe, reliable execution). This split requires a highly mature platform. **On-call duty** shifts accordingly: the platform team handles systemic failures (infrastructure, pipeline crashes, guardrail breaches), while business decisions (feature rollbacks, content issues) remain with the stream-aligned team.\n\nThis “what/how” boundary is more permeable than it sounds. Brand consistency, for example, is a business concern (the *what*), but verifying it can be automated by the platform (the *how*). Ultimately, the platform enforces a *baseline of safety and standards*; it does not guarantee business excellence.\n\nThe platform team must provide four core pillars as a self-service offering:\n\nThe engagement model is strictly self-service: everything is documented, versioned, and consumable without friction. The engineering effort is invested once by the platform team and leveraged continuously across all agent-driven projects.\n\nTo ground this in reality, here are the observable criteria a platform must meet to actually empower AI-driven development:\n\nUntil these criteria are met, the platform cannot safely absorb the operational responsibility from the stream-aligned business teams. In the interim, the organization must rely heavily on *enabling teams* to bridge the gap.\n\nThe enabling team exists to bridge the gap between business intent and engineering rigor. In classic *Team Topologies*, this team is strictly temporary—its goal is to upskill product teams and then move on. In the agentic transition, they focus on:\n\n**A Permanent Gap?** Here the model will probably reach a limit. Traditionally, an enabling team upskills developers until they are fully autonomous. But in the agentic world, stream-aligned teams are increasingly non-technical. There is a hard ceiling to how much you can “upskill” domain experts in software engineering; the gap will never close entirely through training alone.\n\nThe platform must provide structural **compensation** for this lack of technical expertise. The enabling team’s ultimate job isn’t just to train the business; it is to identify exactly what the business *cannot* or *should not* learn, and mandate the platform team to automate it. This is not a flaw in the model; it is a necessary adaptation to a reality where the application producer is no longer a software developer.\n\nComplicated subsystem teams tackle the most technically demanding layers of the AI infrastructure. Their expertise is deep and highly specialized; diluting it across individual product teams would be a massive waste of talent and focus.\n\n**This team type is optional.** If your organization simply wraps external LLM APIs, you probably don’t need one. However, the moment you start hosting your own open-weights models, optimizing inference costs, or dealing with strict data sovereignty constraints, this team becomes critical. They handle the heavy lifting of advanced AI engineering: red-teaming, complex RAG architectures, fine-tuning, and custom evaluation frameworks.\n\nThey collaborate closely with the platform team on hard engineering problems like KV cache optimization, sovereign inference pipelines, and compute efficiency. Crucially, their work *never* reaches the stream-aligned product teams directly. It is entirely encapsulated and distributed as a service through the platform.\n\n*Team Topologies* defines three core interaction modes between these teams. There is not much to adapt for the agentic era; the model is mostly suitable out-of-the-box. Here is the map:\n\nDefining teams and their interactions is only the first step. A static blueprint will inevitably fail. As with any framework, adapting it to your context is always better than blindly adopting it (in my experience, blind adoption is the Dire Straits anti-pattern: money for nothing). For this organizational structure to survive contact with reality, it cannot be a one-off reorganization. It must be treated as an ongoing journey toward a specific target of maturity.\n\nThe enabling team’s role is explicitly designed to shrink. That is the ultimate sign the system is working.\n*The three interaction modes evolve together: facilitating fades, collaboration gives way to X-as-a-Service, which becomes the dominant mode.*\n\nThis evolution follows two parallel axes that must be carefully distinguished: **team maturity** and **platform maturity**. They reinforce each other, but they do not progress at the exact same pace.\n**In the beginning:**\n\n**During maturation:**\n\n**At full autonomy:**\n\nThe enabling team disappears because it succeeds, not because it fails.\n\nLet’s look at how this plays out once the organization reaches **full autonomy**.\nThe marketing team wants to generate a new landing page. They supply the **dynamic context** (campaign intent, key messaging). The platform automatically injects the **systemic context** (brand guidelines, UI components, accessibility rules), and its deterministic guardrails verify brand consistency and security.\n\n*Notice how the roles have evolved:* The enabling team, who heavily supported marketing in the early days, completed their core training three months ago. Today, they only drop in for occasional edge-case support.\n\nMeanwhile, the complicated subsystem team’s deep technical expertise operates silently under the hood. During the build phase, they collaborated with the platform team to design a sovereign AI architecture (optimizing GPU allocation and handling concurrent accesses). They also helped the platform identify exactly which parts of the massive brand context should be frozen. Because of this, the context is now served directly from the KV cache rather than being recomputed on every prompt iteration, drastically reducing the cost per generation.\n\n**The result:** A compliant, secure, fully deployed landing page—without the marketing team ever needing to know what a CI/CD pipeline is.\n\n**The Flip Side:** A team that never “sees” the underlying protection mechanisms loses the ability to judge their relevance or report false positives. Therefore, guardrails must be **transparent in their decisions** (providing clear error messages and audit trails), even if they remain entirely opaque in their implementation.\n\nA solid team structure is not enough. If we truly empower business teams to build and deploy, we must address the foundational question of governance: **who decides an application has the right to exist?** And who manages its lifecycle (its technical debt, its cumulative cost, and its eventual deprecation)?\n\nWithout governance, agentic production just creates *industrialized shadow IT*. The platform acts as the enforcement engine for this governance (similar to the concept of *computational governance* in Data-Mesh). By centralizing deployment, monitoring, and usage metrics, it provides **systemic visibility** across the entire application portfolio.\n\nThrough the platform, we can track active applications, identify abandoned ones, and trigger automated deprecation. If an older application suddenly fails a newly updated security guardrail, it is immediately flagged, not silently forgotten.\n\n**Ease of production must be matched by ease of oversight.** If the platform makes it trivial to spin up an application, it must make it equally trivial to audit how many exist, who owns them, and what they cost.\n\nSpecific guardrails will move toward **an** off-the-shelf product when **commoditized**. But there is one final, essential question regarding the platform’s lifecycle: **when does a local “product” guardrail become a global “platform” guardrail?**\n\n**The Rule of Three:** Let’s say the E-commerce team implements a Personally Identifiable Information (PII) guardrail (a security filter designed to automatically scrub sensitive customer data like shipping addresses or credit card partials) before it gets sent to an external LLM (a key topic when operating in Europe, for example).\n\nThree months later, the Loyalty Program team builds a similar filter to mask customer names and birth dates when processing feedback logs. Then, the Store Operations team does the same for email addresses in Click & Collect order issues.\n\nThis is the graduation signal. Borrowing Martin Fowler’s *Rule of Three* 2, once a guardrail is duplicated across three distinct teams, it becomes a candidate for systemization. The platform team abstracts the data-scrubber, makes it configurable (e.g., ensuring standard compliance with GDPR or CCPA rules), documents it, and exposes it globally as a unified “Customer Data Anonymization” service.\n\nIn **this** context, stream-aligned product teams surface the recurring needs. Enabling teams spot cross-cutting trends during their engagements (Communities of Practice or Special Interest Group meetings are excellent venues to spot these). The platform team evaluates and integrates. Autonomy does not mean isolation: product teams act as the frontline sensors that feed the platform’s evolution. The platform remains a *living product* 1 with its own backlog, Product Owner, and iteration cycles.\n\n**The Bottleneck Paradox:** A risk emerges here. The more successful the platform becomes, the more the Platform PO inherits three massive burdens: the technical backlog, the guardrail graduation process, and application portfolio governance. Paradoxically, if one person must manually arbitrate the flow of needs from dozens of agent-driven teams, we recreate the exact cognitive bottleneck this entire model was designed to prevent.\n\n**The answer lies in tooling and, even more so, in cognitive automation.** A human cannot manually harvest and categorize this data at an agentic scale. The platform must automate the detection of graduation candidates, usage-based prioritization, and portfolio tracking. The PO arbitrates the data; they do not carry the burden of collecting it.\n\nWithout this continuous graduation mechanism, the platform stagnates. Product teams will endlessly reinvent the same solutions, guardrails will remain localized, and systemic reliability will silently erode.\n\nNow we have all the principles in place, it remains to turn them into actionable rules.\n\nEvery capability must have one owner (accountable for the outcome) and can have multiple contributors (who co-build without carrying accountability). Establishing this strict boundary is non-negotiable.\n\n*Each capability has an owner and contributors. Empty cells mean “not involved.” Specifics stay with product teams, systemics with the platform.*\n\nThe guiding principle is straightforward: anything specific (dynamic context, product-level guardrails, domain knowledge) stays with the stream-aligned teams because the business owns the domain. Anything systemic (global context, organizational guardrails, core tooling) is abstracted and maintained by the platform team.\n\nThe AI orchestrator is the perfect illustration of this split: the platform provides the engine (the systemic tool), but the product team drives it (the specific configuration).\n\nThe agentic platform answers the *what*. *Team Topologies* provides the framework to set up the *who* and the *how*. Treat this not as a rigid partition, but as a strict **distribution of accountability**: business intent and domain context belong to the product team, while production reliability belongs to the platform.\n\nOther organizational models will certainly emerge. But building a platform without clearly defining these boundaries and interactions will inevitably turn that platform into a massive bottleneck.\nThis model is not an off-the-shelf framework; it is a mental model for organizing **a team of teams building multiple agentic applications in parallel**. As an empirical heuristic (not an absolute rule), once you reach three to five product teams, the cumulative cost of reinvention (recreating context, rewriting guardrails, fixing localized inconsistencies) far outweighs the cost of investing in a shared platform.\n\nApplied to agentic engineering, *Team Topologies* provides a structure that:\n\nWhat has changed in our industry is that producing an application **no longer requires writing code**. Instead, it demands a new set of skills: articulating intent, structuring dynamic context, and steering an AI orchestrator. What *has not* changed is that you still need **guardrails, consistency, and reliability** to survive in production.\n\nThis brings us back to the core problem raised at the outset. Today, the software engineer carries the entire “anticipation burden” because they know exactly which questions the agent will fail to ask. Tomorrow, as the platform deterministically absorbs that burden, the technical barrier to entry plummets. A business team can safely deploy software because the platform anticipates the systemic risks on their behalf.\n\n**The shift of the application producer (from software engineer to business expert) is not a futuristic assumption. It is the direct, measurable consequence of the platform absorbing the anticipation burden.**\n\nThe developer does not disappear. Their role shifts upstream. They no longer build the application: they build the engine that empowers everyone else to build it.\n\nMatthew Skelton, Manuel Pais — *“Team Topologies: Organizing Business and Technology Teams for Fast Flow”*, IT Revolution, 2019. [↩︎](https://blog.owulveryck.info/index.xml#fnref:1) [↩︎](https://blog.owulveryck.info/index.xml#fnref1:1)\n\nDon Roberts, cited by Martin Fowler — *“Refactoring: Improving the Design of Existing Code”*, Addison-Wesley, 1999. “Three strikes and you refactor.” The principle is transposed here from code refactoring to guardrail graduation. [↩︎](https://blog.owulveryck.info/index.xml#fnref:2)", "url": "https://wpnews.pro/news/who-does-what-team-topologies-for-the-agentic-platform", "canonical_source": "https://blog.owulveryck.info/2026/06/24/who-does-what-team-topologies-for-the-agentic-platform.html", "published_at": "2026-06-24 08:00:00+00:00", "updated_at": "2026-06-24 12:45:50.704006+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-safety", "developer-tools"], "entities": ["Team Topologies", "Skelton", "Pais", "George Box"], "alternates": {"html": "https://wpnews.pro/news/who-does-what-team-topologies-for-the-agentic-platform", "markdown": "https://wpnews.pro/news/who-does-what-team-topologies-for-the-agentic-platform.md", "text": "https://wpnews.pro/news/who-does-what-team-topologies-for-the-agentic-platform.txt", "jsonld": "https://wpnews.pro/news/who-does-what-team-topologies-for-the-agentic-platform.jsonld"}}