Engines

An engine owns an agent’s loop — the part that turns a goal into generation and tool calls. The default engine is native (the in-process Dreadnode loop). Setting engine: claude-code delegates the loop to Claude Code while everything above the loop — sessions, the chat UI, evaluation, optimization, policy, and telemetry — keeps working, because the agent is still a first-class agent.

The throughline: bring a harness you already like onto the platform and make it evaluable, optimizable, session-backed, and governed — not a one-off integration.

---
name: coder
description: A careful coding agent running on Claude Code.
model: claude-sonnet-4-6
engine: claude-code
---

You are a careful senior engineer. Prefer small, well-tested diffs.

That one line is the whole change. The capability, its skills, and the way you push and run it are unchanged.

Note

claude-code needs the Claude Agent SDK and the claude CLI on PATH in the runtime: pip install "dreadnode[claude-code]". The platform’s runtime image already includes both.

Two ways to run a foreign harness

• Declare a built-in engine — engine: claude-code, the path this page covers. You configure a standard Claude Code agent through the agent’s fields, and the platform drives it.
• Author a custom engine — when you already have your own agent loop written against the Claude Agent SDK. You wrap your loop as an engine so your orchestration keeps running, while sessions, scoring, and evaluation ride on top.

How the engine is chosen

engine resolves with the same precedence as model: an explicit override at the call site wins, then the runtime default, then the agent’s engine: declaration, then native.

Where	Example
Agent frontmatter	engine: claude-code
Session creation (worker / SDK)	create_session(..., engine="claude-code")
Default	inherit → native

Unlike model, the engine is sticky for the session: it’s bound when the session is created and does not change per turn (the harness owns the session’s loop). model can still vary turn to turn within a session.

What carries over

Because a Claude Code agent is still an agent, you get the native experience:

• Sessions — a session row and a faithful transcript, including reasoning, in the chat UI.
• Traces — generation and tool spans, with usage and cost (model calls route through the inference gateway).
• Tool approval — when the session isn’t autonomous, Claude Code’s tool requests surface in the same approval prompt as native agents, and an evaluation worker auto-denies them. This covers every tool the harness runs, including its built-in tools.
• Scorers and detectors — attach exactly as they do for native runs.

Tools and skills under a foreign engine

This is the part to understand before you wire up a capability:

• Claude Code uses its own tools (Bash, Read, Edit, …). Your capability’s Python @tool and MCP tools are not injected into a claude-code agent — the runtime warns you, per turn, which capability tools are unavailable to it.
• tools: rules apply only within the harness’s own tool namespace; rule keys that don’t match a harness tool are inert.
• Skills use the shared SKILL.md standard and are portable in principle; surfacing capability skills into Claude Code is on the roadmap, not wired today.

Caution

A capability that mixes a native agent and a claude-code agent shares one tool pool, but the two agents consume it differently. The native agent runs your Python/MCP tools in-loop; the Claude Code agent uses its own. The runtime tells you what’s unconsumed so this is never silent.

Governance

Offloading the loop must not silently weaken policy, so the runtime reconciles your session policy against what the engine can actually enforce:

Policy facet	claude-code
Autonomy (block vs auto-allow)	enforced (permission_mode)
Step budget (max_steps)	enforced as max_turns (best-effort — turns ≠ steps)
Tool approval / HITL	bridged into the approval prompt
Mid-loop guard steering	observe-only → a guard policy is refused
Token / cost / time budgets	no harness equivalent — enforced by killing the run

If a policy needs something the engine can’t enforce, the runtime refuses the session rather than pretending (a guard policy on claude-code is rejected). Degraded-but-bounded facets (a token budget enforced by killing the run) produce a warning, not a refusal. You’ll also see a warning for any explicitly-set agent config the engine ignores (for example generation_timeout).

Evaluate

A claude-code agent is evaluated with the same tooling as a native agent. If your capability’s agent declares engine: claude-code, a managed evaluation already runs it on that engine. To override the engine at evaluation time (or to evaluate a model without a capability), pass --engine:

dn evaluation create my-eval \
  --capability [email protected] --agent-name coder \
  --model claude-sonnet-4-5 \
  --engine claude-code \
  --task my-task

The override threads through to the runtime session the eval worker drives, and governance reconciliation applies (a policy the engine can’t enforce is refused, not silently run). The evaluation’s runtime sandbox must contain the claude CLI — the platform’s runtime image includes it.

You can also evaluate locally with the SDK Evaluation harness (the agent runs on your machine; the run + scores sync to the platform). That appears under Runs, not the managed Evaluations list.

Optimize

Optimizing a claude-code agent’s system prompt and skills is planned — it rides the native-runtime optimization path. Not yet available.

See also

• Custom engines — bring your own Claude Agent SDK loop.
• Agents — the engine frontmatter field.
• Policies — what the runtime reconciles against.