Example: multi-step modular task

Scenario

You track pricing coverage across competitor blogs. You do not have a fixed URL list—you have a query. You want one task that discovers candidate pages, then extracts a structured record from each of them, without running two separate jobs and stitching results together yourself. This is what an execution plan is for: a task with more than one action step, where a later step reads the output of an earlier one.

Architecture

Recommended request flow

Step	API call
1	`POST /api/v1/tasks` with `execution_plan`
2	`POST /api/v1/tasks/:id/run`
3	`GET /api/v1/executions/:id/steps`
4	`GET /api/v1/executions/:id/steps/:step_id/results`

Step 1: create the task with an execution plan

Each step needs a step_id, an action_type, and an input_source. Set next_step_id to wire steps together, and set input_source: previous_step on the downstream step so it consumes what the upstream step discovered.

curl -sS -X POST "$TITAN_API_URL/api/v1/tasks" \
  -H "Authorization: Bearer $TITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Competitor pricing page discovery",
    "objective": "Find competitor pricing pages and extract plan names and prices",
    "execution_type": "single",
    "urls": ["https://search.brave.com/search?q=competitor+pricing+page"],
    "execution_plan": {
      "version": 1,
      "steps": [
        {
          "step_id": "discover",
          "action_type": "search",
          "input_source": "static_urls",
          "template_slug": "titan-brave-search-v1",
          "limits": { "max_results": 25, "timeout_seconds": 30 },
          "next_step_id": "extract"
        },
        {
          "step_id": "extract",
          "action_type": "scrape",
          "input_source": "previous_step",
          "template_slug": "generic-web-page-extraction-v1",
          "limits": { "max_urls": 25, "timeout_seconds": 60 },
          "payload": { "format": "markdown", "only_main_content": true },
          "retry_policy": { "max_attempts": 2, "backoff_seconds": 15 }
        }
      ]
    }
  }'

template_slug values must exist in your deployment’s template catalog. List what is available with GET /api/v1/templates, or see Use templates and preview runs.

Step 2: run the task

curl -sS -X POST "$TITAN_API_URL/api/v1/tasks/$TASK_ID/run" \
  -H "Authorization: Bearer $TITAN_TOKEN"

The response contains the execution_id for this run.

Step 3: watch step progress

A multi-step execution reports per-step state, so you can see which stage the run is in rather than only an overall status.

curl -sS "$TITAN_API_URL/api/v1/executions/$EXECUTION_ID/steps" \
  -H "Authorization: Bearer $TITAN_TOKEN"

Each entry carries a step_id, status, expected_count, and processed_count. The extract step stays queued until discover produces URLs for it.

Step 4: read results per step

Results are addressed per step, so you can inspect what discovery found separately from what extraction produced.

# What the search step discovered
curl -sS "$TITAN_API_URL/api/v1/executions/$EXECUTION_ID/steps/discover/results?limit=25" \
  -H "Authorization: Bearer $TITAN_TOKEN"

# What the scrape step extracted
curl -sS "$TITAN_API_URL/api/v1/executions/$EXECUTION_ID/steps/extract/results?limit=25" \
  -H "Authorization: Bearer $TITAN_TOKEN"

To export everything the run produced in one file, use GET /api/v1/executions/$EXECUTION_ID/results/export.

Retry behavior across steps

retry_policy is per step:

Field	Effect
`max_attempts`	How many times a failing work item is retried within the step
`backoff_seconds`	Delay between attempts
`fail_execution`	When `true`, exhausting retries fails the whole execution instead of continuing with partial results

Leave fail_execution unset when partial coverage is more useful than no results—a discovery step that finds 20 of 25 pages usually still has value.

Why this example matters

Multi-step plans are what separate a scraping job from a pipeline. The same shape scales to:

search → scrape for discovery-first monitoring
crawl → scrape for site-wide extraction
scrape → api_call for enrichment against your own services

Agents get the same capability without composing plans by hand—see MCP tool reference.

Example workflows

Scenario

Architecture

Recommended request flow

Step 1: create the task with an execution plan

Step 2: run the task

Step 3: watch step progress

Step 4: read results per step

Retry behavior across steps

Why this example matters

Next steps

​Scenario

​Architecture

​Recommended request flow

​Step 1: create the task with an execution plan

​Step 2: run the task

​Step 3: watch step progress

​Step 4: read results per step

​Retry behavior across steps

​Why this example matters

​Next steps

Scenario

Architecture

Recommended request flow

Step 1: create the task with an execution plan

Step 2: run the task

Step 3: watch step progress

Step 4: read results per step

Retry behavior across steps

Why this example matters

Next steps