Skip to main content
At the highest level, the platform has four layers. The same architecture supports classic extraction (URLs plus schema), modular tasks that combine search, crawl, scrape, and API-call actions—see Action types overview—and agent traffic arriving through the MCP server.
  • An agent layer
  • A user layer
  • A control plane
  • A worker layer

​
Platform diagram

​
Service responsibilities

​
End-to-end request flow

​
Agent request flow

Agent traffic follows the same control plane, entering through the MCP server instead of the Task Service API. The MCP server translates a tool call into a durable task and an execution, then returns the Titan execution_id as the MCP run_id. Short runs return results in the same tool call. Longer runs return a run_id the agent polls with titan_get_run. See Runs and results.

​
Ownership boundaries

These boundaries matter because they show integrators where to look first when building clients or debugging a workflow.

​
Execution routing

The Scheduler decides which worker receives a job. Two routing modes exist: Leases, retries, recovery, and realtime dispatch behave the same in both modes. See Tasks for how to set owner_required.

​
Why this structure matters

The public user model stays stable even if worker implementations change. Users and agents continue to create tasks, run executions, and fetch results from the same public interfaces while worker internals evolve behind the scenes.

​
Next steps