A LangGraph deep agent that works on your laptop is a compiled graph plus a checkpointer in MemorySaver. Running it in production means threads that outlive a process, a store for memory, sandboxes for code, schedules, auth and traces. You have two ways to get there. Managed Deep Agents lets LangSmith run the harness and the runtime for you. The self-hosted SDK path, create_deep_agent on a LangSmith Deployment or in your own container, leaves the backend, store and checkpointer in your hands. The thesis of this last part is simple: Managed buys you sandboxes and schedules, and you self-host when you need your own backend, store or checkpointer.

LangGraph deep agents human-in-the-loop is one parameter: interrupt_on. You name the tools that need a person's sign-off, the harness pauses before those calls run, a reviewer approves, edits or rejects each one, and the run picks up from its checkpoint. The mechanics take ten minutes to learn. The harder question is which tools to gate. My thesis for this part: approval belongs on the irreversible tools only. Interrupt everything and humans stop reading, and a rubber-stamped approval is worse than none, because it looks like oversight.

A subagent is a context quarantine. LangGraph Deep Agents subagents let the main agent hand a heavy, noisy job — reading forty files, running a long search, grinding through a diff — to a separate agent, and get back only the conclusion. The parent's context window never sees the intermediate tool calls. That is the whole thesis of this part: delegate when the work is heavy and only the conclusion matters; keep the work inline when the parent needs the details.

Long runs fail on context, not reasoning. A LangGraph deep agent that plans, reads files, calls tools and delegates work will, somewhere around step 200, be carrying more history than the model can hold. When that happens the agent does not get dumber. It gets blind: the original goal scrolls out of the window, a 40,000-token tool result crowds out the plan, and the next decision is made on the wrong evidence. LangGraph deep agents context engineering is the set of mechanisms that keep step 200 looking at the goal: compression of history, offloading of large results to files, isolation through subagents, long-term memory, and prompt caching for the parts that never change.

A LangGraph deep agent gives you two places to put domain knowledge: skills and memory. They look alike, since both are Markdown files the agent reads, but they cost different amounts. Skills load lazily: the agent sees one line per skill until it decides it needs one. Memory loads eagerly: AGENTS.md goes into the context at startup, every time. The rule this post builds on is simple. Skills are lazy, memory is eager, so put each fact where its load cost matches how often the agent uses it.

A LangGraph deep agent can list, read, write, edit and delete files from the moment you create it, and with the right backend it can also run shell commands. That is the point of the harness, and it is also the risk. Deep Agents gives you three controls: declarative permissions= rules, sandbox backends that add an execute tool, and a QuickJS interpreter that adds eval. Each one guards a different surface. This post's argument: permissions guard the file tools, not the shell. Once execute exists, the sandbox is the boundary. If you mix those up, you can end up with an agent that obeys every deny rule and still prints your .env from the shell.

Every long-running agent needs somewhere to put things that do not fit in the next prompt: a draft, a search dump, a plan it will come back to at step 80. The LangGraph deep agents virtual filesystem is that place. The agent sees one set of file tools; underneath, a pluggable backend decides where the bytes actually live. The thesis of this post is simple: the filesystem is the agent's working memory, and the backend decides whether that memory survives the thread. Pick the backend by asking how long each file needs to live, not by what is easiest to wire up.

A LangGraph deep agent is only as useful as the tools it can call, and only as sharp as the tool list it has to choose from. Every tool you add is a name, a description and a JSON schema that the model reads on every single turn. That makes the tool surface a context budget, not a feature list. This part of the series covers the three ways to give a deep agent tools (plain Python functions, LangChain tools, and MCP servers), the built-in harness tools you get for free, and how to hide the ones you do not want with harness profiles so the model has fewer, better choices.

This LangGraph Deep Agents quickstart shows what one function call buys you. create_deep_agent returns a LangGraph agent that already knows how to write files, spawn subagents and summarize its own history. You add a model, a tool and a system prompt, and you have a research agent in under 30 lines. The catch is that each default has a cost and a behavior, and you should know what they are before you change them. Everything below comes from the public Deep Agents quickstart and the customization guide.

LangGraph Deep Agents is what you reach for when an agent has to keep working for a long time on a task nobody can fully script in advance. A model calling tools in a loop is easy to build. Keeping that loop on track at step 200 is harder: the plan drifts, the context window fills with tool output, and the work you could hand off sits in the same thread as everything else. Deep Agents takes the same tool loop and adds defaults aimed at those failures. In LangChain's own terms that makes it a harness, not a framework and not a runtime. This post explains what that difference means, how create_deep_agent compares with create_agent and a custom StateGraph, and what the harness gives you.