Inside a pod.
A pod is the unit of delivery in Cadence. It’s small, stable, and AI-powered, and it’s public-facing: the rest of the org reaches it through well-defined surfaces, not back-channels.
Humans
3–4
Stable membership. The org reorganizes around pods, not the other way around.
AI agents
≥ 2
At minimum: an inbound agent and an outbound agent, each with a public surface.
Library
Public + private
Two layers: what the pod exposes to others, and what it uses internally.
Three external surfaces, the inbound agent, the outbound agent, and the public library, are how every other team interacts with the pod. The private library is the pod’s own working memory.
Inbound agent · public
The pod's front door.
Any other team can talk to it. It validates ideas against the pod's past work, triages, flags issues a human needs to resolve, and proposes a backlog entry.
Outbound agent
The handoff.
Reviews work the pod has produced and decides what the next step is — what needs to happen, by whom, to move the work forward.
Library · public + private
The pod's memory.
Public layer documents capabilities and how to send the pod work. Private layer is the pod's own context store, used by devs and POs in the moment.
The inbound agent.
The inbound agent is the pod’s public front door. Anyone with work to suggest can talk to it directly: a peer pod with a dependency, a leader with an idea, a customer-facing team forwarding a request. The agent doesn’t accept or reject. It processes.
What it does
- 1Takes the idea. Captures the request in the requester's words, plus any context they bring.
- 2Validates against past work. Compares the idea to what the pod has already done. Surfaces relevant prior decisions, related artifacts, and existing capabilities the requester may not know about.
- 3Triages. Tags the request: is it a bug, a new capability, a dependency, a duplicate? Sizes it roughly. Identifies what would need to be true for it to be doable.
- 4Flags issues humans need to resolve. If the request conflicts with existing work, requires a policy call, or needs a decision the agent can't make, it surfaces those clearly.
- 5Proposes a backlog entry. Drafts a candidate entry for the pod's backlog with everything above attached. The pod's humans review and accept, modify, or reject.
The point: requesters get fast, structured intake without interrupting the pod’s flow, and the pod gets work that’s already triaged by the time a human looks at it.
The outbound agent.
The outbound agent mirrors the inbound one. It takes work the pod has produced and works out what needs to happen next to move it forward, whether that stays inside the pod or goes out into the rest of the system.
What it does
- Reviews completed work. Looks at code merged, specs accepted, decisions made. Reads the pod’s own signals.
- Decides next steps. What does this need? Validation? Documentation? A handoff to another pod? Routing to a customer? Inclusion in the next Scaled Review?
- Names what’s required to advance. If the work needs another pod’s input, it drafts a request to that pod’s inbound agent. If it needs a decision from Align, it queues it for the next event.
The library.
Every pod has a library with two layers. They serve different audiences and they should never be confused.
Public layer
What the pod is and what it does.
The public layer is for everyone outside the pod. It documents the pod’s capabilities, the work it’s done, key insights other teams should know, and the right way to send the pod work. The inbound agent reads from this layer to ground its decisions; humans read it before approaching the pod.
Private layer
The pod’s own working memory.
The private layer is for the people in the pod. Devs and POs find the right context at the right time — design notes, earlier debates, internal RFCs, prompts that worked, the messy middle. The pod uses it to share institutional memory forward without bottlenecking on individuals.
Together, the two layers keep a pod nimble even as membership rotates and the codebase grows. Without the public layer, the org can’t talk to the pod efficiently. Without the private layer, the pod loses its own past.
Pods stay stable.
This is the principle that makes the rest of the model work.
Pods are 3–4 people, highly focused on delivering specific value, and intentionally stable and nimble. The org reorganizes around pods, not by reshuffling them.
When initiatives change, pods don’t. The backlog changes, priorities change, sometimes the people they coordinate with change. The pod itself is the constant. Its codebase, agents, library, and accumulated context all stay put.
The reason is simple: every ramp-up costs context, and AI amplifies that cost. A pod that’s been together long enough to tune its agents and build up its private library is far more productive than a freshly assembled team. That’s what compounds over time.
Multi-pod coordination.
The corollary to pod stability: when pods do need to coordinate, the coordination layer is temporary. They don’t merge or restructure. They stand up an alignment for as long as the dependency lasts, then take it down.
When it’s used
As needed, and only when needed. Two or more pods have backlog items that depend on each other and the work can’t move forward in isolation. That’s the trigger.
How it’s structured
- A daily alignment. The participating pods meet at least once a day to keep work moving and surface blockers fast.
- A Flow Lead facilitates. Keeps the meeting tight, removes impediments, owns the cadence.
- A Scaled Product Owner detangles. When dependencies compete, the Scaled PO decides what’s most important and clears the path.
- Each pod surfaces a product-focused representative. Not necessarily full-time dedicated. Their job is to connect the alignment back to their pod and bring the pod’s answers back to the alignment. They’re supported by a Product Owner as needed.
The principle behind it
A pod always has one place to get its final prioritized backlog.
That role can be filled by different people as the org shifts — a dedicated PO during heavy product cycles, a Scaled PO during cross-pod work, a TPM during integration phases. Whoever holds it, the pod has one source of truth. Without that, prioritization fragments and the pod stalls.