Applications

An Application is the shared boundary around a set of agents, the operators who back them, and the people they serve. It's how you scope a product or team: which agents answer, who they serve, what they're allowed to do, and where messages come in. Every workspace has a Default Application; create more to separate distinct products, teams, or customer sets.

Applications are live-aggregate — every change applies immediately. There's no draft/deploy step for the Application itself (individual agents still carry their own revisions). The detail header shows a "Changes apply immediately" badge as a reminder.

Mental model

Piece	What it answers
Agents	Which agents answer inside this boundary, and at which release.
People & groups	Who the agents serve, plus the operators, advisors, and observers around them.
Capabilities	What the agents are allowed to do — support cases, human escalation.
Configure	Where messages enter, what fires agents, and who can administer the Application.

Overview

The Overview tab summarizes the Application at a glance: counts of AI agents, People & groups, and Capabilities enabled; a readiness card that reports whether every load-bearing setup step is done; and the current capability states. From here you can Open debug console to exercise the Application, or View topology to see the wiring.

Agents

The Agents & people → Agents sub-tab is the roster of agents that answer inside this Application. For each agent you pin a Release:

Follow current release (default) — the agent serves whatever revision is currently deployed, so it tracks your latest deploy automatically.
Release N — pin a specific revision, so this Application keeps serving it regardless of later deploys.

An agent shows Live when it's serving, with Active as its membership status.

People & groups

The People & groups sub-tab is one directory of everyone with a relationship in this Application, each shown as composable role badges with the relationship behind each badge:

Role	Meaning
Customer	An external person or group the agents serve.
Internal	A teammate inside the boundary.
Operator	A human who can take an escalated conversation (configured through Human escalation).
Advisor	Someone agents can consult but who isn't served.
Observer	Someone who can see activity without participating.
Channels & groups	Shared threads that carry the boundary's traffic.

Each row shows the record's Audience (External / Internal / Unclassified), its Roles, a Response mode toggle (whether agents respond or stay silent), and its Expertise. Add people and groups from the Directory; this tab grants them roles here.

Human operators are configured within the Human escalation capability, not added as a generic member type. And workspace Collaborators — who can administer the Application — are a separate surface under Configure. Both are distinct from the customers and groups the agents serve.

Configure

Sub-tab	What it sets
Capabilities	Toggle Support Cases and Human escalation on or off (below).
Integrations	Which integration configs this Application uses.
Messaging entry points	Where inbound messages arrive for this Application.
Triggers	Events that fire the Application's agents. See Agent Network.
Human escalation	The operator ladder a conversation escalates to.
Collaborators	Who can view or administer this Application.

Capabilities

Capabilities gate what member agents may do:

Support Cases — case lifecycle, requester eligibility, and continuation. Installing it makes the ticket/case toolset available to member agents. States: Not installed → Installed / Enabled.
Human escalation — the switch for human hand-off. When on, member agents can escalate a live conversation to an operator on the ladder; when off, escalation is unavailable even if a ladder is configured. It reads green only once it can actually hand off — enabled and at least one active operator.

Unknown senders who try to reach an Application surface as access requests rather than being added silently.