Raven composable Agent Harness research

Raven: Composable Agent Harnesses, Host Orchestration & Evolution

Author: DeepSeekAgent.io Editorial Team
Published: Oct 13, 2026
Updated: Oct 13, 2026

Agent systems are moving beyond one model paired with one toolset. Research can go to a search specialist, repository work to a coding agent, and design or long-running operations to different executors. Raven takes this composition further by treating the model–harness pair, rather than the model alone, as the unit that can be scheduled.

The paper Raven: The Harness of Harnesses for Composable Agentic Intelligence, submitted on September 27, 2026, presents a complete architecture around that idea. A Host Agent decomposes goals, selects specialists, defines dependencies, and integrates results. Each execution node retains its own tools, context policy, and control rules. Persistent memory, Skill Forge, and harness evolution then carry useful experience into later work.

Why the unit is model × harness

The same model can behave very differently under another harness. File access, shell timeouts, compaction, tool-error feedback, memory, and completion judgment all affect whether the model can finish a task.

Raven therefore models an agent as the execution policy created by a model and its harness together. Its registry describes the capabilities and interfaces of each agent. The roster can include Raven-Research, Raven-Code, Raven-Design, and Raven-Oncall, plus adapters for Claude Code, Codex, OpenCode, Hermes Agent, and OpenClaw.

This differs from running several subagents with the same prompt and assigning each one a role name. Raven composes distinct execution environments and control policies, not just personas.

How the Host Agent organizes work

Instead of broadcasting the entire request to every agent, the Host Agent compiles the work into a directed acyclic graph (DAG):

split the goal into deliverable nodes;
select an executor for each node from the registry;
encode ordering and artifact dependencies as edges;
validate the graph and schedule dependency-ready nodes;
retain files, run records, and deliverables for downstream nodes;
resolve exceptions, request clarification, and synthesize the final result.

For a game project, research can run first; gameplay development and visual design can then proceed in parallel; integration, testing, and deployment follow after both branches complete. Explicit artifacts move across the graph, so an upstream agent does not need to restate its entire result in a chat message.

The difficult part of multi-agent work is rarely opening more sessions. It is preserving handoffs, getting dependencies right, and deciding who retries, reassigns, or stops after a failure.

Orchestration results with DeepSeek V4 Flash

The Multi-Agent Orchestration Benchmark evaluates planning without dispatching workers. Raven, Claude Code, and Hermes Agent receive the same request and delegation instruction. Each system uses Qwen3.8-27B and DeepSeek-V4-Flash-0731 over the same 140 tasks.

For the DeepSeek-V4-Flash-0731 group, the paper reports:

Metric	Raven	Strongest baseline	Difference
Node F1	0.963	0.854	+0.109
Edge F1	0.897	0.813	+0.084
Exact Match	0.867	0.762	+0.105

Node F1 measures specialist selection, Edge F1 measures dependency prediction, and Exact Match requires the accepted specialist set and precedence relations to agree with the reference. Raven's advantage therefore covers both who should do the work and how their deliverables should connect.

Raven-Research versus DeepSeek Harness on the same model

The paper also connects Raven-Research, DeepSeek Harness, and MiroFlow to the same backbone and gives them the same search and page-retrieval tools. On the DeepSeek-V4-Flash group of DeepResearch Mixed, it reports:

System	Accuracy	Mean input tokens	Mean output tokens	Estimated cost/question
MiroFlow	67.2%	3.737M	39.3k	$0.0374
DeepSeek Harness	68.9%	2.975M	31.8k	$0.0211
Raven-Research	76.5%	2.380M	41.6k	$0.0242

Fixing the model and tools makes search policy, context assembly, and completion behavior the main system-level differences. Raven-Research reaches the highest pooled accuracy at a slightly higher estimated cost than DSH while using fewer input tokens.

The harnesses retain different turn limits, time limits, and context policies, and the evaluation questions were also used while developing the research flow. The result is useful as an end-to-end workflow comparison, not as the isolated effect size of one component.

How a harness evolves

Raven does not let a live agent freely rewrite every part of itself. It exposes bounded, modular harness surfaces:

diagnose tool, context, or control-policy failures from traces;
generate candidate interventions;
run paired tests with the backbone frozen;
admit only candidates that pass validity and improvement gates;
preserve successful policies in a Harness Gene Bank for recombination.

The cited HarnessBank evaluation compares initial and evolved harnesses over seven benchmarks. With the Qwen3.6-27B backbone frozen, the paper reports Pass@1 gains ranging from 5.1 to 15.4 percentage points.

This is closer to an engineering release process than asking an agent to edit its own prompt and continue. Changes have boundaries, candidates are screened, versions can be compared, and regressions can be rolled back.

Memory and Skill Forge solve different problems

Raven separates long-term reuse into two paths:

Memory stores episodes, facts, user context, and cross-session experience: what happened before.
Skill Forge turns repeatable procedures into skills: what to do next time.

Skills are not limited to external catalog retrieval. Execution cases can be clustered by task intent, converted into explicit updates, validated, and stored with versions and lineage. Memory does not have to be copied wholesale into every prompt, and stable procedures do not need to be rediscovered from chat history.

Implications for DeepSeek Harness

Raven is less a proposal for one larger universal agent than a clearer set of system boundaries:

A Profile or Preset should describe an executable capability, not merely alias a model and prompt.
Agent Teams need explicit artifacts, dependencies, and completion criteria instead of free-form conversation alone.
Trajectories should support failure diagnosis, regression testing, and harness version evolution.
Model evaluations should record the harness version, tools, and context policy together.
Multi-agent budgets must include Host planning, worker execution, retries, and synthesis—not only the parent session.

For users, the practical question will increasingly move beyond “Which model does it use?” toward “Which harness surrounds the model, can it route work to a better executor, and can the result return through a reliable handoff?”