#17
LangGraph Runtime Context Is Not Workflow State
Production LangGraph should not be responsible for proving who the user is.
Authentication happens before graph invocation.
Authorization happens before risky business actions.
That boundary matters in production LangGraph systems.
Authentication answers:
Who is calling this workflow?
Authorization answers:
What is this caller allowed to do?
State answers:
What does the workflow need to remember?
Context answers:
What does this specific run need to know?
State and context are not the same thing.
State is workflow memory.
It is what the graph needs to remember, update, persist, resume, and route on.
Examples of state:
- activeFlow
- waitingFor
- missingSlots
- idempotencyKey
Context is runtime execution data.
It is what the current run needs to know, but should not necessarily become part of durable workflow state.
Examples of context:
- userId
- tenantId
- role
- permissions
The API gateway, or backend layer should authenticate the request first.
Only after the caller is trusted should LangGraph be invoked.
At invocation time, the backend can pass runtime context into the graph.
That context belongs to the current run.
It carries execution data such as the authenticated user, tenant, permissions, channel, requestId, or trace metadata.
Nodes can read that context during execution to authorize actions, call tools, apply tenant rules, or enrich traces.
But context should not automatically be persisted as workflow state.
State remembers the workflow.
Runtime context carries who is acting.