LangChain Deep Agents in production: what the harness gives you, and what you still have to build

In this guide

• What does "deep agent" mean?
• What is an agent harness?
• What Deep Agents 0.7 ships
• What production still needs, and how Olano handles it
• Lessons from running it
• The key principles of harness engineering
• When LangChain's managed deployment fits better
• How Olano helps

What does "deep agent" mean?

A deep agent is one built to work through a long, multi-step task rather than answer in a turn or two: it plans, keeps notes outside its context window, hands sub-tasks to helpers and keeps going after the conversation outgrows the model's memory. LangChain's documentation describes Deep Agents as "designed for complex, multi-step tasks that require planning and decomposition", and the package README calls it "an opinionated agent that runs out of the box", with "defaults tuned for long-horizon, multi-step work" and an acknowledgement that it was primarily inspired by Claude Code. The depth comes from the harness, not from a special model: any chat model that supports tool calling can drive it.

What is an agent harness?

An agent harness is everything around the model loop. LangChain's own formula is "Agent = Model + Harness", where the harness is "the prompt, the tools, and any middleware that shapes behavior". By that definition LangChain's create_agent is a minimal harness and Deep Agents an opinionated one built on it, and both run on LangGraph, the runtime that saves, streams and resumes the loop. A harness is neither the runtime underneath nor the hosting around it, which is why "we use Deep Agents" answers only part of the production question. Our comparison of LangChain, LangGraph and Deep Agents sets out the three layers side by side.

Read the right-hand column as a list of decisions. A deep agent that is going to production makes each one explicitly:

from deepagents import create_deep_agent
from langchain.agents.middleware import TodoListMiddleware
from langgraph.checkpoint.postgres import PostgresSaver

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates the tables; safe to repeat
    agent = create_deep_agent(
        model="anthropic:claude-sonnet-4-6",
        tools=[lookup_order, refund_order],
        backend=sandbox,                      # not the in-state default
        checkpointer=checkpointer,            # threads survive restarts
        interrupt_on={"refund_order": True},  # a person approves refunds
        middleware=[TodoListMiddleware()],    # planning is opt-in since 0.7
    )

Here sandbox is a backend from a sandbox provider; LangChain's sandbox documentation lists providers including Daytona, E2B, Modal, Runloop, Vercel and its own LangSmith sandboxes. Every argument after tools is a choice the defaults leave open.

Lessons from running it: upstream behaviour worth knowing

None of these is a bug. Each is documented upstream behaviour that surprises people moving from a notebook to a deployment.

• Planning is opt-in since 0.7. Earlier versions included the write_todos tool by default; a deep agent built from an older tutorial no longer plans unless you add TodoListMiddleware.
• The default filesystem is the checkpoint. The in-state backend saves files with every step, so LangChain advises against large files there, and files a subagent writes stay visible to the parent afterwards.
• An unknown model changes summarisation silently. A model newer than its provider package has no window in its profile, so the 170,000-token, six-message fallback applies and an agent forgets the start of a short session. Set the window yourself; our guide to switching LLM providers shows how.
• Summaries arrive in the stream. Tokens from the summarisation call stream like reply tokens unless you drop chunks whose metadata carries lc_source: "summarization". The streaming debugging guide covers this and its cousins.
• Offloads land at the backend root. Large tool results go to /large_tool_results/ and evicted history to /conversation_history/ on the default backend. LangChain suggests keeping that default in state; if it maps to real disk, decide where those folders go.
• Approvals need the same thread. An interrupt resumes only through a checkpointer and the same thread_id, and several approvals in one step arrive as one batch that needs a decision for each, in order. Our checkpointer guide covers the storage side.
• A sandbox protects the host, not the data. LangChain's documentation is explicit that sandboxes do not stop prompt injection from running commands inside them, or data leaving over the network, so keep secrets out of the sandbox.

What are the key principles of harness engineering?

Harness engineering is improving an agent by changing what surrounds the model (its prompt, tools and middleware) rather than the model itself. Five principles recur in LangChain's documentation and in our own setup:

1. Keep the context small and relevant. Offload big results, summarise old turns, and send heavy sub-tasks to subagents that return one report.
2. Enforce boundaries in tools and sandboxes, not the prompt. In the README's words: "Enforce boundaries at the tool/sandbox level, not by expecting the model to self-police."
3. Make every step durable and inspectable. Checkpoints let a run resume and let you read what happened; traces or local callbacks show why.
4. Put a person in front of consequential actions. Interrupts for anything that spends, sends or deletes.
5. Tune the harness to the model. Deep Agents supports harness profiles per provider or model, which change the prompt, tool descriptions and visible tools without forking.

When LangChain's managed deployment fits better

LangChain offers its own route to production. Its documentation recommends Managed Deep Agents, "a CLI-first hosted runtime" in public beta on LangSmith Cloud: you author the agent as a project of files, and it runs the same harness on LangSmith's Agent Server with threads, streaming, sandboxes and schedules. Teams needing custom application code or authentication can use a LangSmith Deployment directly, which provisions the checkpointer and store and adds authentication, webhooks, cron and observability.

That is the better choice when your team writes the agent in Python, wants tracing and evaluation in LangSmith alongside it, or the agent is the backend of your own product. Olano fits when the agent works for a business on the channels its customers and staff already use, approvals are made by people who never open a terminal, and you want a dashboard, a credential vault and managed models rather than a codebase.

How Olano helps

Every Olano agent runs the Deep Agents harness on LangGraph and LangChain, with the right-hand column of the table above already built and maintained: production checkpoints, an isolated workspace per agent, a context policy from the model's real window, approvals with an inbox, a per-agent vault, channels, schedules and Cortex, and turns that outlive the browser tab. The Olano platform page covers the product, and security covers isolation, approvals and audit. The limit is the same one as in the managed-deployment comparison: Olano agents are configured in a dashboard or by chat, not written as Python, so code-level customisation of the harness belongs on the libraries directly.