Browse docsMenu

Platform

Pods and Scope

How to scope a pod so it stays useful, bounded, and easy to evolve.

Pod

A pod is the technical and operational boundary for one team or process. It contains the tables, files, agents, workflows, functions, permissions, apps, and surfaces that make that work one system.

Operating job

Scope the pod around the work it moves: triage support, qualify leads, review expenses, onboard teammates, track launch items, or run a back-office loop. Multiple apps, workflows, agents, and assistants can live inside one pod when they serve the same operating job.

Good pod scope

  • One team or one operating domain.
  • One primary unit of work, such as ticket, lead, claim, expense, applicant, or launch item.
  • One shared data model for the domain.
  • Multiple user surfaces only when they serve materially different personas in the same operating loop.

Bad pod scope

  • Mixing unrelated domains such as hiring, support, finance, and sales in one pod.
  • Creating mirror membership tables instead of using organization and pod membership APIs.
  • Starting with an app layout before deciding what work object the operator acts on.