Ask a marketing team how many AI agents they run and you will usually get a confident number. Ask which of those agents belong together, who is accountable when one of them is wrong, and where the boundary of that group sits, and the confidence tends to go.
The second set of questions is what a pod answers. The pod is the unit of design in AI-augmented marketing, and it is the piece most teams skip. Agents get added one at a time, each one solving whatever annoyed someone that week, until the team has a collection. A collection produces output. It does not produce leverage, and no one can say who owns it.
The definition
A pod is the smallest complete unit of agent-assisted work: a set of agents that together cover the recurring work of one role, directed by one named accountable human.
Every clause in that sentence is load-bearing.
Together cover means the pod is complete for its scope. If a person still has to do a recurring part of the job by hand because no agent covers it, the pod is not finished being designed. Completeness is what turns a set of helpers into a unit you can reason about.
The recurring work of one role is the boundary. Not the work of a department, and not one clever task. A role is the right size because it is small enough to brief accurately and large enough that covering it changes how a person spends their week.
One named accountable human is the part teams get wrong most often. Not a team, not a committee, not a rotating owner. One person, by name, who is answerable for what the pod produces. If you cannot say the name, you do not have a pod.
Four properties separate a pod from a pile of prompts
One accountable human. Named, and holding the approval decision. This person briefs the agents, reviews what comes back, and owns what ships. The accountability does not distribute across the pod and it never transfers to an agent.
A bounded scope. The pod covers a defined set of recurring work, and the things it does not cover are written down. An unbounded pod quietly expands until nobody can review its output at the cadence it produces.
Shared context. The agents in a pod work from the same brand voice, positioning, audience definition, and standard of what good looks like. This is what makes the outputs consistent with each other. Four agents with four different understandings of the brand are four agents, not a pod.
A written control layer. Which outputs need review before they ship, which do not, what triggers escalation to a human, and what the agent does when it is uncertain. In writing, not in the accountable human's head, because the point of writing it down is that it survives a busy week.
How big is a pod?
Three to six agents in most designs that hold up. The range is a design guideline rather than a measured benchmark, and the reasoning behind it is more useful than the number.
Below three agents, you have an assistant. That is a fine thing to have, but it does not change the shape of a role, and the design work a pod requires is overhead you have not earned yet.
Above six, the pod starts needing management of its own. One person has to brief each agent, review its output, and maintain it as the work changes. Past roughly six that weekly load stops fitting alongside the person's actual job, and the pod begins failing in the specific way that is hardest to catch: output keeps arriving, review gets thinner, and quality drifts without anyone deciding to let it.
What one looks like
Take a product marketer. The recurring work of that role, the parts that come around every cycle, might be launch briefs, competitive updates, sales enablement one-pagers, and the first drafts of lifecycle email.
Four agents, one for each. They share the same positioning document, the same audience definitions, the same brand voice, and the same written standard for what a good draft looks like. The product marketer briefs them, reviews everything, and approves what ships.
The boundary matters as much as the contents. This pod does not touch pricing. It does not make positioning decisions, it works from them. Nothing it produces reaches an analyst or the press without going somewhere else first. Those exclusions are written into the pod's control layer, which is what makes them real rather than assumed.
A pod is not the agents alone. It is the agents plus the human who owns them, the context they share, the controls they run under, and the boundary that says where they stop.
What a pod is not
It is not a tool stack. Four subscriptions is a procurement decision. A pod is a design decision, and you can build one inside tools you already pay for.
It is not an org chart. A pod describes how one role's recurring work gets done. It does not describe reporting lines, and reading it as headcount math is the fastest way to design one badly.
It is not autonomous. This is the one worth being blunt about. A pod without a human holding approval is not an advanced pod. It is an ungoverned one, and the failure mode is not dramatic. Output keeps arriving and looking fine, right up until the piece that was not fine goes out with your name on it.
The three-question test
Point at any set of agents your team runs and ask:
Who is accountable? One name, not a team. Where does it stop? Written down, not assumed. What has to be reviewed before it ships? Specifically, not "we check things."
Three clean answers and you have a pod. Anything less and you have a collection of agents, which is a fine place to start and a poor place to stay. The gap between those two states is where most teams currently sit, and closing it costs design time rather than budget.
The pod is the unit. The New Org Model is the structure pods sit inside, and it is the next thing to read if you want to see how a team is arranged once several roles are working this way.
Join AAIML free for the full pod design method, the templates behind it, and the practitioners working through the same design problem in real time. aaiml.org