Docs

Workflows

Standing automations your agent builds in chat: schedule, webhook, and manual triggers, safe test runs, credentials, per-run pricing, and plan limits.

A workflow is a standing automation that runs on plori without you or your agent in the loop. "Every morning, fetch the new issues, have a model triage them, and post the result to my webhook" becomes a small pipeline that fires on its own schedule, while your agent sleeps.

You don't assemble it by hand. You describe the automation in chat and your agent builds it step by step from a curated catalog of steps, each one validated as it's added. You review the draft in the visual editor, test it safely, and turn it on.

Workflows vs scheduled runs

A scheduled run wakes your agent later with a prompt: one deferred agent turn, with everything an agent turn costs and can do. A workflow is a fixed pipeline that runs without an agent turn at all: cheaper, repeatable, and exactly the same steps every time. Use a scheduled run for "think about this tomorrow"; use a workflow for "do this same thing every day".

Triggers

A workflow fires one of three ways:

  • On a schedule. Every N minutes, hourly, daily, weekly, monthly, or a cron expression you set.
  • On a webhook. The workflow gets its own URL under https://api.plori.ai/v1/hooks/... with an unguessable key. POST to it from any service and the delivery is accepted, buffered, and replayed into the workflow, with retries for up to an hour, so a brief platform restart between accept and run can't lose it. The caller always gets an immediate acknowledgment, not the workflow's result: a workflow can't write its own reply back to the caller yet. The URL only fires while the workflow is active.
  • Manually. Run it on demand from chat, from the CLI, over MCP, or the editor's "Run now" button.

Watch-style automations ("new items in this feed") are built as a schedule plus a durable seen-before check that lives in plori's database, so each item is delivered once even though the machinery behind a workflow is recycled between runs.

What steps can do

The v1 catalog covers:

  • HTTP requests to any API.
  • Transforms: JSON, CSV, text helpers, and a field-to-field data mapper.
  • An AI step that prompts a hosted model and returns its answer into the pipeline.
  • Custom code steps in TypeScript, for logic the catalog doesn't cover.
  • A small key-value store for state between runs (cursors, counters).

A v1 workflow is a straight line: trigger, then steps in order, no branching yet.

Credentials

Steps that call authenticated APIs use named connections. A connection can hold a directly supplied API key, bot/bearer token, multi-field credential, or secret-bearing URL such as a webhook. Registered services can instead use a managed OAuth 2.0 connection. Reddit Ads is the first managed OAuth provider.

You fill a connection once, from the Connect card in chat or the connections rail in the editor. The value is sealed the moment it's saved: the model and the conversation transcript never see it, and it's decrypted only when the workflow actually fires, directly into the machinery that runs it.

For Reddit Ads, create your own app in Reddit's developer console, register https://api.plori.ai/v1/oauth/callback as its redirect URI, then enter the app's client ID and client secret in the connections rail and choose Authorize. Plori stores the resulting grant for your account, refreshes it server-side when needed, and lets workflows or explicitly linked agent variables reuse it. For workflow runs, app secrets and provider tokens are write-only: the API never returns them to the editor, and they are not placed in the builder's prompt, transcript, or workflow definition.

Linking a grant to an agent environment variable is a separate, explicit trust choice. The fresh access token reaches that agent's command subprocesses, not its prompt. Plori removes exact secret values from command output before it reaches the model or saved events, but a model-controlled command can still transform or send the token. Bind only the provider access that you intend the agent's commands to use.

An “app” is not always OAuth. Telegram and Discord bots use bot tokens, Discord webhooks use a secret-bearing URL, and many services use API keys; save those through the matching direct connection fields. Another OAuth service needs a reviewed provider profile before Plori can run its browser grant and refresh flow. Plori does not accept arbitrary authorization or token URLs from a connection because that would let untrusted input choose where server-held credentials are sent.

Known services are wired automatically. When an HTTP step targets an API in Plori's channel registry, the platform places the connection exactly where that API expects it. Current direct profiles include Discord webhooks, Slack bot tokens, and TwitterAPI.io API keys. This keeps a generated step from, for example, guessing Bearer auth for an x-api-key service. Services outside the registry still work with an explicitly authored named connection reference in the request.

Testing safely

A test run is the default way to fire a draft, and it's built so a test can't act on the world by accident:

  • The run stops before the first step that would write anywhere outside the workflow (an HTTP POST, for example). Read-only requests like GET run for real, against the real API, so you see real data flowing through your steps.
  • Custom code steps run with their network access blocked during a test, whatever the code inside them tries to do.
  • When you're ready to exercise the side effects too, you can explicitly ask for a full run, which executes everything.

What workflows cost

Prices render live from the billing system on the pricing page; in short:

  • Building and editing are free.
  • A run that actually happened (it succeeded, failed, or hit the 24-hour runaway protection stop) costs 1 credit flat, any number of steps, with the first 90 seconds of runtime included, then 1 credit per additional started minute. Fires the platform skips or loses are never billed.
  • One price for every run, no matter how it starts: a schedule, a webhook, a manual run, or a test from chat. A run consumes compute, so a run is billed; the trigger never changes the price.
  • An AI step bills its model usage on top at the model's own rate, like any model call, so the flat fee alone is not the total for workflows that call a model. With your own provider key that model usage costs 0 credits.

Every workflow also has its own monthly spend cap, so a runaway schedule can't quietly drain your balance. When the cap is hit, or your balance is empty, fires are skipped and recorded rather than billed, and under the default notification setting you get a chat notice. A run that is already going and reaches the cap is stopped too, billing only the time it used. Set the cap in the visual editor's Settings panel (0 removes it), or over the workflow API with your API key: PUT /v1/workflows/{id} with {"spend_cap_month": <credits>, "base_version": <current version>}.

Limits by plan

Plan Active workflows Runs at once
Free 1 1
Pro 5 2
Power 20 5

Drafts don't count against the active limit; upgrading raises it. Anonymous trials can draft and test a workflow but must sign up to activate one.

Run length is not a plan feature. Every run on every plan is stopped at a uniform 24-hour runaway protection limit, a system safety stop for runs nobody meant to leave going forever. A run stopped there is billed for the runtime it used, like any run that finished on its own.

Notifications

Each workflow has a notification preference: off, failures (the default: a message in your agent's chat when a run doesn't succeed), all (a message on every run), or summary (the agent reads the result and posts a short summary, which is a billed agent turn).

Which agent owns a workflow

A workflow belongs to one agent: the one that built it. That agent is the only one that can see, edit, or run it from a chat. Ask a different agent about it and it will tell you it cannot find it. You still see every workflow in the web app and over the API, where they are grouped by agent, and you can hand a workflow to a different agent at any time.

In the web app, an agent's Workflows panel shows that agent's own workflows. Its dashboard page lists the same set, and each row opens the workflow in that agent's panel.

Workflows created outside a chat (over MCP or the API without naming an agent) start unassigned: yours to manage, but no agent's to edit until you give one to an agent. They appear in an "Unassigned" section under every agent's Workflows panel, where one click assigns the workflow to that agent. Deleting an agent never deletes its workflows; they move to that unassigned group, ready to be handed to another agent. Unassigning an active workflow does not pause its runs, but it stops chat notifications until you assign it to an agent again, even if its notification preference is failures, all, or summary.

From your own tools

The MCP server exposes list_workflows, create_workflow, run_workflow, and get_workflow_execution, and the CLI mirrors them as plori workflows list | create | run | execution. Building the steps themselves stays with your agent in chat.