Workflow DSL Explained: Build Complex Computer Use Agents with Task, If, Loop, Parallel, and Assert
Manual UI automation is fragile. XPath and CSS selectors break when an app updates. API-only tools cannot touch native desktop apps. The Coasty workflow DSL solves both problems by letting you define the full sequence an agent follows on a real screen. You compose reusable steps like tasks, assertions, conditionals, loops, and parallel branches into a versioned JSON document. The server runs the workflow on a cloud machine, step by step, and surfaces events for monitoring or webhooks. Each task step costs 5 cents. You control budgets, deadlines, and retries in one place.
How the workflow DSL works
A workflow is a versioned JSON object submitted to POST /v1/workflows. The body contains a schema_version and an array of steps. Each step can be a task, assert, if, loop, parallel, human_approval, retry, succeed, or fail. Task steps invoke the computer use agent to perform a high-level goal. Assert steps verify a condition after a task. If steps branch based on a condition object. Loop steps repeat a body while a condition holds. Parallel steps run multiple sub-workflows or tasks concurrently. Variables such as {{inputs.username}} and stepId.field let you reference inputs and step outputs. You can attach hard guards like budget_cents, max_iterations, and deadline_seconds to the workflow or individual steps. After creating a workflow, you start it with POST /v1/workflows/{id}/runs. Each run is billed at 5 cents per task step. You can inspect runs with GET /v1/runs and watch real-time events with GET /v1/runs/{id}/events (Server-Sent Events).
curl -X POST https://coasty.ai/v1/workflows \
-H "Authorization: Bearer $COASTY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"schema_version": "1.0",
"steps": [
{
"type": "task",
"name": "login",
"description": "Open browser, go to example.com, type username and password, click login button"
},
{
"type": "assert",
"name": "check_login",
"condition": {
"type": "contains",
"path": "{{login.outputs.page_content}}",
"value": "dashboard"
}
},
{
"type": "if",
"name": "has_dashboard",
"condition": {
"type": "exists",
"path": "{{check_login.outputs.result}}"
},
"steps": [
{
"type": "task",
"name": "export_dashboard",
"description": "Click export button and download CSV file to /downloads/export.csv"
}
]
},
{
"type": "loop",
"name": "process_items",
"condition": {
"type": "count",
"path": "{{export_dashboard.outputs.items_remaining}}",
"op": ">",
"value": 0
},
"max_iterations": 10,
"steps": [
{
"type": "task",
"name": "process_item",
"description": "Select the next pending item and mark it done"
}
]
},
{
"type": "parallel",
"name": "parallel_tasks",
"steps": [
{
"type": "task",
"name": "task_a",
"description": "Run task A in parallel"
},
{
"type": "task",
"name": "task_b",
"description": "Run task B in parallel"
}
]
},
{
"type": "succeed"
}
],
"hard_guards": {
"budget_cents": 1000,
"deadline_seconds": 600
}
}'Step types in depth
- ●Task: The main execution unit. Each task step triggers the computer use agent to read the screen and act. Task steps are billed at 5 cents each. You can reference outputs from previous steps using stepId.field.
- ●Assert: Verifies a condition after a task. The condition object supports types like contains, exists, equals, and count. The assert step does not cost credits but ensures the agent is on track.
- ●If: Branches execution based on a condition object. The condition references variables from inputs or previous steps. Only the steps inside the matching branch execute. Nested if and parallel steps are supported.
- ●Loop: Repeats a set of steps while a condition holds. You can use count, exists, or custom logic as the condition. Hard guards like max_iterations prevent infinite loops. Each iteration that runs a task incurs 5 cents.
- ●Parallel: Executes multiple sub-workflows or tasks concurrently. Parallel steps let you parallelize independent work and reduce overall runtime. You can combine parallel with if and loop for sophisticated pipelines.
- ●Human_approval: Pauses the workflow and waits for an external trigger. Useful for sensitive actions or manual review. The workflow state becomes awaiting_human until you resume or cancel.
- ●Retry: Retries a sub-workflow or task multiple times if it fails. You can set max_attempts and a backoff strategy. Each retry attempt is a new task execution and costs credits.
- ●Succeed: Marks the workflow as successful and terminates execution.
- ●Fail: Marks the workflow as failed and terminates execution. You can include an error message.
Each task step costs 5 cents. Use hard_guards to cap budget and deadline_seconds to control runtime.
Where this beats brittle automation
Traditional automation relies on fixed selectors that break when UI updates. The Coasty workflow DSL does not care about specific DOM elements. Instead, it describes high-level goals like open browser, type username, click login, and download CSV. The computer use agent reads the screen each step and acts like a human, adapting to layout changes. APIs alone cannot handle native desktop apps, file system dialogs, or complex workflows. The workflow DSL orchestrates both API calls and screen interactions in a single program. You can compose reusable workflows, reuse variable bindings, and enforce guards like budget and deadline across the whole pipeline. This makes agents robust, maintainable, and suitable for production.
Now you can design workflows that orchestrate tasks, branches, retries, and parallel work across browsers and desktops. Start building with the workflow DSL and see how a computer use agent behaves on real screens. Get your API key and start coding at https://coasty.ai/developers.