Skip to content

platform-actions.mdx

Latest commit

 

History

History
138 lines (106 loc) · 8.46 KB

platform-actions.mdx

File metadata and controls

138 lines (106 loc) · 8.46 KB
Raw
title Platform Actions
description 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.