Worlds

Worlds is modeled as a control plane in the API and an execution backend in a separate Worlds runtime.

The API owns workspace scoping, auth, durable metadata, async job state, and artifact references. The Worlds backend owns manifest generation, manifest inspection, and trajectory generation.

Caution

The control-plane routes and persistence model are in place. The current execution path provisions a Worlds sandbox and calls the existing internal Worlds HTTP API there. Completed trajectory sample batches are persisted locally in that sandbox and published as datasets via the Dreadnode SDK; live inspection still depends on the backend while it is running.

Resource model

Worlds exposes three workspace-scoped resource groups:

• manifests for durable generated world graphs
• trajectories for durable attack-path samples derived from a manifest
• jobs for async creation, status, and cancellation

POST /api/v1/org/{org}/ws/{workspace}/worlds/manifests and POST /api/v1/org/{org}/ws/{workspace}/worlds/trajectories enqueue jobs instead of doing generation inside the API process.

In local environments, the API starts an in-process Worlds worker by default so queued jobs are claimed automatically. In other environments, run a dedicated worker or set WORLDS_IN_PROCESS_WORKER_ENABLED=true explicitly.

Read-only inspection routes also hang off manifests, for example graph nodes and edges, principal and host detail views, and command catalog discovery. Those routes are API-owned, but they should delegate to the Worlds backend rather than importing the Worlds library into packages/api.

Project alignment

Like evaluations and runtimes, Worlds resources stay workspace-scoped and use project_id as grouping metadata.

If a client does not provide a project_id when creating a manifest, the API resolves the workspace default project. Trajectory jobs inherit the manifest project so derived assets keep the same lineage. Manifest name is API-side metadata for the durable resource and is not forwarded to the backend generator.

Execution boundary

The API should not mount the demo Worlds FastAPI server directly.

The intended execution boundary is:

• API control plane in packages/api
• Worlds generation and sampling in a separate container or sandbox
• internal HTTP calls from the control plane to the Worlds server running inside that sandbox
• dataset publication for completed trajectory sample batches

Worlds backend sandboxes are internal compute sandboxes. They are tracked for lineage and cleanup, but they are not meant to behave like user-owned interactive runtimes.

That keeps Worlds aligned with the existing evaluation and runtime patterns instead of relying on process-global state.

Trajectory modes and artifacts

Trajectory sampling supports three modes:

• kali and c2 for algorithmic sampler paths
• agent for native SDK Agent rollouts

agent mode now supports two policy inputs:

• the preferred runtime-driven path: runtime_id + capability_name and an optional agent_name
• the legacy compatibility path: agent_model

The control plane resolves runtime-bound capabilities when the job is created and stores an immutable policy snapshot in the job payload. The Worlds backend then pulls that capability inside the sandbox and constructs the agent from the selected AgentDef, rather than embedding a fixed prompt and model in the backend.

If the selected agent model is a tinker://... checkpoint path, the Worlds backend can route inference through Tinker’s OpenAI-compatible endpoint by setting TINKER_OPENAI_BASE_URL and TINKER_API_KEY on the platform. Non-Tinker models continue to use the normal LiteLLM-backed sandbox inference path.

Completed sample jobs now persist a training artifact path in all modes:

• trajectories.training.jsonl for dataset publication and training ETL
• trajectories.atif.jsonl for algorithmic modes
• trajectories.raw.jsonl for native agent mode

agent mode does not emit ATIF; it emits raw SDK trajectory records plus normalized training rows.

For runtime-driven agent jobs, both artifacts also carry policy lineage such as the resolved runtime digest, selected capability, and selected agent name.

API surface

Worlds resources are workspace-scoped:

• POST /api/v1/org/{org}/ws/{workspace}/worlds/manifests
• GET /api/v1/org/{org}/ws/{workspace}/worlds/manifests
• POST /api/v1/org/{org}/ws/{workspace}/worlds/trajectories
• GET /api/v1/org/{org}/ws/{workspace}/worlds/jobs
• GET /api/v1/org/{org}/ws/{workspace}/worlds/jobs/{job_id}
• POST /api/v1/org/{org}/ws/{workspace}/worlds/jobs/{job_id}/cancel