The Workflow DSL Explained: Task, Assert, If, Loop, Parallel
Marcus Sterling||7 min
⌘+K
Writing brittle scripts that depend on page IDs or API endpoints breaks fast. A button moves, a field name changes, or a service adds a new error type. The Coasty workflow DSL solves this by letting you describe the agent’s behavior as a versioned JSON plan. You can chain steps, retry on failure, run tasks in parallel, and ask for human approval. This guide explains each step type and shows a runnable example.
What the Workflow DSL is
- ●POST /v1/workflows creates a versioned JSON DSL of runs. Each workflow has a unique id and version number.
- ●Steps are executed in order by the Coasty agent. The agent uses the computer use API to drive real desktops, browsers, and terminals.
- ●The DSL supports these step types: task, assert, if, loop, parallel, human_approval, retry, succeed, fail.
- ●Task steps charge $0.05 per agent step. Parallel and loop steps are billed per step they invoke.
- ●You can reference variables like {{inputs.x}} and stepId.field inside conditions and actions.
Step types in detail
- ●task: defines a run with machine_id, task, cua_version (v3 or v4), instructions, system_prompt, max_steps, deadline_seconds, on_awaiting_human, and webhook_url. Each task step is billed $0.05.
- ●assert: checks a condition and fails the workflow if the assertion is false. Conditions are structured JSON objects.
- ●if: runs a block of steps only when the condition evaluates to true. Use it for conditional logic inside workflows.
- ●loop: repeats a block of steps up to max_iterations times. The DSL supports conditions and break points.
- ●parallel: runs multiple step blocks concurrently. Useful for tasks that can be executed independently.
- ●human_approval: pauses the workflow until approval is received. Options include pause, fail, or cancel when awaiting human input (on_awaiting_human).
- ●retry: wraps a block of steps and repeats it on failure up to a configured retry count.
- ●succeed: marks the workflow as successful. Falls through to the next step or ends the workflow.
- ●fail: marks the workflow as failed and stops execution. Useful for hard guards like budget_cents, max_iterations, or deadline_seconds.
bash
curl https://coasty.ai/v1/workflows \
-X POST \
-H "X-API-Key: $COASTY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "example-workflow",
"description": "Workflow with task, assert, if, loop, parallel",
"steps": [
{
"type": "task",
"name": "login",
"machine_id": "vm-123",
"task": "Log in to the dashboard",
"cua_version": "v4",
"instructions": "Select the email field, type the email, select the password field, type the password, and click the submit button.",
"on_awaiting_human": "pause"
},
{
"type": "assert",
"name": "verify_login",
"condition": {
"type": "exists",
"selector": "text",
"value": "Welcome back"
}
},
{
"type": "if",
"name": "has_admin_role",
"condition": {
"type": "exists",
"selector": "text",
"value": "Admin Dashboard"
},
"steps": [
{
"type": "task",
"name": "open_admin",
"machine_id": "vm-123",
"task": "Open the Admin Dashboard",
"cua_version": "v4"
}
]
},
{
"type": "parallel",
"name": "parallel_tasks",
"steps": [
{
"type": "task",
"name": "task1",
"machine_id": "vm-123",
"task": "Generate a report",
"cua_version": "v4"
},
{
"type": "task",
"name": "task2",
"machine_id": "vm-123",
"task": "Send an email",
"cua_version": "v4"
}
]
},
{
"type": "loop",
"name": "retry_login",
"max_iterations": 3,
"steps": [
{
"type": "task",
"name": "login_with_retry",
"machine_id": "vm-123",
"task": "Log in to the dashboard",
"cua_version": "v4"
},
{
"type": "assert",
"name": "verify_retry",
"condition": {
"type": "exists",
"selector": "text",
"value": "Welcome back"
}
}
]
},
{
"type": "human_approval",
"name": "final_approval",
"message": "Please confirm the workflow completed successfully."
},
{
"type": "succeed",
"name": "finish",
"message": "Workflow completed successfully."
}
],
"hard_guards": {
"budget_cents": 500,
"max_iterations": 1000,
"deadline_seconds": 3600
}
}'Running a workflow
- ●POST /v1/workflows/{id}/runs starts a new run of an existing workflow. You can also POST /v1/workflows/runs for ad-hoc inline workflows.
- ●Each run is a separate execution of the workflow DSL with its own state and inputs.
- ●GET /v1/workflows/{id}/runs lists runs for a workflow. GET /v1/runs retrieves all runs.
- ●A run can have states: queued, running, awaiting_human, succeeded, failed, cancelled, timed_out.
- ●POST /v1/runs/{id}/cancel cancels a running run. POST /v1/runs/{id}/resume resumes a paused run.
- ●GET /v1/runs/{id}/events streams Server-Sent Events for real-time progress. Use Last-Event-ID to reconnect.
Each task step costs $0.05. Parallel and loop steps are billed per step they invoke. Use hard_guards to enforce budget_cents, max_iterations, and deadline_seconds.
Where this beats brittle automation
- ●The Coasty workflow DSL is versioned and declarative. You can roll back to earlier versions and compare behavior across runs.
- ●Conditions like assert, if, and loop let the agent react to runtime state without hard-coded selectors.
- ●Parallel steps let you execute independent tasks concurrently, cutting total agent time.
- ●Retry and human_approval give you resilience to transient failures and the ability to intervene when needed.
- ●The agent drives real desktops, browsers, and terminals using the computer use API, not just API calls. This means it can handle UI changes, popups, and dynamic content.
The workflow DSL is a powerful way to define versioned, resilient computer use agents. Start by defining your first workflow with task, assert, if, loop, and parallel steps. Learn more and get a key at https://coasty.ai/developers.