Pods and Scope

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.

Who can talk to a pod

Everyone who interacts with a pod directly is a member of it. Surfaces resolve the sender to a Lemma user and check pod membership before an agent ever runs, and apps do the same through AuthGuard. Someone who is not a member gets a signup or request-access link back instead of an answer — so a customer, a lead, an applicant, or a community member cannot message your bot or open your app.

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.