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 new people, 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

Members, as themselves: surfaces resolve the sender to a Lemma user and check pod membership before an agent runs, and apps do the same through AuthGuard. By default anyone else gets a signup or request-access link instead of an answer. A pod can also answer people it does not let in — its contacts and the visitors to its web chat — who never sign in and see only what the pod opens to them. See People outside the pod.

Reaching people outside the pod

Customers, leads and applicants can write to the pod's own bot as contacts, chat with it on your website, or fill in a form that adds a row to one of its tables — all without a Lemma account. For work that lives in another system, a connector still reads it on a schedule and sends replies back once a member approves them.

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.