> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qredence.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# fleet-rlm core concepts

> How fleet-rlm coordinates one native dspy.RLM per Turn over Daytona Sandboxes, streams typed Runtime Events over SSE, and persists committed Turn history.

`fleet-rlm` is an RLM-native backend. One Turn runs one fresh native `dspy.RLM` against a Daytona Sandbox with a workspace-scoped durable Volume, streams typed Runtime Events over Server-Sent Events, and atomically commits its result to Postgres.

## One Turn, one RLM

`TurnCoordinator` validates the deterministic local scope, Attachments, and exact Skill selections before opening SSE. `RLMRunner` then runs one fresh native `dspy.RLM`, and `RunLifecycle.finish()` owns result snapshot handling, Artifact publication, and atomic Turn Commit. The coordinator projects the terminal suffix and cleans up Run resources.

The Root uses Python, native Sub-LM queries, or isolated child RLMs according to a cheapest-sufficient delegation ladder. Recursive children remain one native level deep. Root-only `rlm_query_batched` provides ordered, bounded sibling fan-out, and the Root verifies and synthesizes their evidence before `SUBMIT`.

See [Recursive RLM](/fleet-rlm/concepts/recursive-rlm) for the full delegation flow.

## Daytona-backed execution

Daytona Turns acquire a fresh Interpreter Lease and use Workspace Volume Scope. Each Turn receives a bounded newest-record digest of Workspace Memory in its `session_context`; the full `memory/MEMORIES.md` log remains behind the host-mediated Memory Tools. The RLM may append a record only when the user explicitly asks to remember something.

Memory is immediate workspace state, not Session History or a Turn-commit record, and survives failed Runs and Sandbox replacement. Full Session history stays host-side behind the bounded `read_session_history` Tool.

See [Daytona runtime](/fleet-rlm/concepts/daytona-runtime) for lifecycle and Volume Scope details.

## Runtime surfaces

Fleet ships a backend and a maintained terminal client. There is no Fleet-shipped web UI.

| Surface                                     | Command                                            |
| ------------------------------------------- | -------------------------------------------------- |
| Supervised backend + pi-tui                 | `uv run fleet cli`                                 |
| Backend only                                | `uv run fleet web` or `uv run fleet-rlm serve-api` |
| Standalone pi-tui against a running backend | `pnpm --dir tools/fleet-tui start -- [options]`    |

All launchers default to `127.0.0.1` and reject non-loopback binds unless `--allow-non-loopback-bind` is passed. See the [CLI reference](/fleet-rlm/reference/cli).

## Policy-driven configuration

Non-secret runtime policy lives in `config/fleet.toml`. `[config] default_profile` selects one of the shipped profiles (`daytona`, `daytona-recursive`, `daytona-managed`, `daytona-bench`, `daytona-bench-40`). Policy is strict, resolved once at process startup, and takes effect only after restart. Only the environment variables named by the selected profile are read.

Fleet uses one deterministic local User and Workspace scope. It accepts no `Authorization` header or caller-supplied identity headers. The `/api/settings` endpoint is a separate loopback-only administration surface. See the [configuration reference](/fleet-rlm/reference/configuration) for the full policy structure.

## Observability

Every typed Runtime Event is projected as a bounded `Turn.progress.<event-kind>` child span through the centralized `EventRecorder`. This includes RLM reasoning summaries, generated code, interpreter output, tool inputs and outputs, status and progress events, structured results, streamed text, and the committed final answer. Live, reconciled, and committed events remain aligned. It does not export hidden provider chain-of-thought or arbitrary callback payloads.

Interactive profiles route traces to a local MLflow experiment at `http://127.0.0.1:5001`; the supervised `fleet cli` command starts or reuses that server. The managed profile writes to Databricks Unity Catalog. Benchmark profiles disable tracing.

See [Observability](/fleet-rlm/concepts/observability) for the full trace contract.

## Next

<CardGroup cols={2}>
  <Card title="Architecture" icon="sitemap" href="/fleet-rlm/concepts/architecture">
    Turn coordinator, RLM runner, Run lifecycle, and Daytona substrate.
  </Card>

  <Card title="Recursive RLM" icon="diagram-project" href="/fleet-rlm/concepts/recursive-rlm">
    Root delegation ladder, one-level child recursion, and shared budgets.
  </Card>

  <Card title="Daytona runtime" icon="cubes" href="/fleet-rlm/concepts/daytona-runtime">
    Sandbox lifecycle, Workspace Volume Scope, and Interpreter Leases.
  </Card>

  <Card title="Sessions & persistence" icon="database" href="/fleet-rlm/concepts/sessions-persistence">
    Committed Turn history, Alembic-managed Postgres, and durable Artifacts.
  </Card>

  <Card title="Observability" icon="chart-line" href="/fleet-rlm/concepts/observability">
    Runtime Events, MLflow tracing, and diagnostics.
  </Card>

  <Card title="HTTP API" icon="code" href="/fleet-rlm/reference/http-api">
    Turn streaming contract and error envelope.
  </Card>
</CardGroup>