> ## 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. # DSPy in fleet-rlm > How fleet-rlm composes native dspy.RLM, Signatures, instruction fragments, and DSPy sandbox-serializable inputs for one Turn against Daytona. Fleet runs on native `dspy.RLM` (DSPy 3.3.0). Every Turn constructs one fresh `dspy.RLM`, calls it once, and settles. There is no `dspy.ReAct` chat wrapper, no long-lived Agent, and no Fleet-owned RLM variable-mode monkeypatch. The maintained integration surface is the shipped Signatures, the delegation ladder, and the instruction fragments that compose the Root prompt. ## Where DSPy lives | Concern | DSPy primitive | fleet-rlm location | | ------------------------ | ------------------------------------------------ | ------------------------------------------------------------ | | One Turn = one fresh RLM | `dspy.RLM` | `src/fleet_rlm/rlm/runner.py` | | Default Root Signature | `dspy.Signature` | `src/fleet_rlm/rlm/dspy_contract.py` | | Skill Signatures | `dspy.Signature` (JSON-compatible common inputs) | Bundled Skill modules | | Instruction fragments | Instruction composition | `src/fleet_rlm/rlm/instructions.py` | | Recursive child dispatch | Native RLM harness | `src/fleet_rlm/rlm/recursive_calls.py`, `recursive_batch.py` | | Large inputs | `SandboxSerializable` | `src/fleet_rlm/rlm/inputs.py` | ## Configure models through profiles Model, provider, token, and recursion policy live in `config/fleet.toml` under the selected profile. There are no `DSPY_*` environment variables. Select the profile at the top of `config/fleet.toml`: ```toml theme={null} [config] default_profile = "daytona-recursive" ``` Provider environment variables are set by profile: * Interactive profiles (`daytona`, `daytona-recursive`) call OpenCode Go: `FLEET_OPENCODE_GO_API_KEY`, `FLEET_OPENCODE_GO_BASE_URL`. * Managed and benchmark profiles call the Databricks AI Gateway: `DATABRICKS_TOKEN`, `FLEET_DATABRICKS_AI_GATEWAY_BASE_URL`. * All committed profiles use `deepseek-v4-flash` for both Root and Sub. See the [configuration reference](/fleet-rlm/reference/configuration) for the full matrix. ## The Root Signature The default Fleet Root Signature carries a bounded, strict input surface. Every Signature receives: * `request` text. * Bounded `session_context`. * Bounded `skill_cards`. * Bounded Attachment metadata. Full committed history stays host-side behind the `read_session_history` Tool. The Signature uses strict local Pydantic DTOs; conversion and JSON serialization happen once immediately before native `dspy.RLM.acall()`. Custom Skill Signatures retain JSON-compatible common input annotations. Only one selected Skill may provide a validated custom Signature per Turn; `data-analysis` is the only bundled Skill that does so. ## Instructions are composed, not monolithic `src/fleet_rlm/rlm/instructions.py` owns the default Fleet Root instruction fragments: base, REPL, tool, optional recursion, verification, and bounded-context guidance. Fragments are composed directly; disabling recursion under a non-recursive profile omits recursion guidance rather than deleting text from one large monolithic docstring. ## Delegation ladder The Root selects the cheapest sufficient primitive: 1. Python in the interpreter for deterministic work. 2. Native `llm_query` / `llm_query_batched` for semantic work. 3. `rlm_query` for one iterative isolated subproblem. 4. Root-only `rlm_query_batched` for ordered independent child RLMs. Recursive children remain one native level deep. `RLM_NATIVE_CHILD_DEPTH = 1` is a fixed product invariant, not a policy value. Fleet reserves the shared recursive budget atomically before starting a child and bounds sibling concurrency through `recursion_max_parallel_children`. See the [Recursive RLM concept page](/fleet-rlm/concepts/recursive-rlm) for the isolation contract and the `[rlm]` bounds. ## Large inputs Long documents, workspace bundles, and durable Attachments cannot be inlined into the Root prompt. DSPy 3.3.0 ships the `SandboxSerializable` contract; Fleet builds host-constructed capsules that DSPy injects into the interpreter as REPL variables. For example, authorized Attachment context is packaged into `AttachmentContextCapsule` before the Turn runs: ```python theme={null} # src/fleet_rlm/rlm/inputs.py (host-side, illustrative) class AttachmentContextCapsule(dspy.SandboxSerializable): """Compact manifest for authorized immutable context already staged in a Volume.""" entries: tuple[AttachmentContextEntry, ...] mount_root: str ``` Inside the sandbox, DSPy reconstructs the value through `sandbox_assignment(...)` while the LM sees only a short `rlm_preview()` summary. Skill authors should not import capsule classes directly; the host builds them. ## Interpreter reuse within one Turn Within one Run, interpreter calls reuse one context. Python state persists across RLM iterations. Every later Run receives a fresh context, and replacing a Daytona Sandbox remounts the Workspace Volume Scope without preserving Python globals. ## Tracing `config/fleet.toml` `[mlflow]` policy controls DSPy tracing. Fleet enables MLflow DSPy inference autologging for the selected experiment; compile and evaluator traces stay disabled for live Turn observability. `mlflow.trace_content_max_chars` bounds each readable field, and `mlflow.async_logging = true` keeps trace export off the Turn critical path. See the [observability page](/fleet-rlm/concepts/observability) for the full policy. ## What is not here * No `dspy.GEPA` optimization API surface. Committed profiles are deterministic; there is no `optimize` subcommand and no `POST /api/v1/optimization/*` endpoints. * No `dspy.ReAct` `FleetAgent` chat wrapper. * No BYOK per-caller LM selection. * No Fleet-owned RLM variable-mode wrappers. Large inputs use DSPy's native `SandboxSerializable`. ## See also One-level recursive child boundary and `[rlm]` bounds. The one-Turn, one-fresh-RLM model and Skill disclosure. Turn SSE contract that every Signature runs behind. Profile matrix and provider environment variables.