Skip to main content
Platform actions expose selected Outlit platform configuration through the same API, CLI, and MCP surfaces that agents already use for customer context. They are meant for workflows where an agent needs to inspect or safely prepare configuration without clicking through the Outlit UI. Use platform actions for Outlit-hosted agents, automations, signals, destinations, selected workspace settings, and identity merge suggestions. Use Integration Routes for connecting external data sources such as Slack, Stripe, HubSpot, PostHog, or support tools.

​
How the Surfaces Fit Together

Each surface calls the same platform action contracts. The transport changes, but the intent does not: the API exposes the canonical route, the CLI wraps that route for terminal use, and MCP exposes the same operation as an agent tool.

​
Naming Model

Platform actions use resource-first names so humans and agents can predict what to call next: Subtypes and templates are inputs, not command names. For example, use outlit agents create --template churn to create a template-backed agent, and use outlit destinations create --type slack to create a Slack channel destination. Agent and destination updates patch only the fields provided. Automation and signal updates currently take full configuration bodies, so agents should read the current resource first, preserve fields they do not intend to change, and then send the updated body.

​
Current Scope

The current platform action set focuses on the Agents, Automations, Settings, and Identity areas of the Outlit platform. For example, a CLI user or agent can create a draft template and then explicitly enable or disable lifecycle resources:
Template creation creates supported template resources in draft mode. Draft creation does not enable an automation, add schedules, add external destinations, or send notifications by itself. Lifecycle write actions mutate only the named resource state. Automation create and update actions are agent-centered. Callers provide agentId; update bodies also provide name, enabled, and triggerType explicitly. Outlit maps the agent ID to the hosted-agent processor internally and does not require callers to construct raw processor JSON. For custom agents, put all surfacing and skipping guidance in instructions. Older split fields such as surfaceCriteria and skipCriteria are no longer accepted by the platform action create/update contract.

​
Safety Model

Platform actions are designed to make configuration inspectable before they make it broadly mutable.
  • Most non-identity read actions require an API key with the agents:read scope.
  • Most non-identity write actions require an API key with the agents:write scope.
  • destinations options is non-mutating, but it requires agents:write because it lists Slack channel choices used to create destinations.
  • Identity merge suggestion read actions require identity:read; queue and reject require identity:write. The identity resolution feature must be enabled for the workspace.
  • Template creation returns explicit safety metadata describing what was created and what was not enabled.
  • Enable actions validate the current platform state before enabling. For example, an automation cannot be enabled if required destinations or processor agents are unavailable.
  • Destination responses only include masked configuration through fields such as maskedConfig; raw secrets and unmasked provider configuration are not returned.
  • Responses are projected platform-action DTOs, not raw database rows.
  • Error responses use command envelopes with stable error codes such as authorization_denied, validation_failed, not_found, and conflict.

​
Response Shape

Platform actions return command envelopes. Successful responses include a commandId, commandVersion, correlationId, and result. The useful payload is under result.data. For example, outlit automations list --json returns automation data under:
Errors return ok: false with an error object and correlation ID so agents can report the failure precisely or retry only when the error is retryable.

​
Example Agent Workflow

A coding agent or MCP client can use platform actions to inspect what exists, choose a safe action, and leave the user with reviewable platform state:
This workflow lets the agent discover available templates, understand supported action capabilities, create a draft churn agent template, inspect the resulting agent and automation configuration, and then make explicit lifecycle changes.

​
Available REST Routes

The OpenAPI spec is the canonical reference for request and response schemas.