LangGraph Concepts in Plain Language: State, Memory and Orchestration

Official definitions of LangGraph are dense. The project's own tagline describes a low-level framework plus runtime for orchestrating agents that run for a long time and keep state. That may be accurate, but it isn't easy to feel on first read. This is the plain-language groundwork worth covering before writing any LangGraph code, framed around a planned second project in a learning path.

Why move to LangGraph now

Suppose a first project taught the basics: tool calling, MCP, remote tools and a small agent harness. That gives you a clear loop of model, tool, result, model again.

Tool calling
MCP
Remote tools
A small agent harness

What it doesn't explain is what happens when the workflow stops being a plain loop.

What if the workflow is not just a loop?
What if it branches?
What if it must remember the conversation?
What if different steps should have different jobs?

Those questions are what LangGraph is for. The goal here isn't yet another chatbot demo. It's a project that deliberately forces the use of state, routing and orchestration.

Unpacking the definition

Three words carry most of the weight: orchestration, runtime and stateful.

Orchestration

In simple terms, orchestration means coordinating steps that must happen in a certain order and sometimes branch. Think of a restaurant waiter.

Customer orders
     ↓
Waiter takes the order
     ↓
Kitchen cooks
     ↓
Waiter brings food
     ↓
Cashier takes payment

The waiter isn't the kitchen, and the kitchen isn't the cashier, but someone has to coordinate the flow. In an AI support workflow that coordination looks like this:

User asks a question
     ↓
Understand / classify the request
     ↓
Maybe ask for clarification
     ↓
Search documentation
     ↓
Write an answer

LangGraph helps when you want that coordination to be explicit and drawn as a graph, not tucked inside one giant function.

Runtime

The runtime is what actually runs the workflow. A useful comparison is a film script versus the production that shoots it. The graph is the script: which scenes exist and what follows each. The runtime is the production machinery: it performs the next scene, tracks where things stand and continues until the end.

You define nodes and edges
        ↓
You compile the graph
        ↓
You invoke it with a user message
        ↓
The runtime walks START → … → END

Stateful agents

A stateful agent keeps enough context to continue a conversation. A stateless one treats every message as if a stranger walked in.

Stateless looks like this:

User → “I teach at ABC School.”
Agent → answers, then forgets

User → “How do I enter grades?”
Agent → has no idea who you are

And stateful like this:

User → “I teach at ABC School.”
        ↓
      State remembers role / history
        ↓
User → “How do I enter grades?”
        ↓
Agent can use prior context

Booking a flight is a good analogy. If the agent forgets your destination between messages, you start over each time. Support chats feel exactly that way. State is how the system keeps hold of the thread.

Harness versus graph

With a harness, the loop is visible, which is the point of building one. LangGraph poses another question: could the workflow be modeled as a graph, with labeled steps, forks and persisted state, rather than one repeating generate loop? Not every project needs that. But it's worth learning before claiming to understand agent workflows.

Agent memory, split in two

It's tempting to treat memory as one blob. It isn't.

Short-term memory

This is memory for the current conversation or thread.

User: I am a teacher at ABC School.
…
User: How do I enter grades?

It's why turn two still knows turn one happened. In LangGraph terms it usually lives in graph state, especially the message list, and can persist across turns using a checkpointer and a thread id.

Short-term memory ≈ working memory for this conversation

The working-memory comparison is handy as long as you remember it's only an analogy.

Long-term memory

This covers information that should outlive one chat thread. Typical examples are user preferences, a school profile, lasting facts about someone's role and notes from earlier tickets.

Short-term ≈ RAM for this session
Long-term  ≈ persistent storage across sessions

The distinction that matters most: conversation history is not automatically long-term memory. A transcript inside the current thread is still session memory. Long-term memory is a separate design decision about what to store, for how long and how to retrieve it later. For a first build, thread memory is enough, with a full long-term profile store coming afterward.

Multi-agent orchestration without the hype

A single catch-all agent can be harder to follow than a handful of specialists. Building a house is the analogy.

Electrician
Plumber
Painter
Inspector

Nobody asks the painter to do the wiring, because the jobs differ. For a school support assistant, you can imagine a flow like this:

User
  ↓
Intake          (who is speaking? teacher / admin?)
  ↓
Classify / route
  ↓
Knowledge       (find the right docs)
  ↓
Support         (write the reply)

Splitting responsibilities has real benefits: each step is easier to test, it's easier to tell a routing failure from a document-search failure, and the mental model of the workflow gets clearer. Be honest about the limit, though. Multiple agents help when responsibilities genuinely differ. They aren't valuable just because the label sounds advanced.

Human in the loop

Sometimes the AI should pause and wait for a person before going on.

User request
     ↓
AI prepares an action
     ↓
Sensitive?
     ↓
Pause → human approval → continue

Typical cases include deleting student records, changing grades after publishing, refunds or payments, and escalating a ticket to a real administrator. Think of it as a safety and trust idea: agents may reason and act, but some decisions stay under human control. That's understood conceptually here and may be added later. One note: asking a clarifying question such as which area of the product someone means is helpful, but it isn't the same as human approval of a sensitive action.

How the pieces fit

Before writing code, the overall picture looked like this:

Orchestration  → who does what, and in what order?
Runtime        → what executes that plan?
State          → what do we remember while running?
Short-term mem → how does a multi-turn chat continue?
Long-term mem  → what should survive across sessions? (later)
Multi-agent    → when should steps be specialized?
HITL           → when must a human approve? (later)
Tools          → how does the agent reach outside knowledge?

LangGraph is appealing because it makes several of those pieces visible in the graph and not just buried inside prompts.

The practice project: a school support agent

To practice, the story is a support agent for LEPA, a school management system used by teachers and admins. Typical questions come from users locked out of their accounts, people registering a new student, teachers entering grades or wondering why they don't appear, staff taking attendance, and admins producing reports.

The exercise is about the flow between steps, and no clever model is needed to show that. The build proceeds in small steps:

1. State plus a tiny graph, going from START through one node to END
2. Intake, classification and conditional routing
3. A real knowledge tool over Markdown docs
4. An API with conversation memory using checkpoints
5. Graph visualization and clear documentation
6. Optional LLM polish on top of retrieved docs

Takeaway

LangGraph's definition feels heavy until it's unpacked. Orchestration is coordinating steps. Runtime is executing and tracking the workflow. Stateful means a conversation carries its context forward rather than restarting blank. Memory, multi-agent design and human approval are related ideas, and some belong in a first build while others can wait. Knowing which is which is part of the learning.