Platform Actions

Inspect and configure Outlit agents and automations through API, CLI, and MCP

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, and destinations. Use Integration Routes for connecting external data sources such as Slack, Stripe, HubSpot, PostHog, or support tools.

How the Surfaces Fit Together

Surface	Use it when	Entry point
REST API	You are building your own app, backend job, or schema-driven integration	OpenAPI spec
CLI	You want a human or coding agent to run commands from a terminal	CLI commands
MCP	You want an MCP client to inspect or prepare platform configuration while assisting a user	MCP Integration

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:

Surface	Pattern	Example
CLI	outlit <resource> <verb>	outlit agents update <id> --instructions "..."
REST API	Standard resource routes	PATCH /api/agents/{id}
MCP	<resource>_<verb> tool names	outlit_agent_update

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 webhook to create a webhook 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 and Automations areas of the Outlit platform.

Area	Read actions	Write actions
Agents	List templates, list available actions, list agents, get one agent	Create, update, enable, disable, rename
Automations	List automations, get one automation	Create, update, enable, disable, archive
Signals	List configured automation signals, get one signal	Create, update, archive
Destinations	List configured destinations, get one destination with masked configuration	Create, update, enable, disable, archive

For example, a CLI user or agent can create a draft template and then explicitly enable or disable lifecycle resources:

outlit agents create --template churn --json
outlit agents create --type custom --display-name "Renewal risk" --instructions "Find risk" --surface-criteria "Surface risky customers" --json
outlit signals create --file ./signal.json --json
outlit automations create --file ./automation.json --json
outlit agents enable 10000000-0000-4000-8000-000000000004 --json
outlit automations disable 10000000-0000-4000-8000-000000000001 --json

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.

Safety Model

Platform actions are designed to make configuration inspectable before they make it broadly mutable.

• Read actions require an API key with the agents:read scope.
• Write actions require an API key with the agents:write scope.
• 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:

result.data.automations

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:

outlit agents templates --json
outlit agents actions --json
outlit agents create --template churn --json
outlit agents update 10000000-0000-4000-8000-000000000004 --instructions "Prioritize recent support escalations" --json
outlit destinations create --type webhook --name "Customer ops" --url https://hooks.example.com/outlit --json
outlit destinations update 10000000-0000-4000-8000-000000000003 --type webhook --name "Customer ops" --json
outlit agents enable 10000000-0000-4000-8000-000000000004 --json
outlit agents list --json
outlit automations list --json
outlit automations enable 10000000-0000-4000-8000-000000000001 --json
outlit signals list --json
outlit destinations list --json

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

Route	Purpose
GET /api/agent-templates	List supported agent templates
GET /api/agent-actions	List available agent configuration actions
GET /api/agents	List configured agents
GET /api/agents/{id}	Get one configured agent
POST /api/agents	Create an agent
PATCH /api/agents/{id}	Update one configured agent
POST /api/agents/{id}/enable	Enable one configured agent
POST /api/agents/{id}/disable	Disable one configured agent
POST /api/agents/{id}/rename	Rename one configured agent
GET /api/automations	List configured automations
POST /api/automations	Create an agent automation
GET /api/automations/{id}	Get one configured automation
PATCH /api/automations/{id}	Update one agent automation
POST /api/automations/{id}/enable	Enable one configured automation
POST /api/automations/{id}/disable	Disable one configured automation
POST /api/automations/{id}/archive	Archive one configured automation
GET /api/signals	List configured automation signals
POST /api/signals	Create one automation signal
GET /api/signals/{id}	Get one configured automation signal
PATCH /api/signals/{id}	Update one automation signal
POST /api/signals/{id}/archive	Archive one configured automation signal
GET /api/destinations	List configured automation destinations with masked configuration
GET /api/destinations/{id}	Get one configured automation destination with masked configuration
POST /api/destinations	Create one automation destination
PATCH /api/destinations/{id}	Update one automation destination
POST /api/destinations/{id}/enable	Enable one configured automation destination
POST /api/destinations/{id}/disable	Disable one configured automation destination
POST /api/destinations/{id}/archive	Archive one configured automation destination

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