Module 5, Lesson 115 min

The project, and running it locally

The last module of the official course builds a project. Everything in it is assembly, and the assembly is where the defaults you inherited become decisions you made.

What “putting it together” actually means

By this point you have every part. A constructor, a model, a prompt, tools, MCP wiring, threads, gates, a backend, a shell policy, permissions, context thresholds, skills, memory and a subagent roster.

None of that is hard individually. The difficulty is entirely in which of them you configured on purpose.

Running it locally

A deep agent is a compiled StateGraph. That single fact answers most deployment questions before they are asked: anything that can serve a LangGraph graph can serve this, and the serving story belongs to the runtime rather than to deepagents.

So local deployment is not a deep agents topic wearing a disguise. It is the LangGraph deployment topic, and the specifics of local server commands and configuration live in the runtime’s own documentation. This course teaches the boundary and declines to invent CLI flags around it. In a semi open book exam, that lookup is cheap and a memorised flag is worth almost nothing.

The checklist that is actually the lesson

Every default here resolves toward capability

Before an agent runs anywhere that matters, six things must be decided rather than inherited:

Backend. Where the filesystem lives, and whether execute does anything at all.

Shell policy. Defaults to HostExecutionPolicy, which is full host access.

Permissions. Fail open. Every path you did not write a rule for is permitted.

interrupt_on. Empty unless you populate it, so nothing is gated.

Context thresholds. Offload tool results at 20,000 tokens and human messages at 50,000. Then one fraction, 0.85 of max_input_tokens, driving two mechanisms: argument truncation first, then conversation summarization keeping a 0.10 fraction. Where the model profile exposes no max_input_tokens, that pair is replaced by 170,000 tokens and 6 messages.

The memory and skills split. Nothing decides this for you, and getting it wrong is a permanent per-run tax.

Notice the pattern, because it is the honest summary of the whole library. Deep Agents defaults toward capability at every layer. That is a defensible choice for a tool aimed at capable agents. It is a genuinely dangerous one to inherit without reading.

Sorting the risk

Not all six are equal, and knowing the ordering is worth more than knowing the list.

The first three compose into a blast radius: a host shell, an open filesystem and no gates means an agent that can act on your machine, anywhere, unobserved. Get those wrong and the failure is an incident.

The last three cost you quality and money: a bad context strategy makes an agent that forgets, a bad knowledge split makes one that pays for instructions it never needed. Get those wrong and the failure is a bill and a disappointing demo.

Both matter. Only one of them is the reason to be careful before you press run.

Practice

Try it yourself

Quiz

Whose problem is deployment

You want to serve a deep agent behind an HTTP endpoint on your own machine. Which layer of the stack owns that concern?

ALangGraph, because a deep agent is a compiled StateGraph and serving graphs is its job
BDeep Agents, because it is the top layer and owns the finished product end to end
CThe middleware stack, since the tail middleware is what handles transport
DLangChain's create_agent, because that is where the agent is constructed

Show answer

Correct answer: A — LangGraph, because a deep agent is a compiled StateGraph and serving graphs is its job

A deep agent is a compiled StateGraph, so anything that can serve a LangGraph graph can serve it, and deployment is a runtime concern rather than a harness one. The Deep Agents option is tempting because that is the layer you actually typed, and it is easy to assume the top layer owns everything downstream of it. The layer-ownership question from module 1 answers this exactly as it answers the rest.

Recall

What must be decided before anything runs

Every item on this list has a default, and every default resolves toward capability rather than caution. That is the reason the list exists.

Name the decisions that must be made deliberately before a deep agent is run anywhere that matters, and say what each one defaults to if you leave it alone.

Reveal answer

The backend, which decides where the filesystem lives and whether execute does anything. The shell execution policy, which defaults to HostExecutionPolicy and therefore to full host access. The permission list, which fails open on any path you did not write a rule for. The interrupt_on list, which is empty unless you populate it, so nothing is gated. The context thresholds, which default to a 20,000 token offload, truncation at 85 percent of the window, and summarization firing at 85 percent of max_input_tokens keeping 10 percent. And the split between always-loaded memory and on-demand skills, which nothing decides for you.

Quiz

The three that bite

An agent is deployed with everything left at its default. Which trio is the genuinely dangerous one?

AEmpty base system prompt, opt-in planning, trimmed tool descriptions
BNo checkpointer, no thread_id, and no streaming on the endpoint
CHost shell policy, fail-open permissions, an empty interrupt list
DDefault offload threshold, default truncation, default summarization keep-ratio

Show answer

Correct answer: C — Host shell policy, fail-open permissions, an empty interrupt list

Those three compose into an agent that can run shell commands on your machine, reach any path you forgot to name, and do all of it without a human seeing it. The fourth option is the plausible decoy because context thresholds genuinely are defaults you inherit, but getting them wrong costs you quality and money rather than blast radius. Sort defaults by what happens when they are wrong, not by how many of them there are.

Quiz

Two minutes, docs open

A question turns on how a graph is served locally during development. Where does that answer live?

AThe deepagents reference, under backends and environments
BThe LangGraph platform and local server documentation
CThe middleware catalogue, under the tail middleware entry
DThe create_agent parameter reference, under checkpointer

Show answer

Correct answer: B — The LangGraph platform and local server documentation

Serving is a LangGraph concern, so it lives in the runtime's own deployment documentation rather than anywhere in the agent harness docs. The first option is the trap this module keeps setting: backend is about where the agent's filesystem and execution live, which sounds like infrastructure and is not the same question as where the graph is served from.

Write the spec before the code

Thirty minutes, one scratch file, no cloud account. This is the capstone in miniature and it is worth doing properly.

Pick an agent you would actually run unattended, and write down its purpose in two sentences.
Work down the pre-deployment checklist and write your decision for each item, with a reason attached.
For every number you wrote, mark it either documented default or deliberate override, and for the overrides say what evidence moved you.

Done whenEvery number in my spec is either a default I can name or an override with a reason, and none of them appears because it sounded about right.