Skip to content

Apps

An App turns a Harness + Agent pair into a deployed service that responds to external messages. The App owns the channel-specific binding (Slack, webhook, schedule, AG-UI), the inbound auth, the session-routing strategy, and the publish/unpublish lifecycle.

The same agent can back multiple apps (e.g., a Slack deployment and a webhook deployment), and each app’s lifecycle is independent.

App Architecture

  1. An external channel sends a request to the app’s endpoint.
  2. The app verifies the request using channel-specific auth (signing secret, OIDC, mTLS, etc.).
  3. A session is found or created according to the session strategy.
  4. The agent processes the message and the response flows back through the channel.
ChannelStatusWhat it does
SlackAvailableDeploy as a Slack bot
AG-UIAvailableAG-UI inbound channel
ScheduleAvailableCron-triggered invocation into an app-owned session
WebhookAvailableHTTP-triggered invocation
WhatsAppPlanned
Web WidgetPlanned

See Slack Integration for the Slack-side setup.

Each channel chooses how incoming messages map to sessions:

StrategyBehaviourUse when
per_thread (default)Each thread is its own sessionSupport bots, Q&A
per_channelOne session per channelPersistent channel assistant
per_userOne session per userPersonal assistant

Schedule and webhook channels use their own routing model (shared session vs. per-invocation).

draft → published → draft → archived
  • Draft: configured but does not accept incoming requests.
  • Published: live; webhook requests are processed.
  • Archived: soft-deleted and hidden from listings.

Unpublishing stops new message processing; existing sessions remain accessible.

MethodPathDescription
POST/v1/appsCreate app
GET/v1/appsList apps
GET/v1/apps/{app_id}Get app
PATCH/v1/apps/{app_id}Update app
DELETE/v1/apps/{app_id}Archive
POST/v1/apps/{app_id}/publishPublish
POST/v1/apps/{app_id}/unpublishUnpublish

Full request/response schemas in the API reference.