Whetstone.
Deploy Your AgentThe agent, and the config contract that makes it deployable
Module 1, Lesson 216 min

The agent, and the config contract that makes it deployable

A graph on your laptop is not deployable. What makes it deployable is a contract that says which code to build, what to build it on, what it needs, and where its state goes. That contract is langgraph.json, and it is a build-time document. It says nothing about what happens at runtime, and that single distinction kills a whole family of wrong answers on its own.

The shape of the thing

langgraph.json, the common case
{
  "graphs": { "agent": "./src/agent.ts:graph" },
  "env": ".env",
  "node_version": "20",
  "auth": { "path": "./src/auth.ts:auth" },
  "store": { },
  "http": { }
}

The complete key set is dependencies, graphs, auth, base_image, image_distro, env, store, ui, python_version, node_version, pip_config_file, pip_installer, keep_pkg_tools, dockerfile_lines, checkpointer, http, webhooks, api_version.

Read that once slowly rather than memorising it cold. The exam is semi-open-book, so what you need is to recognise a key and know which family it belongs to, not to recite the set.

Four families, and the list stops being a list

  • What runs: graphs, ui, auth, http, webhooks
  • What it runs on: base_image, image_distro, dockerfile_lines, api_version, node_version, python_version
  • What it needs: dependencies, env, pip_config_file, pip_installer, keep_pkg_tools
  • Where state goes: store, checkpointer

That last family is the one the entire memory module hangs off, so notice now that both memory components are declared here, at build time, even though everything they hold is runtime data.

What is deliberately absent

Scan the key list again and notice what is missing. No assistants. No threads. No runs. No region.

That is not an oversight. Those are runtime objects, created through the API against a running server, and the region is chosen once at organization setup, which is a lesson of its own and an unhappy one. The config file’s job ends the moment the server is up.

env is where this file touches the vocabulary from the last lesson. Environment configuration is how secrets enter the deployment, and secrets are part of a revision. So the chain runs: env describes secrets, secrets are part of the deployed unit, and the deployed unit is what a revision versions. Editing what env resolves to is a redeploy, not a tweak.

Practice

Try it yourself

Recall

The two keys that do the work

Ignore the long tail for a moment. Two keys carry almost every real deployment.

Which two langgraph.json keys does essentially every deployment set, and what does each one do?

Reveal answer

graphs and env. graphs maps a name to the code entrypoint for each graph the deployment serves, which is what makes a deployment able to hold more than one graph. env supplies environment configuration, which is where secret values enter the deployment, and therefore the key that ties this file to the revision concept: change what env resolves to and you are cutting a new revision, not editing a live one.

Quiz

Spot the fabricated key

One of these four config snippets could never appear in a real langgraph.json.

Four candidate snippets
{ "auth": { "path": "./src/auth.ts:auth" } }
{ "http": { } }
{ "assistants": [{ "name": "default", "model": "claude" }] }
{ "graphs": { "agent": "./src/agent.ts:graph" } }
  1. AThe auth snippet, because auth is configured in the platform interface rather than in the file
  2. BThe http snippet, because mounting custom routes is a runtime concern rather than a build one
  3. CThe assistants snippet, because assistants are runtime objects and are never declared at build time
  4. DThe graphs snippet, because a graph entrypoint is a module path rather than a file path
Show answer

Correct answer: C — The assistants snippet, because assistants are runtime objects and are never declared at build time

There is no assistants key. Assistants are runtime objects created through the API against a running server, so they cannot be declared in a build-time contract. The tempting wrong answer is the http snippet, because custom routes genuinely do serve requests at runtime and it feels like a runtime concern: http is a real key, and what it configures is which routes get built into the server, which is a build-time decision about a runtime behaviour. auth and graphs are both real and both extremely common.

Recall

Build-time versus runtime objects

A quick classification drill that kills a whole family of wrong answers at once.

Assistants, threads and runs appear nowhere in langgraph.json. Why not, and what does that tell you about what the file is for?

Reveal answer

Because langgraph.json is a build-time contract and those three are runtime objects. The file describes what gets built and served: which graphs exist, what base image, which dependencies and environment, whether there is a store or a custom checkpointer, what auth handler to load, what HTTP routes and webhooks to mount. Assistants, threads and runs are created and manipulated through the API against a running server. So any answer option showing an assistants or threads key in the config file is fabricated and can be binned without reading the rest of it.

Quiz

Grouping the long tail

You will never memorise eighteen keys cold, and you do not need to. You need to place a key in a family fast enough that an option list stops being noise.

  1. Abase_image and image_distro describe where state goes
  2. Bstore and checkpointer describe where state goes
  3. Cdockerfile_lines and api_version describe what the deployment needs
  4. Dgraphs and node_version describe what runs
Show answer

Correct answer: B — store and checkpointer describe where state goes

store and checkpointer are the two keys that decide where state goes, which is why they are the pair the memory module later hangs off. The tempting wrong answer is the last one, because graphs genuinely does describe what runs: node_version does not, it describes what the code runs on. Mixing one correct half with one incorrect half is the most common shape of a plausible distractor, so read both halves of an option before accepting it on the strength of the first.

Check

Annotate the shape from memory

Do it on paper. The point is the grouping, not the spelling.

You should see

You have written out the four families with at least two keys in each, correctly placing graphs, ui, auth, http and webhooks under what runs, base_image, image_distro, dockerfile_lines, api_version and node_version under what it runs on, env under what it needs, and store and checkpointer under where state goes. You have also marked which keys in the what-it-needs family do not exist for TypeScript.

Sign in to track your progress →