Skip to main content
A task is what you define once and run many times. It captures what should happen (discovery, navigation, extraction, API calls, or classic URL-based extraction), where inputs come from, and how results should be shaped. Executions are individual runs of that definition—the runtime history, status, and outputs.

​
What a task usually contains

Most tasks include:
  • A name
  • An objective (what success means in plain language)
  • An execution mode (for example single run or scheduled)
  • Optional template or script selection
Classic extraction tasks also specify:
  • One or more target URLs
  • An output schema for structured JSON (and media fields when applicable)
Modular tasks add action types (search, crawl, scrape, api_call), input sources, limits, payloads, or a full multi-step plan instead of relying only on the classic field layout. See Action types overview for how those pieces fit the API.

​
Why tasks matter

Tasks are the stable control-plane object you can:
  • List and filter
  • Update as sites or APIs evolve
  • Schedule or trigger manually
  • Tie to many executions over time
That stability is what makes Titan suitable for monitors, pipelines, and agent-driven retrieval, not only one-off scripts.

​
Execution types

The main distinction is:
  • Single-run tasks — ad hoc jobs, proofs of concept, or on-demand collection.
  • Scheduled tasks — recurring monitors, feeds, and anything that needs a time series of executions.

​
Output schemas

For extraction-heavy flows, the output schema is the contract between you, the platform, and downstream consumers: it describes the JSON shape you expect. Modular and multi-step tasks may attach schemas per step where the plan requires it; the API Reference lists the exact request shapes for your deployment.

​
Templates and tasks

Tasks can be authored from scratch or started from a template that encodes a proven pattern for a site or vertical. Templates help teams share defaults; the task remains your owned object for schedules, history, and updates.

​
Agentic tasks

Tool calls made through the MCP server create tasks too. Instead of one task per agent call, Titan reuses a durable agentic task per capability and adds a new execution for each call. That keeps an agent’s history in one place rather than scattering hundreds of near-identical task rows across your account. Agentic tasks carry extra fields that mark their origin: You can filter on these fields when listing tasks, so agent traffic is separable from tasks you author yourself. Executions, results, datasets, and billing behave identically to tasks you create through the API.

​
Owner-pinned tasks

Some extraction depends on the user’s own logins, sessions, and IP address—those do not transfer to third-party capacity. Set owner_required: true on the task and Titan routes every execution to a worker node that you own.
With owner_required: true:
  • Only nodes registered to your account are eligible to run the work.
  • Titan skips its shared IP, subnet, and domain rate-limit controls, because you pace your own capacity.
  • Leases, retries, recovery, and realtime dispatch behave exactly as they do for ordinary tasks.
If you have no eligible node online, executions stay queued until one becomes available. See Worker types for how to bring a node online.

​
Tasks versus executions

  • A task is the definition.
  • An execution is one run of that definition.
One task can have many executions. The task stays stable while executions capture status, errors, and exports for each attempt.

​
Next steps