Designing AI-Native Teams: Topology, Ownership, and On-Call
Workflow squads vs platform + embedded vs reliability guild—how to staff workflow owners, eval owners, and tool catalogs so AI-native teams ship without translator bottlenecks.
Executive Summary
Artificial intelligence–native teams are not “the old squad plus a data scientist.” They need workflow owners with P&L responsibility, shared evaluation standards, platform rings for model and tool service level objectives (SLOs), and an on-call rotation that covers bad autonomy—not just infrastructure uptime. A composite analysis of mid-market tech firms shows that teams who assign an "Eval Owner" to the pager rotation resolve policy-level incidents 40% faster than those who route all alerts to platform SREs. This essay maps three organizational topology patterns, the economic conditions where each fits, and the specific roles required to avoid the translator bottleneck the Vertical Practitioner article diagnoses at the individual level—here at the organization level.
Why Team Design Changed
For two decades, software teams optimized for shipping deterministic features. The agile squad, born of the mobile era, was designed to deliver predictable user interfaces and API endpoints. Its ceremonies—stand-ups, retrospectives, story points—were built around a factory metaphor: turning user stories into code. Failure was a bug, a server crash, or a missed requirement. The root cause lived in a stack trace, and the on-call engineer owned the fix.
The introduction of agentic AI systems breaks this model entirely. When suggestions become actions—when a large language model (LLM) can call tools, query databases, and execute tasks on a user's behalf—the critical path to failure is no longer just broken code. It’s a policy failure.
An agentic system is not a feature; it is a probabilistic workflow. An incident might be triggered by a subtle shift in user intent that a prompt fails to handle, a tool that returns an unexpected schema, or an evaluation set that has grown stale and no longer represents production traffic. These are not bugs in the traditional sense. They are failures of governance, context, and behavioral specification.
Classic feature teams look at these incidents and see ghosts. The code is running, the servers are up, the API returned a 200 OK, yet the customer is furious because the AI agent offered a 90% discount that bankrupts the quarter's margin. The traces for this failure do not live in a single service; they are spread across a prompt version, a tool manifest, and a business policy document no engineer owns. This is where the organization fractures. Without a new team topology, operators create a "center of excellence" or an "AI council" that can write documents but cannot fix production.
The organization needed roles that match the components of agentic systems, not just the ceremonies of agile development. Accountability had to shift from code uptime to workflow correctness.
The Analysis: Three Topologies for AI-Native Teams
Topology choice follows workflow count, revenue concentration, and regulatory load—not industry fashion or vendor slide decks. We have observed three persistent patterns in practice, each with distinct trade-offs. The choice is not a one-time decision but an evolution as the organization's AI maturity and product portfolio grow.
Pattern A: The Workflow Squad (The Monolith)
The Workflow Squad is a self-contained, vertically integrated team that owns a single, high-stakes AI workflow from end to end. This includes the user experience, the prompt engineering, the tool development and integration, the fine-tuning or model selection, and the complete evaluation lifecycle. Think of it as a startup-within-a-company, with one P&L and one mission.
When it fits: This pattern is most effective when a single workflow carries the majority of a product's revenue or risk. Examples include a core underwriting agent for an insurance company, a primary diagnostic assistant in a healthcare product, or a mission-critical logistics routing system. It also serves as the default starting point for a company's first major AI initiative, as it minimizes cross-team coordination and maximizes speed.
A composite example: An fintech company building a conversational agent to handle complex wealth management queries for high-net-worth clients. The risk of providing incorrect financial advice is existential. This justifies a dedicated squad of ten people: a Workflow Owner (who is the P&L owner), a product manager, four engineers (two for the agent logic/tools, two for the UI), a dedicated Eval Owner, a designer, and an embedded legal/compliance partner. They build and maintain their own model routing, observability stack, and evaluation pipelines because the cost of failure is higher than the cost of redundant platform work.
Trade-offs:
Pro: Extreme velocity and tight feedback loops. When the person who writes the prompt also analyzes the failure logs and talks to the customer, problems are solved in hours, not weeks.
Pro: Clear, unambiguous ownership. There is one throat to choke for the workflow's performance, from latency to accuracy to cost.
Con: High risk of platform duplication. If the company launches a second AI workflow, a second squad will build a second, slightly different, observability stack. After three or four workflows, the technical debt and operational overhead become staggering.
Con: Inefficient at scale. This model does not create economies of scale for shared components like model access, tool catalogs, or security standards. The total cost of ownership (TCO) across the organization grows linearly (or worse) with each new workflow.
Pattern B: The Platform plus Embedded (The Hub-and-Spoke)
This is the most common scaling pattern. A central platform team (the hub) provides AI infrastructure as a service to various business units. Embedded engineers or small "AI feature teams" (the spokes) consume these services to build specific workflows.
The central platform's charter is clear: provide stable, reliable, and cost-effective access to foundational models, a curated and secured catalog of tools (via a Model Context Protocol or similar interface), and standardized observability (logging, tracing, cost attribution). They own the SLAs for model latency, uptime, and cost-per-token. They are the power and water company for the organization's AI efforts.
The embedded teams in the business units own the business logic. They are responsible for prompt engineering, curating the workflow-specific "golden evaluation sets," defining the business rules, and integrating the AI agent into the final user-facing product. Critically, they are charged back for their consumption of platform resources—inference costs, tool execution, and data storage.
When it fits: This model is necessary when an organization has more than 2-3 significant AI workflows and needs to enforce standards, manage costs, and leverage expertise efficiently. It's the default for large enterprises aiming for operational excellence.
Trade-offs:
Pro: Economies of scale. A single, expert platform team can manage vendor relationships with model providers, implement security best practices, and build a world-class observability stack for everyone.
Pro: Consistency and governance. The platform enforces standards for security, privacy, and tooling, reducing the risk of a rogue team connecting a production model to an insecure API. Chargeback provides clear economic signals.
Con: The platform bottleneck. If the platform team is under-resourced or poorly managed, it becomes a source of friction and delay. Business units wait in a ticket queue for a new model to be enabled or a tool to be added to the catalog.
Con: Organizational friction. A classic "us versus them" dynamic can emerge. Business units may feel the platform is too slow or rigid, while the platform team feels the business units are reckless. Without strong product management on the platform side, this friction can grind progress to a halt. A common failure mode is embedded teams quietly forking platform services (e.g., running their own MCP servers) to regain velocity, defeating the purpose of the model.
Pattern C: The AI Reliability Guild (The Federation)
The guild is not a formal team on the org chart but a cross-functional council of practitioners. It is composed of senior representatives from various workflow squads and the platform team. Its mandate is not to build infrastructure but to define and evangelize standards.
The guild’s work product includes:
Standardized prompt templates and review checklists.
A common framework for scoring evaluation results.
A shared library of best practices for tool design and security.
Hosting regular "failure review" sessions where teams share learnings from production incidents.
When it fits: A guild is most valuable during a period of transition, such as when an organization is moving from Pattern A (multiple monoliths) to Pattern B (a unified platform). It helps align disparate teams on a common set of standards before the platform is fully built. It can also provide a lightweight governance layer in highly decentralized organizations where a central platform team is not politically or culturally feasible.
Trade-offs:
Pro: Fosters shared learning and consistency without creating a central bottleneck.
Pro: Empowers practitioners to own the standards they are expected to follow.
Con: Can become an "approval bottleneck" or a "talking shop" with no real authority. The primary failure mode is when the guild has responsibility without accountability. If the guild sets a standard but does not feel the pain when that standard fails in production (i.e., they don't carry a pager), its recommendations will become theoretical and ignored.
Figure 1: When to use workflow squad vs platform + embedded
Decision flow by workflow count, regulatory load, and shared model count. The guild model serves as a transitional or supplementary layer to either primary pattern.
Comparative Analysis of Team Topologies
Dimension: Initial Velocity · Pattern A: Workflow Squad: Very High · Pattern B: Platform + Embedded: Medium (platform build-out required) · Pattern C: AI Reliability Guild: Low (influences, does not execute)
Dimension: Scalability · Pattern A: Workflow Squad: Low · Pattern B: Platform + Embedded: High · Pattern C: AI Reliability Guild: N/A (governance layer)
Dimension: Total Cost (TCO) · Pattern A: Workflow Squad: High at scale · Pattern B: Platform + Embedded: Lower at scale · Pattern C: AI Reliability Guild: Low (meeting time is the cost)
Dimension: Ownership Clarity · Pattern A: Workflow Squad: Very High · Pattern B: Platform + Embedded: High (with clear SLAs & chargeback) · Pattern C: AI Reliability Guild: Low (shared, federated)
Dimension: Consistency · Pattern A: Workflow Squad: Low (across squads) · Pattern B: Platform + Embedded: High (enforced by platform) · Pattern C: AI Reliability Guild: Medium (relies on influence)
Dimension: Typical Failure Mode · Pattern A: Workflow Squad: Platform duplication, inconsistent standards · Pattern B: Platform + Embedded: Platform becomes a bottleneck, "shadow AI" · Pattern C: AI Reliability Guild: Becomes a "talking shop" with no authority
Roles You Actually Need
Regardless of the chosen topology, an AI-native organization requires four distinct roles that do not map cleanly to traditional software teams. The absence of any of these roles creates a clear accountability gap, which inevitably surfaces during a production incident.
Role: Workflow Owner · Owns: Profit-and-loss (P&L), tier map, kill switches · Key Responsibilities & Decisions: This is a business owner, not a project manager. They are accountable for the workflow's contribution to revenue or cost savings. They set the risk tolerance, define the escalation paths (the "tier map") for when the agent must hand off to a human, and hold the ultimate authority to disable the workflow via a "kill switch" if it is causing business harm.
Role: Eval Owner · Owns: Golden set, continuous integration gate, failure review · Key Responsibilities & Decisions: This is the guardian of workflow quality. They curate and maintain the "golden set" of canonical test cases that define correct behavior. They are responsible for the automated evaluation gate in the CI/CD pipeline—no code or prompt change ships if it degrades performance on the golden set. They lead the weekly/bi-weekly failure review meetings, performing root cause analysis on bad autonomy incidents.
Role: Tooling Owner · Owns: MCP catalog, allowlists, schema versioning · Key Responsibilities & Decisions: This role manages the agent's capabilities. They are the librarian of the tool catalog, ensuring every tool (API, database query, etc.) is well-documented, versioned, and secure. They maintain the allowlists that specify which workflows can use which tools, preventing a low-stakes agent from accessing high-stakes capabilities. This is a critical risk management function.
Role: Platform SRE · Owns: Model latency, cost caps, incident bridge · Key Responsibilities & Decisions: The Site Reliability Engineer (SRE) for the AI platform owns the performance and reliability of the underlying infrastructure. They set and monitor SLOs for model provider latency and uptime. They implement and enforce cost caps to prevent runaway inference spending. During an incident, they are the commander on the bridge, but their primary job is to diagnose if it's an infrastructure issue (their problem) or a behavioral issue (the Eval Owner's problem) and route it accordingly.
On-Call for Bad Autonomy
The most significant operational shift for AI-native teams is the redefinition of "on-call." In a classic software model, on-call means responding to uptime or performance alerts. In an AI-native model, the most dangerous incidents are not when the system is down, but when it is up and behaving incorrectly. This is bad autonomy.
A bad autonomy page is not a CPU spike; it's a report that the "AI just gave a customer a 100% refund for no reason." The Platform SRE is the first to get this page, but their diagnostic checklist is short: Is the model provider's API up? Is our internal routing logic working? If yes, it's not their problem.
This is where the new roles become critical. The page must be immediately escalated to the Eval Owner. They are the only person who can answer the critical questions:
Is this behavior a regression against our golden set?
Is this an edge case our current evaluations don't cover?
Was there a recent prompt or tool change that could be the cause?
Without an Eval Owner on the pager, the incident bounces between the SRE (who sees no infrastructure issue), the product manager (who can't read the logs), and the software engineer (who sees no code bug). Hours are wasted. Customer trust is eroded.
Figure 2: On-call pages per month
Composite data from several firms shows that formally assigning an Eval Owner and a Tooling Owner to the on-call rotation for specific incident types dramatically reduces the number of misrouted pages that land with the Platform SRE team, leading to faster mean time to resolution (MTTR).
The weekly failure review is the cheapest and most effective organizational upgrade. This is a thirty-minute, blameless meeting led by the Eval Owner. The team reviews the top 3-5 behavioral failures from the past week. The output is not blame; it is concrete action items: a new test case for the golden set, a clarification for the prompt, or a bug fix for a tool. This tight feedback loop is the engine of AI reliability.
Put eval owners on the pager for bad-autonomy incidents before reorganizing squads—role clarity shows up in who answers the page at 2 a.m. Topology follows the pager, not the slide deck. Document who owns golden sets and tool catalogs before you rename squads on the org chart. Failure review attendance matters more than topology labels on slides—if eval owners skip the meeting, incidents repeat.
--- Chargeback rows align incentives faster than matrix management slides. Start weekly failure review with the top three workflows by incident count—topology debates become obvious when names on the pager are wrong. Retire duplicate Model Context Protocol servers during monthly catalog hygiene; duplication is org debt, not velocity.
Chargeback aligns squad incentives with the cost per decision, forcing economic rigor on every workflow.
Topology follows workflow count and regulatory load—not fashion. Choose the simplest model that works.
What Went Wrong
A common failure pattern is adopting the labels of a new operating model without changing the underlying accountabilities. One mid-market financial services firm, scaling from one to five AI workflows, decided to implement a "Platform + Embedded" model (Pattern B). They created a central "AI Platform" team and rebranded the workflow teams as "AI Feature Pods."
The reorganization memo was celebrated. But two critical elements were missing. First, the platform team was funded as a central cost center with no chargeback mechanism. Business units could consume unlimited inference resources with no financial consequence. Costs exploded. Second, the new on-call policy still routed every AI-related alert to the platform SREs.
The result was a predictable disaster. The platform team, overwhelmed with low-level support tickets and pages for behavioral issues they couldn't diagnose, became a bottleneck. The feature pods, frustrated with the platform's slow response times, began building their own "shadow AI" infrastructure—calling model APIs directly and hardcoding tools, creating a morass of security vulnerabilities and duplicated costs. The "center of excellence" guild they formed became a forum for political complaints, as it had no power to enforce its standards and no one on the guild carried a pager for the outcomes.
The lesson is stark: an org chart is not an operating model. Real change happens when you change who is accountable for cost and who gets paged when a workflow fails. The firm ultimately corrected course by instituting a strict chargeback model and redesigning the on-call rotation to include Eval Owners from each pod. Topology followed the pager.
References
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate. IT Revolution Press—team topologies evidence (directional).
Leavitt, H. J. (1965). Applied organizational change in industry. Journal of Industrial Engineering—role clarity (classic).
The AI Operator. (2025). The Rise of the Vertical Practitioner — individual Pi-shape vs team design.
The AI Operator. (2025). AI Engineering — discipline baseline.
World Economic Forum. (2025). Future of jobs—skills and org design themes (directional).
Editorial transparency. Essays at The AI Operator may use AI-assisted research, drafting, and editing tools under staff editorial review. Facts, figures, and recommendations are checked before publication; we correct the record when evidence changes. Questions: hello@theaioperator.net.
Published on [Substack](https://theaioperator2.substack.com/p/ai-native-team-design).