Standing automations
Your agent builds the workflow.
Describe a routine once in chat. Your agent assembles it into a standing workflow, step by step and validated as it goes; you review it in a visual editor, test it safely, and turn it on. From then on it fires on a schedule or a webhook with nobody in the loop. Not even the agent.
Opens your agent straight away, no signup needed.
From a sentence to a standing automation.
§01Describe it
"Every morning, fetch the new issues, triage them with a model, and post the result to my webhook." That sentence is the spec: the agent builds the pipeline from a curated catalog of steps, each one validated as it's added.
Review and test it
The draft takes shape in a visual editor. A test run stops before the first step that would write anywhere outside the workflow, so trying it can't act on the world by accident. How workflows work.
Turn it on
It fires on a schedule, on a webhook URL of its own, or on demand from chat, the CLI, or MCP. Runs never wake the agent, so the routine keeps going while the agent sleeps.
A real pipeline, not a prompt on a timer.
§02A workflow run is not an agent turn. It is a fixed pipeline: HTTP requests to any API, JSON, CSV, and text transforms, an AI step that prompts a hosted model, custom TypeScript for logic the catalog doesn't cover, and a small key-value store for state between runs, such as cursors. The same steps run the same way every time. In v1 the pipeline is a straight line, trigger then steps in order, no branching yet.
Credentials the steps use are sealed the moment you save them: the model and the conversation transcript never see the value, and it is decrypted only when the workflow actually fires. In v1 a connection is a token, an API key, or a URL; registered services can use a managed OAuth 2.0 connection instead.
When each occurrence needs the agent's judgment instead of the same steps, use a scheduled run: one deferred agent turn. For the full picture of unattended work, see background agents.
Runs are cheap because no one is thinking.
§03You pay per run, not per step. One credit covers a run with any number of steps and the first 90 seconds of compute; past that, each started minute adds one more credit. Building and editing cost nothing. If a step calls an AI model, the model's own token rate applies on top (bring your own provider key and the model part drops to 0). The price is the same whether a schedule, a webhook, or you triggered it.
Free keeps 1 workflow active with 1 run at a time, Pro 5 active with 2 concurrent runs, Power 20 active with 5; drafts are always free. Every workflow carries its own monthly spend cap, and every run on every plan stops at a 24-hour safety limit, so a misconfigured schedule can't quietly drain your balance. The live rate card renders straight from the billing system.
Your own agent can build them too.
§04The same pattern works from outside. Point Claude Code, Cursor, or any MCP client at plori's MCP server and it can create a workflow, hand the building to a plori agent, fire runs, and read back execution results that mean what they say, all with a single API key. Your coding agent delegates the routine and gets back a standing automation it can check on any time.
Elsewhere this pattern usually means hosting your own workflow server and wiring an MCP bridge to it. On plori the agent and its workflows already live in the same place, so there is nothing to self-host and no bridge to maintain.
Questions, answered.
§05What is an AI-built workflow?
An AI-built workflow is a standing automation an AI agent assembles for you: you describe the routine in plain words, the agent picks and configures each step from a curated catalog, every step is validated as it is added, and the result runs on a schedule or a webhook without the agent in the loop. Researchers call the broader pattern agentic process automation: the agent designs the pipeline itself, then steps aside so it runs on its own.
How is a workflow different from a scheduled run?
A scheduled run wakes your agent and gives it a prompt. That is a full agent turn: the agent reasons, acts, and costs what a turn costs. A workflow is a fixed pipeline, no agent involved: same steps, same order, cheaper. Pick a scheduled run for "think about this tomorrow" and a workflow for "do this same thing every day".
Does a workflow run need the agent to be awake?
No. Runs fire on plori's infrastructure and never wake the agent, and the price is the same either way.
Can my own coding agent create workflows on plori?
Yes. Point Claude Code, Cursor, or any MCP client at api.plori.ai/mcp and it can inspect full workflow versions, create CAS-guarded draft edits, run workflows, and inspect executions with a single API key. The plori CLI mirrors list, create, run, and execution; definition editing is MCP-only. Building the steps themselves stays with your plori agent in chat.
What stops a test from acting on the world?
A test run is the default way to fire a draft, and it stops before the first step that would write anywhere outside the workflow. Read-only requests like GET run for real, so you see real data flowing through your steps, and custom code steps have their network access blocked during a test. When you want the side effects too, you explicitly ask for a full run.
How many workflows can I keep active?
Free keeps 1 workflow active with 1 run at a time, Pro 5 active with 2 concurrent runs, Power 20 active with 5; drafts are free and don't count. Anonymous trials can draft and test a workflow but need a signup to activate one. Every run on every plan is stopped at a uniform 24-hour safety limit, and each workflow has its own monthly spend cap, so a runaway schedule can't quietly drain your balance.