A single brilliant agent builder cannot ship a production agent. They will get to a demo and stall, because the work that turns a demo into a system that survives Tuesday morning is not the work one person does. It is the work of a pod — a small, named, decision-empowered group of people from different functions who own one agent from intake to incident response. The pod is four people: an agent builder, a domain expert, a data analyst, and a reviewer. They have explicit decision rights, two non-negotiable rituals (weekly trace review and monthly eval refresh), and a discipline that distinguishes their pod from a "working group" or "tiger team" or whatever the company called the last failed coordination structure. This lesson is the pod's full operating design — the four roles and what each owns, the decision rights matrix that prevents the architect from being the bottleneck, the two rituals that hold the pod together, the meetings that should not exist, the failure modes that kill pods, and the staffing math that tells you when to spin a second pod up.

Why "Pod" and Not "Team" or "Squad"

The word matters. The strategist who calls their agent-shipping group a "team" inherits all the connotations of a normal product team — a manager, a tech lead, a designer, an engineer, a PM — and immediately runs into a mismatch with the work. A normal product team builds a feature, ships it, and operates it. An agent pod builds a behavior, evals it, ships it, monitors traces, refreshes evals, runs incidents, and iterates the behavior continuously. The cadence is different. The skills are different. The decision rights are different. Calling it a "team" obscures the differences and produces a team that fails in the same ways at every company.

The strategist who calls the group a "squad" borrows from the Spotify model, which means borrowing all the criticisms — the squad model collapsed at Spotify itself, and importing the label without the underlying decisions imports the failure mode without the upside.

The strategist who calls the group a "tiger team" tells the rest of the company this is a temporary structure that will dissolve after the project ships. Agents are not projects. Agents are operational systems that run forever, get retrained, get refreshed, get retired, and are replaced. A tiger team that ships the agent and disbands is a tiger team that hands off an operational system to nobody. Six months later, the agent has drifted, the eval set is stale, the incidents are unowned, and the strategist is explaining to the CFO why the ROI numbers in the original case have evaporated.

The pod is the right word because the pod implies persistence (it does not dissolve), small size (four to six people), shared responsibility (decisions are made by the pod, not by a single manager), and continuous ownership (the pod runs the agent for as long as the agent runs). The strategist who picks the word picks the structure.

The pod's defining properties

• Persistent ownership. The pod owns the agent from intake to decommissioning. Not from build to launch. From the moment the agent is in the inventory to the moment it is sunset.
• Named members. The pod has named individuals, not "Engineering Resources." Every member of the pod can be paged at 2am for a pod-related incident, and every member of the pod has agreed to that on-call as part of joining.
• Decision rights inside the pod. The pod can ship, pause, refresh, or escalate without going through a centralized PMO or steering committee for routine decisions. The strategist sets the bar for what counts as routine and what escalates.
• Two non-negotiable rituals. Weekly trace review and monthly eval refresh. If the pod is not running these, the pod is not a pod; it is a group of people who happen to share an agent.
• Small. Four core members, plus a fifth and sixth contributor brought in as needed (security, legal, design). Larger than six and the pod stops being a pod and starts being a steering committee.

The fastest way to identify whether a company actually understands agents is to ask who the pod is for a specific named production agent. If the answer is a named list of four people, the company gets it. If the answer is "Engineering owns it" or "the AI team," the company is going to be back at the strategist's office in six months explaining why the agent is drifting and nobody noticed.

The Four Core Roles

The pod is four people. Each has a specific role with specific accountabilities. The roles are functional, not titular — a single person can fill multiple roles in a small company, and a single role can be split across two people in a large one, but the four functions must be covered.

Role one: the agent builder

The agent builder is the person who can configure the agent, write the prompts, design the tool boundaries, set up the eval set, and ship the changes. In ladder terms (see chapter 5.4 lesson 1), this is an L2, L3, or L4 IC — junior pods have an L3 builder, mature pods have an L2 with L3 oversight, high-stakes pods have an L4 leading.

The builder owns: the agent's configuration in the platform (Lindy, Relevance, n8n, LangGraph, Crew, or platform-native), the prompt versioning, the tool integrations, the eval harness, the observability instrumentation, the agent's SLOs, and the technical postmortem after any incident.

The builder is the person who reaches for Cursor, Claude Code, Codex CLI, Helicone, LangSmith, Braintrust, or Langfuse on a daily basis. They are the person who writes the regression eval. They are the person who answers the question "why did the agent do X yesterday?" when the data analyst flags it in trace review.

Role two: the domain expert

The domain expert is the person who knows what the agent is actually supposed to do. They are the operations manager whose team is being augmented, or the customer-success leader whose tickets the agent is drafting, or the sales-ops director whose lead-scoring model the agent is replacing. They are the person who can read an agent output and say "this is wrong because at our company we always Y first."

The domain expert owns: the definition of "good" for the agent (which becomes the eval criteria), the ground truth for the eval set (real customer tickets, real sales conversations, real ops cases), the edge cases the builder would never invent on their own, and the relationship with the team whose work the agent touches.

The domain expert is the person who, in trace review, looks at an output and says "the response is grammatically perfect and factually wrong because the customer is on the Enterprise plan and we have a different SLA there." Without the domain expert, the builder ships an agent that is technically sophisticated and operationally useless.

Role three: the data analyst

The data analyst is the person who knows where the data lives, how clean it is, and what queries answer which questions about the agent's behavior. They are the person who builds the dashboards, runs the counterfactual measurements (did the agent actually do it, or was it the human reviewer who fixed the output?), and surfaces the patterns the builder and the domain expert would not see in raw traces.

The data analyst owns: the dashboards (the three dashboards every agent needs — operational, quality, business outcome), the counterfactual measurement framework, the trace sampling methodology, the cost-per-run attribution, the customer-impact attribution, and the data the pod uses in the quarterly agent review.

The data analyst is often the most under-staffed role in early agent pods. The builder thinks they can do the analysis themselves, until the third week of trace review when the builder is drowning in the dual job of fixing the agent and analyzing the agent. The data analyst is not a luxury; the data analyst is the difference between a pod that ships improvements every week and a pod that ships improvements every quarter.

Role four: the reviewer

The reviewer is the human-in-the-loop. They are the support agent who approves the draft, the underwriter who signs off on the agent's recommendation, the contract manager who reviews the agent-extracted terms. They are the user of the agent, in the strict sense — the agent runs and they decide what to do with the output.

The reviewer owns: the actual approval-edit-reject decisions on agent output, the feedback signal that turns into training data, the practical knowledge of where the agent's recommendations are useful and where they are not, and the early-warning function (the reviewer notices the agent getting worse before any dashboard does, because they are in the loop hourly).

The reviewer is the role most strategists forget to put on the pod. They put the reviewer on the org chart of the function the agent serves, not on the pod. This is wrong. The reviewer is a pod member with a vote in pod decisions. If the reviewer says "the agent is getting worse this week" and the data does not yet show it, the pod listens to the reviewer first.

The fifth and sixth role, brought in as needed

For agents that touch customer data, security joins the pod (not just consults). For agents that touch regulated decisions, legal joins. For agents that touch customer-facing UI, design joins. For voice agents, an audio specialist joins. The bench is small and the addition is functional — they are pod members for the agent surface that requires them.

The Decision Rights Matrix

The most common pod failure is decision rights ambiguity. The builder thinks they need approval for everything; the domain expert thinks the builder is making decisions without consulting them; the data analyst is escalating things they could have decided; the reviewer is making product changes through their feedback that nobody is reviewing. The decision rights matrix prevents this. The matrix is explicit, written, and owned by the pod.

The matrix has four kinds of decisions and four ways to handle each:

Four kinds of decisions

• Prompt and configuration changes. A new system prompt, a tool added or removed, a parameter tweaked.
• Eval changes. A new case added, an old case retired, an eval threshold adjusted.
• Scope changes. The agent's surface area expands (handles a new ticket category) or contracts (no longer handles a previously-handled category).
• Incident decisions. The agent is paused, throttled, killed, or rolled back during an incident.

Four ways to handle a decision

• Decided by one named pod member. The role owner decides. The pod is informed.
• Decided by pod consensus. The pod discusses and reaches agreement. If consensus fails, escalates.
• Decided by pod majority with named tiebreaker. Vote. The architect or strategist breaks ties.
• Escalated to AI Council or architect. Beyond the pod's authority. The pod prepares the decision packet; the council decides.

The matrix, populated

For a typical pod, the matrix looks like this:

• Prompt and configuration changes (routine). Decided by the builder. Pod is informed via the standing change log.
• Prompt and configuration changes (substantive). Decided by pod consensus. "Substantive" is defined as anything that changes a published behavior or any change that requires a regression eval to clear.
• Eval changes (additions, retirements). Decided by pod consensus. The domain expert has effective veto on what "good" means.
• Eval threshold changes. Decided by pod majority with the architect as tiebreaker. Threshold changes can mask regressions if done loosely; the architect's role is to ensure the threshold change is justified.
• Scope expansion. Escalated to the AI Council. The pod prepares the decision packet (the eval evidence, the risk assessment, the rollout plan). The Council decides.
• Scope contraction. Decided by pod consensus. The Council is informed.
• Incident pause or throttle. Decided by any single pod member. No consensus required. Any pod member can hit the pause button at any time.
• Incident kill. Decided by the builder or the architect. Requires explicit verification (not just a Slack message) so it cannot happen accidentally.
• Incident rollback. Decided by pod consensus during the incident, or by the architect if consensus is not possible in the moment.

The matrix is not a bureaucratic device. The matrix is a permission grant. It tells the builder they can ship the routine prompt change without asking, which removes the largest single source of pod friction. It tells the reviewer they can pause the agent without permission, which gives them real authority and removes the largest single source of reviewer disengagement.

The Two Non-Negotiable Rituals

The pod runs two rituals. Both are non-negotiable. A pod that skips either is not a pod; it is a group of people who happen to share an agent.

Ritual one: weekly trace review

Once a week, the pod sits together (in person, on Zoom, or in a Slack huddle) for 60-90 minutes. The data analyst prepares a sample of agent traces from the past seven days. The sample is stratified: 30% low-confidence outputs (where the agent flagged uncertainty), 30% reviewer-overridden outputs (where the human disagreed), 20% customer-flagged or escalated cases, 20% random sample for baseline. The pod reviews the sample together.

For each trace, the pod asks: what did the agent do, what did the reviewer do, what was the right answer, where did the agent go wrong (if it did), and what is the failure mode (tool-call failure, reasoning failure, context failure, prompt failure, eval blind spot, ground-truth disagreement)? The builder takes the failure modes back into the agent. The domain expert takes the ground-truth disagreements back into the eval set. The data analyst flags any patterns that recur across multiple traces.

The output of trace review is a written summary, distributed to the AI Council, that names the top three failure modes for the week and what the pod is doing about them. The summary takes 15 minutes to write. It is the artifact that lets the AI Council trust the pod is doing the work without having to attend the review.

Pods that skip trace review for two weeks miss a regression. Pods that skip for a month miss a regression that has already harmed customers. The discipline is non-negotiable.

Ritual two: monthly eval refresh

Once a month, the pod refreshes the eval set. New cases come from production traces (especially the ones surfaced in trace review), customer complaints, incidents, synthetic generation for edge cases, and the domain expert's running list of "the agent does not handle this yet." Stale cases are reviewed for relevance — a case that tests behavior the agent no longer needs to handle should be retired, not maintained.

The eval baseline is re-run against the current production agent. Regressions surface here, before they surface in production. The pod decides what to do with each regression: ignore (if the regression is on a case that is no longer load-bearing), fix (if the regression matters), or accept-with-mitigation (if the fix is expensive and the mitigation is a reviewer pattern).

The output of the eval refresh is a written report: cases added, cases retired, regressions found, regressions resolved or accepted, accuracy and error trends over the past three refreshes. The report is the artifact the AI Council uses to track agent health between quarterly reviews.

If a strategist had to pick one diagnostic to assess any agent program in any company, it would be: show me the last four weeks of trace review summaries and the last three monthly eval refresh reports. If those documents exist and are coherent, the program is healthy. If they do not exist, no other metric matters yet.

Meetings That Should Not Exist

The pod runs two meetings per month: four weekly trace reviews and one monthly eval refresh. Plus incident response when an incident happens. That is it. The strategist's job is to defend the pod against every meeting that wants to be added.

The standup the engineering org wants you to have

The pod does not run a daily standup. The work is too varied and the pod is too small. A standup wastes 15 minutes per day per pod member, which is 5 hours per week across a four-person pod, which is 200 hours per year. That is a quarter of an FTE consumed by a ritual that produces no decisions and no improvements. The pod replaces standup with an asynchronous status thread in Slack updated when there is something to say.

The status update the program manager wants

The pod does not produce a weekly status update for the program manager. The pod produces a trace review summary (which is the status update) and the program manager reads it. If the program manager wants a different format, the program manager adapts to the pod's format, not the other way around. The pod that produces three different status updates per week for three different audiences is a pod whose builder is doing status updates instead of building.

The all-hands the strategist is tempted to call

The strategist does not call a weekly all-hands for all pods to share progress. Cross-pod sharing happens in the monthly AI Council and in the quarterly agent review. Weekly all-hands across pods consume builder time and produce coordination overhead. The pods talk to each other through the trace review summaries and the eval refresh reports, which are public.

The retro that should be a postmortem

The pod does not run a Friday retro for general feedback. The pod runs postmortems after incidents and quarterly retros for trend reflection. Continuous retros produce continuous low-grade complaints that never get acted on; postmortems produce specific corrective actions that ship.

The grooming session the team wants

The pod does not run a backlog grooming session. The pod has a small set of in-flight changes (the routine ones the builder is shipping, the substantive ones the pod is discussing) and the architect's roadmap for the agent. A grooming session for a four-person pod with a small in-flight set is theater.

Failure Modes That Kill Pods

Pods die in predictable ways. The strategist's job is to detect the early signals and intervene.

The dotted-line domain expert

The pod is officially four people but the domain expert is "dotted-line" — they are still 100% allocated to their primary function, and the pod is a tax on their time. They show up to trace review when they can, miss eval refresh half the time, and the agent drifts from the operating reality the domain expert is supposed to ground.

Fix: write the domain expert's pod role into their formal job description, with the time commitment named (typically 8-12 hours per week for an active pod). If their manager will not commit the time, the pod is not staffed, and the strategist must escalate or de-scope the agent.

The phantom reviewer

The pod has a "reviewer role" but the reviewer is actually rotating across 12 people who each see a handful of agent outputs per week. No single reviewer has enough volume to form a coherent view. The trace review reflects 12 different opinions about the agent, none of which is grounded in continuous exposure.

Fix: name a primary reviewer (the person who handles the largest share of agent outputs), bring them onto the pod with named role, and treat the others as a feedback channel rather than as pod members.

The builder as bottleneck

Every decision flows through the builder. The pod cannot make progress on a Tuesday because the builder is in a conflicting meeting. The pod's velocity is bounded by the builder's calendar. Cause: decision rights matrix not in use, or the matrix gives too many decisions to the builder.

Fix: revisit the matrix. Push more decisions to consensus or to other named owners. The builder's calendar should be the bottleneck for changes only the builder can make, not for routine pod decisions.

The data analyst who is half a person

The data analyst is 50% allocated and the pod is the lower priority half. The dashboards are stale. Counterfactual measurement is not happening. Trace review samples are not stratified. The pod is flying blind.

Fix: full-allocation a data analyst, or accept that the agent has a lower-tier data picture (and document the gap so the AI Council knows). Half-allocated data analysts in agent pods are the single most common under-staffing pattern in 2026.

The pod that became a meeting

The pod runs trace review, eval refresh, two architecture reviews, three stakeholder updates, a customer feedback session, and a security check. Nobody is building. The pod is the meeting calendar.

Fix: the strategist publishes the two-meeting rule (trace review + eval refresh, plus incident response). Every other meeting must justify its existence against that floor. Meetings that cannot justify get cancelled.

The cross-pod siege

Pod A's agent needs a change to Pod B's shared MCP server. Pod B has not prioritized it. Pod A's roadmap blocks. Cause: cross-pod dependencies not surfaced or owned.

Fix: name a platform pod that owns shared infrastructure (MCP servers, eval frameworks, observability). Cross-pod dependencies go to the platform pod, not to the pod that happens to own the surface. The platform pod has its own roadmap and prioritization, governed by the architect.

When to Spin Up a Second Pod

One pod is the starting structure. The second pod, the third pod, the fourth pod — these are the structures that emerge as the agent program grows. The decision of when to spin up a second pod is the strategist's call. The trigger points are concrete.

Trigger one: the first pod is running two agents

A pod can run one agent well. A pod cannot run two agents well; the trace review for two agents takes twice as long, the eval refresh competes for attention, the on-call rotation gets confused. When the first pod has two agents in production and a third is being planned, it is time to spin up a second pod.

Trigger two: the agent has crossed the blast-radius threshold

An agent that started as low-stakes (internal-only, narrow surface) may grow to high-stakes (customer-facing, revenue-touching, regulator-relevant) over its life. When the blast radius crosses a threshold the strategist defines, the agent needs a dedicated pod — not a slice of an existing pod's attention.

Trigger three: the on-call rotation is breaking

A four-person pod can sustain a 4-week on-call rotation (each member is on-call one week per month). When the rotation tightens (every other week, or every week) because incidents are frequent and members are burning out, the pod needs to be split or supplemented.

Trigger four: the domain expert is split across surfaces

The pod's domain expert is the customer-success leader. The agent expanded to also serve the sales-engineering team. The single domain expert cannot ground both surfaces. The structural answer is a second pod with a sales-engineering domain expert, not a single pod with two domain experts.

Trigger five: the agent's roadmap is too big for the pod's velocity

The pod is shipping at a sustainable cadence (one substantive change per two weeks). The strategist's roadmap has six substantive changes planned in the next quarter. The math does not work. Either the roadmap shrinks or the pod doubles.

Doubling the pod (adding a second builder, a second reviewer, a second data analyst) is the wrong answer; pods larger than six become coordination problems rather than building problems. The right answer is two pods on adjacent surfaces of the same agent, with explicit hand-off points and a shared platform.

The Pod and the 90-Day Re-Skilling Track

The pod is the destination for the 90-day re-skilling track graduate. The track described in chapter 5.4 lesson 1 takes a strong individual contributor in an adjacent function and turns them into a productive L1 or L2 agent builder. The graduate lands on a pod — typically replacing or supplementing the builder role on a moderate-stakes pod.

The pod is also a feeding ground for the domain expert role. The customer-success leader who has spent six months as a reviewer on the support agent pod is the natural domain expert for the next support-adjacent agent the company builds. The reviewer-to-domain-expert promotion path is one of the highest-leverage moves the strategist makes; it converts a function the agent disrupted into a function the agent strengthens.

The reviewer role itself is a re-skilling destination. The ops manager whose team was reduced by the auto-tagging agent does not leave the company; they become the reviewer on the next pod that needs domain depth, with a 90-day track to add the prompt-and-tool craft that turns them into an L2 builder. The pod is the visible career path that the re-skilling track promises.

The Pod and the Architect Relationship

The pod is empowered to decide most things. The architect is the escalation path for the decisions the pod is not empowered to make. The relationship works when both sides understand the boundary.

What the architect does for the pod

• Reads the trace review summaries and eval refresh reports. Without attending the meetings. The artifacts are the architect's view into the pod's health.
• Owns the cross-pod platform decisions. Shared MCP servers, eval framework, observability stack, model selection — the architect ensures these decisions are not made differently by different pods.
• Sets the threshold for what escalates. Substantive prompt changes, scope expansion, eval threshold changes, incident kills. The architect publishes the threshold and revises it as the pods mature.
• Tiebreaks pod decisions. When pod consensus fails, the architect decides. The architect is the named tiebreaker in the decision rights matrix.
• Sponsors the pod's hiring and growth. The pod's members get promoted through the ladder; the architect is the named senior who advocates for them in the promotion committee.

What the architect does not do for the pod

• Make the pod's routine decisions. Prompt tweaks, eval additions, scope contractions — the pod decides, not the architect.
• Attend trace review or eval refresh by default. The architect reads the artifacts. Attendance is by request, not by default. The pod's meetings are for the pod.
• Override the pod on incident response. If the pod paused the agent during an incident, the architect does not unpause until the pod's investigation says so.
• Reassign pod members without consultation. Pod composition is a pod decision in collaboration with the architect, not an architect decision imposed on the pod.

The architect who micromanages a pod produces a pod that does not own its work. The architect who is absent from a pod produces a pod that drifts. The architect who reads the summaries, attends by request, and tiebreaks when asked produces a pod that ships.

Key Takeaways

• The pod is four people: agent builder, domain expert, data analyst, reviewer. Persistent, named, decision-empowered, small. Not a team, not a squad, not a tiger team.
• The pod owns the agent from intake to decommissioning. Every named production agent has a named pod with a named member-list the strategist can recite.
• The decision rights matrix is explicit: routine prompt changes by the builder; substantive changes by pod consensus; scope expansion escalated to AI Council; any pod member can pause the agent at any time.
• Two non-negotiable rituals: weekly trace review (60-90 minutes, stratified sample, written summary) and monthly eval refresh (cases added/retired, baseline re-run, regression report). A pod that skips either is not a pod.
• Meetings that should not exist: daily standup, weekly status update, weekly all-hands across pods, Friday retro, backlog grooming. The strategist defends the pod against meeting creep.
• Six failure modes kill pods: dotted-line domain expert, phantom reviewer, builder as bottleneck, half-allocated data analyst, the pod that became a meeting calendar, cross-pod siege.
• Spin up a second pod when: first pod is running two agents, the agent crossed the blast-radius threshold, the on-call rotation is breaking, the domain expert is split across surfaces, or the roadmap exceeds the pod's velocity.
• The pod is the destination for 90-day re-skilling graduates and the reviewer-to-domain-expert promotion path. The pod is the visible career path the re-skilling track promises.
• The architect reads the summaries, sets the escalation threshold, owns cross-pod platform decisions, tiebreaks when consensus fails, and stays out of the pod's routine decisions.
• The fastest diagnostic for a healthy agent program: show me the pod's last four weeks of trace review summaries and the last three monthly eval refresh reports. If they exist and are coherent, the program is healthy.