Whetstone.
Deep Agent DeployDeploying without writing deployment code
Module 6, Lesson 116 min

Deploying without writing deployment code

Everything up to here assumed you were authoring the deployment yourself: writing langgraph.json, pointing graphs at an entrypoint, choosing an environment. The deep agent path offers a shortcut, and the interesting question is not what it does but what it does not change.

What actually gets removed

The pitch is deploying without writing deployment code. That phrasing invites an over-reading, so be precise about the scope: what disappears is the scaffolding. The config file, the entrypoint wiring, the boilerplate that converts an agent into a deployable unit.

What does not disappear is your agent’s logic, your auth policy, or any of the architecture. You still have a deployment. It still has revisions. It still holds graphs, which still get default assistants, which still get paired with threads by runs.

That single sentence is worth more on the exam than any command, because it is the one that turns a whole module of new-sounding material into an application of material you already know.

Two CLIs, and which is which

By this point there are two command-line tools in the picture and it is worth separating them cleanly.

The langgraph CLI is the general tool: dev on 2024, build -t, up on 8123, dockerfile, and the Python-beta-only deploy that you do not have. It builds and serves any deployment regardless of how the agent inside it was authored.

The deepagents CLI is the higher-level path for getting a deep agent shipped without hand-authoring the scaffolding. It is a convenience layer aimed at one shape of agent, not a replacement for the general tool and not a workaround for the TypeScript gap.

The command surface, with a version stamp on it

Verified against the released deepagents-cli 0.2.2. Treat this as orientation rather than as something to memorise, for the reason in the next section, and re-check it if a question turns on a specific flag:

Command What it does
deepagents init [name] Scaffold a new agent project. --force overwrites existing files.
deepagents deploy Ship the project. --dry-run prints the payload without sending, --dir sets the project directory, --detach skips health polling, --reset discards local state, --yes skips the confirmation prompt.
deepagents agents list, get <id>, delete <id> against your deployed agents.
deepagents mcp-servers Register and manage MCP servers: list, add, get, update, delete, connect, tools.

Three things in that table matter more than the flags.

The binary is deepagents, not deepagents-cli, even though the package is named the latter and installs both names. --dry-run on deploy is the one flag worth remembering unprompted, because it is the safe way to inspect what a scaffold decided on your behalf, which is exactly the blind spot this whole path creates. And the interactive REPL is no longer here: it moved out to a separate deepagents-code package, so this CLI is deployment-only.

What to look up and what to know

This is the honest part, and it generalises well beyond this one tool.

Look up the commands. A young CLI’s exact surface, its flags and its prompts change faster than any course or exam can track, and a confidently misremembered flag is worse than an admitted gap. The exam is semi-open-book precisely because this category of knowledge is cheap to retrieve.

Know the relationships. That a deep agent compiles to a graph, that it is served by the Agent Server, that it therefore inherits the whole deployment model, and that the tool removes scaffolding rather than removing architecture. Relationships are what you cannot look up in ninety seconds, which is exactly why they are what gets tested.

The exercise worth doing

Before reading any documentation, write down from memory everything that has to exist for an agent to be deployable at all: which files, which config keys, which of them a scaffold could infer and which it would have to ask you about. Then check the list.

You will find the gaps run in both directions, and the direction that matters is the one where you invented something. A key you were sure existed and does not is exactly the kind of certainty that costs a mark, and finding it in a Devon barn is considerably cheaper than finding it in the exam.

Practice

Try it yourself

Quiz

What a no-code deploy path actually removes

The deepagents CLI is described as deploying without coding. What is the coding it removes?

  1. AThe agent's own logic, which the CLI generates from a natural-language description
  2. BThe deployment scaffolding: the config file and entrypoint wiring you would otherwise write by hand
  3. CThe authorization handlers, which the platform supplies for you on this deployment path
  4. DThe need for a graph at all, since a deep agent is an abstraction that replaces the graph
Show answer

Correct answer: B — The deployment scaffolding: the config file and entrypoint wiring you would otherwise write by hand

The scaffolding is what disappears: the config file, the entrypoint wiring, the boilerplate that turns an agent into a deployable unit. The tempting wrong answer is the last one, because deep agents are presented as a higher-level abstraction and it is easy to assume the abstraction replaces the graph rather than sitting on top of one: a deep agent is still a graph underneath, which is exactly why it deploys onto the same Agent Server. Nothing in this path removes your agent's logic or hands you free auth handlers.

Recall

What is running underneath

This is the fact that makes everything you learned in the other five modules still apply.

A deep agent deployed through the deepagents path is being served by what, and what does that mean for the rest of this course?

Reveal answer

It is served by the Agent Server, the same runtime that serves any other deployment. That means everything else in this course still applies to it unchanged: it has a deployment with revisions, graphs with default assistants, threads with the same four statuses, runs pairing an assistant with a thread, the same nine API groups, the same Postgres requirement, the same checkpointer and store, and the same authentication and authorization handler families. A different authoring path does not produce a different runtime.

Quiz

Two CLIs, two jobs

There are two command-line tools in play by this point in the course.

Two tools, different jobs
langgraph dev
deepagents ...
  1. AThey are two names for the same tool, kept alive across the old and the new branding
  2. Bdeepagents replaces the langgraph CLI entirely once a project contains a deep agent
  3. Clanggraph builds and serves any deployment; deepagents is the higher-level path for shipping a deep agent
  4. DThe langgraph CLI is Python-only, so TypeScript developers must use deepagents instead
Show answer

Correct answer: C — langgraph builds and serves any deployment; deepagents is the higher-level path for shipping a deep agent

The langgraph CLI is the general build-and-serve tool for any deployment, and the deepagents CLI is a higher-level path aimed specifically at getting a deep agent deployed without hand-authoring the scaffolding. The tempting wrong answer is the last one, because there genuinely is a Python-only gap in the langgraph CLI and it would be neat if this were the workaround: the gap is one command, langgraph deploy, and the rest of the CLI is available to everyone. The aliases option is worth binning immediately, since it borrows the real branding confusion from module zero and applies it to two genuinely different tools.

Recall

What to verify rather than recall

An honest boundary, and one worth internalising as a general test-taking instinct rather than a fact about this tool.

Which parts of the deepagents deploy path should you look up rather than recall, and which parts are safe to answer from memory?

Reveal answer

Look up the exact commands, flags and prompts, because a young CLI's surface changes faster than any exam or course can track, and a half-remembered flag is worse than an admitted gap. Answer from memory the relationships: that a deep agent still compiles to a graph, that it is served by the Agent Server, that it therefore inherits the deployment, revision, assistant, thread and run model unchanged, and that the tool removes scaffolding rather than removing architecture. In a semi-open-book exam the relationships are what you cannot look up quickly and the commands are what you can.

Do

Predict the scaffold before you read it

Do the predicting part offline. Check it against the docs whenever the wifi cooperates.

  • From memory, write down every file and every config key that must exist for any agent to be deployable at all.
  • Beside each one, write what a no-code path would have to fill in on your behalf, and what it could not possibly know without asking you.
  • Mark which of those items become a new revision when changed later.
  • Now check your list against the documentation for the deep agent deploy path and note what you missed in each direction, the things you invented and the things you forgot.
Done whenYou have a predicted file and key list with per-item notes on what a scaffold could and could not infer, revision-affecting items marked, and a written diff against the real documentation in both directions.
Sign in to track your progress →