# DeepAgents + Brick: A Production Agent Harness at a Fraction of the Inference Cost

This guide solves both halves of cost and harness problem at once: adopt **DeepAgents** — LangChain's open-source agent harness — for the architecture, and you put **[Brick](https://regolo.ai/models/brick-v1-beta/)** in front of it as the inference layer. The harness gets smarter; the bill gets smaller.

> **DeepAgents gives your agent a production-grade harness (planning, subagents, filesystem, context management). Brick routes every model call to the cheapest model that can actually do the job, cutting inference cost by up to ~80% with no harness change.**

## The Two Problems

### The harness

A raw agent loop — model calls a tool, reads the result, calls again — works for demos. It breaks in production. The context window fills up. There's no way to delegate a heavy subtask without polluting the main thread. The agent can't read or write files. There's no human approval step before destructive actions. You end up rebuilding all of this by hand, poorly, on top of a bare `while` loop.

### The cost

Even with a good harness, you're calling one model for everything. The planning call that says "first I'll read the file, then I'll search the database" doesn't need your strongest reasoning model. But if you pin a cheaper model to save money, the hard reasoning call fails — and you can't predict which call will be hard. So you pay for the strong model on every call, including the easy ones. Over a multi-step agent run with 20-30 model calls, that compounds fast.

The fix is routing: send each call to the model that fits. Not a cascade (call cheap, escalate on low confidence — you pay for every miss). A single forward decision per query: read the call's capability requirements and complexity, pick the model whose skill profile matches, send it there. One call in, one call out. The agent never knows the model changed.

---

## DeepAgents: The Batteries-Included Harness

[DeepAgents](https://github.com/langchain-ai/deepagents) is LangChain's open-source agent harness — 27k stars, MIT-licensed, built on [LangGraph](https://github.com/langchain-ai/langgraph). It's the same building blocks as LangChain's `create_agent`, but with the pieces a production agent actually needs bundled in and tuned.

### What you get out of the box

| Capability | What it does |
|---|---|
| **Subagents** | Delegate tasks to child agents with isolated context windows. Heavy subtasks stay quarantined; the main thread gets a compact result. |
| **Virtual filesystem** | Read, write, edit, search files across pluggable backends (in-memory, local disk, LangGraph store). Declarative permission rules control access. |
| **Context management** | Summarize long threads, offload large tool outputs to disk, progressive skill loading from `SKILL.md` files. |
| **Code execution** | Sandboxed shell access via sandbox backends, plus an in-process QuickJS interpreter for deterministic transforms. |
| **Human-in-the-loop** | LangGraph interrupts pause before sensitive tool calls. Approve, edit, or reject before execution. |
| **Task planning** | Optional `write_todos` tool for structured task tracking on long multi-step work. |
| **Streaming** | Typed event streams for messages, tool calls, values, and subagent outputs. |

### Model-agnostic by design

DeepAgents works with any LLM that supports tool calling — frontier APIs (OpenAI, Anthropic, Google), open-weight models hosted on Baseten or Fireworks, self-hosted models via Ollama or vLLM, or any OpenAI-compatible endpoint. That last point is the integration: if it speaks the OpenAI chat completions API, DeepAgents can talk to it.

### This matters because Brick is an OpenAI-compatible endpoint. The wiring is one parameter.

---

## Brick: Mixture-of-Models Routing

[Brick](https://github.com/regolo-ai/brick-SR1) is Regolo's open-source Mixture-of-Models (MoM) routing gateway — Apache-2.0, written in Go and Rust. You point your agent at a single endpoint and set `model: "brick"`. Brick reads each request, classifies it, and routes it to the best backend in your configured pool. No cascades, no wasted calls — one forward decision per query.

### How it works

For every request, Brick computes two signals:

1. **Capability vector** — a soft assignment over six dimensions: `coding`, `creative_synthesis`, `instruction_following`, `math_reasoning`, `planning_agentic`, `world_knowledge`. Computed by a ModernBERT classifier.
2. **Complexity score** — `easy`, `medium`, or `hard`. Computed by a Qwen3.5-0.8B model with a LoRA adapter.

Each model in your pool has a measured skill vector along the same six dimensions: the router picks the model whose skill profile is closest to what the query needs, biased by a cost term.

### The cost evidence

Brick's repo includes a benchmark on Dataset A (n=5,504) with a 3-judge majority-vote eval panel (inter-rater agreement κ = 0.761). The results:

| Setting | Accuracy | Cost (× cheapest) | Avg latency |
|---|---|---|---|
| Always Qwen3.5-9b | 65.4% | 1.0× | 8.1 s |
| Always DeepSeek-v4-flash | 71.2% | 4.0× | 14.7 s |
| Always Kimi2.6 | 75.02% | 6.0× | 51.2 s |
| **Brick (max-quality)** | **76.98%** | **1.5×** | 22.8 s |
| **Brick (max-saving)** | 72.4% | **1.0×** | 9.4 s |
| *Oracle bound (3-model pool)* | *83.25%* | *n/a* | *n/a* |

Brick in max-quality mode beats always-Kimi (the strongest single model) at x4 lower cost and roughly half the latency — while producing better output.

**In max-saving mode, it matches always-DeepSeek quality at 1/4 the cost.**

Versus the strongest single model in the pool (Kimi at 6.0×), max-quality saves ~75% and max-saving saves ~83%. That is the basis for the "up to 80%" claim: it's the spread between routing and pinning the strongest model, measured on the repo's own benchmark.

### Five modes

Brick exposes the cost/quality trade-off as five named modes, from cheapest to strongest:

![](http://regolo.ai/wp-content/uploads/2026/07/image-2-1024x247.png)| Mode | Behavior |
|---|---|
| `eco` | Always cheapest model in pool |
| `lite` | Easy → cheap, medium/hard → mid-tier |
| `mid` | Default. Balanced routing across all tiers |
| `pro` | Easy/medium → mid-tier, hard → strongest |
| `max` | Always strongest model |

You can also slide the continuous `r` knob directly for fine-grained control between modes.

---

## Wiring DeepAgents to Brick

The integration is a single connection point: DeepAgents calls an OpenAI-compatible endpoint. Brick is an OpenAI-compatible endpoint. Point one at the other.

### Step 1 — Start Brick

The fastest path is the Docker image (no login required):

```
docker run --rm -p 18000:18000 \
  -e REGOLO_API_KEY=$REGOLO_API_KEY \
  docker.io/regolo/brick:latestCode language: Bash (bash)
```

Brick is now listening on `http://localhost:18000/v1`. Every request with `model: "brick"` gets routed.

To configure which models are in the pool, use the CLI:

```
git clone https://github.com/regolo-ai/brick-SR1 && cd brick-SR1
cd apps/cli && npm install && npm run build && npm link

brick init       # guided wizard: providers, models, classifier mode, cost/quality
brick serve      # starts the router with Docker ComposeCode language: Bash (bash)
```

The wizard writes `config.yaml` (router config), `.env` (API keys, never in YAML), and `docker-compose.yml`. You define the model pool, the skill vectors, and the cost/quality mode.

Verify routing works:

```
# A math prompt routes to a reasoning model
brick route "Prove that sqrt(2) is irrational" --no-generate --json

# A trivial prompt routes to the cheapest model
brick route "Hello" --no-generate --jsonCode language: Bash (bash)
```

The `x-selected-model` response header tells you which backend Brick picked for each request.

### Step 2 — Point DeepAgents at Brick

Install DeepAgents:

```
uv add deepagentsCode language: Bash (bash)
```

Create the agent with a `ChatOpenAI` instance pointed at Brick's endpoint:

```
from langchain_openai import ChatOpenAI
from deepagents import create_deep_agent

# Point at Brick — model is always "brick", Brick picks the real backend per call
model = ChatOpenAI(
    model="brick",
    base_url="http://localhost:18000/v1",
    api_key="your-regolo-key",
)

agent = create_deep_agent(
    model=model,
    tools=[search, fetch_page, run_query],
    system_prompt="You are a research assistant.",
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "Research LangGraph and write a summary"}]}
)Code language: Bash (bash)
```

DeepAgents sees a single model called `brick`. Every call — planning, tool selection, subagent delegation, summarization — flows through Brick, which routes each one independently based on capability and complexity.

### The planning call that decides "read file X, then call API Y" lands on a cheap model. 

The reasoning call that synthesizes results escalates to a stronger one.

### Step 3 — Add subagents with the same routing

DeepAgents' built-in `task` tool spawns subagents with isolated context. Each subagent also calls `model: "brick"`, so each subagent's calls are routed independently — a cheap subagent task lands on a cheap model while a hard one escalates in the same run.

```
from deepagents import create_deep_agent
from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="brick",
    base_url="http://localhost:18000/v1",
    api_key="your-regolo-key",
)

agent = create_deep_agent(
    model=model,
    tools=[search, fetch_page, run_query],
    system_prompt="""You are a research assistant.
    Delegate heavy research subtasks to subagents using the task tool.
    Synthesize their results into a final answer.""",
)Code language: Bash (bash)
```

No extra configuration. The routing is per-request, so subagents inherit the benefit automatically.

---

## Configuration: Controlling Cost vs Quality

### The `r` knob

In `config.yaml`, the `math.routing_preference` field (`r ∈ [-1, 1]`) is the continuous cost/quality control:

- `r = -1` — max-saving. Favors the cheapest model that can handle the query.
- `r = 0` — balanced (default).
- `r = +1` — max-quality. Favors the strongest model in the pool.

The five named modes (`eco` through `max`) are presets along this knob. Use `brick claude mode` (or `brick config edit`) to switch.

### Cache-aware routing

Switching models mid-conversation invalidates the prompt cache — each provider's KV cache is per-model. Brick handles this with three strategies:

| Mode | Behavior |
|---|---|
| `off` | Per-request routing, no cross-turn memory (default) |
| `sticky` | Keep a conversation on its current model unless switching is actually worth the cache re-priming cost |
| `smartsqueeze` | Same hysteresis as `sticky`, but compacts the forwarded context on a switch so the new model reprocesses a small prefix |

For agent workloads with long conversation threads, `sticky` prevents unnecessary cache thrashing while still routing hard calls to stronger models.

### Observability

```
brick claude status         # live dashboard
brick claude status --once  # static one-shot view
Code language: PHP (php)
```

The dashboard reports, since the last router restart:

- **Routed by model** — count and percent per backend
- **Per-model effort distribution** — reasoning effort spread within each model
- **Difficulty mix** — the classifier's easy/medium/hard verdicts
- **Economy** — estimated savings vs all-strongest-model baseline

For production observability, pair Brick's dashboard with LangSmith tracing on the DeepAgents side. Every agent run is traced with full tool call detail; every model call carries the `x-selected-model` header so you can see exactly which model handled which step.

## The Takeaway

DeepAgents gives you the harness — planning, subagents, filesystem, context management, human-in-the-loop — built on LangGraph, production-ready, model-agnostic. Brick gives you the routing — capability and complexity classification per call, single forward decision, up to ~80% cost reduction versus pinning the strongest model.

The integration is one parameter: `base_url` pointing at Brick, `model` set to `"brick"`. The harness doesn't change. The agent code doesn't change. Every model call that was hitting one expensive endpoint now hits the cheapest model that can handle it, escalating only when the task demands it.

Install DeepAgents. Start Brick. Point one at the other. That's the whole guide.

---

## Frequently Asked Questions

### What is DeepAgents?

DeepAgents is LangChain's open-source agent harness (MIT, 27k GitHub stars), built on LangGraph. It bundles subagents, a virtual filesystem, context management with summarization and skills, code execution, human-in-the-loop interrupts, and streaming into a single `create_deep_agent()` call. It is model-agnostic — any LLM that supports tool calling works.

### What is Brick?

Brick is Regolo's open-source Mixture-of-Models routing gateway (Apache-2.0). It reads each request's capability (six dimensions via ModernBERT) and complexity (easy/medium/hard via Qwen3.5-0.8B + LoRA), then routes it to the best backend in a configured pool of open- and closed-weight models. One forward decision per query — no cascades, no wasted calls. It exposes an OpenAI-compatible endpoint with `model: "brick"`.

### How does Brick reduce inference cost?

Not every model call needs the same model. A planning step that decides "read file X, then call API Y" doesn't need your strongest reasoning model, but a step that synthesizes complex results does. Brick reads each call's capability requirements and complexity, routes easy calls to cheap models and hard calls to strong ones. On Brick's own benchmark (Dataset A, n=5,504), max-quality mode beats the strongest single model (Kimi2.6) at 4× lower cost; max-saving mode matches mid-tier quality at 6× lower cost than the strongest model.

### Can I use open-weight models with this setup?

Yes. DeepAgents is model-agnostic and works with any OpenAI-compatible endpoint. Brick's pool can include open-weight models hosted on Regolo, self-hosted via Ollama or vLLM, or any combination of open and closed models. The routing algorithm works identically regardless of which models are in the pool.

### Do I need GPUs to run Brick?

No. The router and both classifiers (capability and complexity) run on CPU. GPUs only matter if you self-host the backend LLMs. With a hosted pool (Regolo, OpenAI, Anthropic), a CPU box is enough.

### How is Brick different from a cascade router like FrugalGPT?

A cascade calls models in sequence — cheap first, escalate on low confidence — and pays for every miss in tokens and latency. Brick makes a single forward decision per query from a capability vector and a complexity score, so there is no wasted call. See the comparison table in the [Brick README](https://github.com/regolo-ai/brick-SR1#-why-brick).

### Can I control the cost/quality trade-off?

Yes. The `r` knob (`r ∈ [-1, 1]`) slides the pool from max-saving (favors cheapest capable model) to max-quality (favors strongest). Five named modes — `eco`, `lite`, `mid`, `pro`, `max` — are presets along this knob. You can also configure cache-aware routing strategies (`off`, `sticky`, `smartsqueeze`) to avoid unnecessary prompt cache invalidation when switching models mid-conversation.

---

## Ship Private AI. Not Infrastructure.

You have the private AI App architecture, bow give it an inference layer built for production.

**Regolo** gives European teams fast, OpenAI-compatible access to Mistral, Llama, Qwen, DeepSeek, GLM, and more — with zero data retention, EU data residency, and no new SDK to learn.

Change your `base_url`. Keep your LangChain code. Start shipping.

### 🚀 [Start your 30-day free trial →](https://regolo.ai/?utm_source=blog&utm_medium=cta&utm_campaign=private-rag)

Build, test, and deploy with no infrastructure to maintain.
**No credit card. No migration project. No compromise on data control.**

### 💬 [Join the Regolo Discord →](https://discord.gg/bqGrVJHeF)

Meet builders working on private RAG, local LLMs, LangChain, Ollama, and production AI systems. Share your setup, get feedback from the community, and speak directly with the Regolo team.

### 🤝 [Talk to an AI Infrastructure Engineer →](https://regolo.ai/contact?utm_source=blog&utm_medium=cta&utm_campaign=private-rag)

Running a sensitive workload, scaling beyond a proof of concept, or assessing a managed EU inference provider? Get a tailored architecture and commercial proposal for your team.

### 📂 [Clone the GitHub repository →](https://github.com/regolo-ai/tutorials/)

Get the full implementation from this guide: ingestion scripts, ChromaDB setup, hybrid retrieval, the **30-Question RAG Floor**, evaluation examples, and deployment configuration.

> **Private AI should not require a private data center.**
> Regolo gives your team an EU-native path from local experimentation to production-grade inference.

---

### Build with Regolo

- **Discord:** [Join the community →](https://discord.gg/bqGrVJHeF)
- **GitHub:** [Explore open-source workflows →](https://github.com/regolo-ai/tutorials/)
- **X / Twitter:** [Follow @regolo\_ai →](https://x.com/regolo_ai)
- **Reddit:** [Join the community →](https://www.reddit.com/r/regolo_ai/)
- **Documentation:** [Read the API docs →](https://docs.regolo.ai)
- **Contact:** [Talk to the team →](https://regolo.ai/contact)

---

*Built with ❤️ by the Regolo team. Questions? [regolo.ai/contact](https://regolo.ai/contact)* or chat with us on [Discord](https://discord.gg/bqGrVJHeF)