LangGraph Multi-Agent Study Backend
A multi-agent backend is a graph of roles, tools, state, and handoffs, not just a pile of prompts.
Evidence, retrieval, agents, and the paths that connect a question to a grounded answer.
Interactive model
Routing and handoff as graph structure
Toggle between a tool-routing architecture and an agent-handoff architecture.
Live HTML simulation · adjust the controls and watch the computed output respond.
Interactive
Agent systems are graphs of state, routing, and tool access
This is a simplified teaching model. Its displayed values are computed from the controls; the article explains where the model stops.
Site connection
Lykke describes chat, study, weekly-plan, and orchestrator agents for routing course tasks across tools and LMS context.
A study backend coordinates qualitatively different work: answer from documents, generate quizzes, inspect Canvas deadlines, allocate study time, calculate formulas, and decide when outside search is allowed. LangGraph's official model makes the control plane explicit as state, nodes, and edges.
Start with the Workflow, Not the Agent Count
Multi-agent design helps when subtasks require different context, tools, permissions, or evaluation criteria. A source-grounded tutor, an artifact generator, and a calendar planner may benefit from separate contracts. When one agent with a small tool set can handle the request reliably, extra agents add model calls, latency, routing errors, and more places for source context to disappear.
The Lykke source explicitly reports a LangGraph multi-agent backend with Chat, Study, Weekly Plan, and Orchestrator agents. It also reports document-grounded chat, web fallback, Canvas-calendar planning, and specialized research, calculator, LMS-data, and stress-heatmap roles. Exact node topology, state schema, retry policy, and verifier behavior are not described and should not be presented as implemented facts.
Analogy limit: an agent graph resembles an organization chart only at a high level. Software nodes do not possess judgment or accountability; the graph must encode inputs, permissions, stop conditions, and error handling explicitly.
Typed State and Evidence-Preserving Handoffs
LangGraph state is a schema plus reducer functions that determine how node updates are applied. A study workflow should pass typed facts such as assignment IDs, due times, source passage IDs, learner constraints, routing reason, and unresolved gaps—not an ever-growing block of conversational prose.
Reducers require care. Appending messages may be appropriate, while replacing a current route or deadline may be correct for scalar fields. Parallel branches that both update a field need a deliberate merge rule; otherwise one branch can overwrite another or duplicate evidence.
| State field | Example type | Why it exists |
|---|---|---|
| request | string | Preserve the learner's actual question |
| course_scope | course IDs | Prevent cross-course evidence leakage |
| evidence | source ID + passage + timestamp | Keep claims traceable through handoffs |
| deadlines | assignment ID + due time | Represent calendar facts separately from prose |
| route | enum + reason | Make the routing decision inspectable |
| gaps | list of missing facts | Stop unsupported certainty from propagating |
Routing, Tool Calls, and Handoffs
A router can call a specialized subagent as a tool and keep central control, or it can hand off active control to another agent. Central routing fits predictable tasks and common policy enforcement. Handoffs fit conversations where a specialist must continue interacting, but they make ownership and context boundaries more important.
Recommended design policy: route with explicit predicates before asking a model to improvise. A request containing due-date constraints can require LMS retrieval before planning; a request asking only for quiz generation can go directly to the Study agent after document retrieval. Tool inputs and outputs should remain structured and source IDs should survive every transition.
| Pattern | Good fit | Main risk |
|---|---|---|
| Specialist as tool | Centralized policy and short subtasks | Orchestrator becomes a bottleneck |
| Agent handoff | Specialist-led multi-turn work | Unclear control and lost context |
| Parallel fan-out | Independent retrieval or critique | Merge conflicts and duplicated cost |
| Deterministic edge | Known policy or data dependency | Rigid if the predicate is underspecified |
Worked Example
A learner asks, 'What should I study before Friday if I have four hours?' The entry node records the request, timezone, course scope, and time budget. A deterministic edge sends the run to LMS retrieval because planning depends on current due dates. The retrieval node returns assignment IDs, due times, course labels, and source timestamps; missing Canvas access produces a gap instead of invented deadlines.
The orchestrator next routes relevant topics to the Study agent and constraints to the Weekly Plan agent. The study output contains topic priorities with source passage IDs; the planning output allocates four hours without changing the deadlines. A merge node checks that every scheduled topic has evidence and total duration is at most 240 minutes, then the response node cites the underlying course artifacts.
| Step | State added | Failure behavior |
|---|---|---|
| Classify | intent=weekly_plan | Ask for missing timezone or course scope |
| Retrieve LMS | deadlines + timestamps | Record access or freshness gap |
| Retrieve course evidence | topics + passage IDs | Do not invent unsupported topics |
| Plan | sessions totaling ≤240 minutes | Relax priorities, never rewrite due dates |
| Verify | coverage and citation checks | Return partial plan with named gaps |
Persistence, Recovery, and Human Review
LangGraph checkpointers save state by thread and support recovery, conversational memory, replay, and human-in-the-loop interrupts. Checkpointing does not make side effects exactly once: replay can re-execute later nodes, including API calls. Nodes that send email, create calendar events, or modify LMS data need idempotency keys, durable action records, or approval gates.
Recommended design policy: interrupt before consequential writes and show the proposed action, source evidence, target, and diff. Keep long-term learner profiles in an intentional store rather than allowing every transient message to accumulate forever in graph state.
Evaluation and Debugging
Evaluate the workflow at three layers: routing accuracy, specialist output quality, and end-to-end task success. Trace the route, model and tool calls, state diffs, source IDs, token cost, latency, and write attempts. A good final answer can still conceal a wrong route or an unsafe attempted side effect.
Build fixtures for ambiguous intent, stale LMS data, retrieval with conflicting due dates, one failed parallel branch, and replay after a checkpoint. Compare the multi-agent graph with a single-agent baseline; keep the graph only when specialization improves a measured outcome enough to justify its operational cost.
Common Pitfalls
- Adding agents before the workflow needs distinct context, tools, or permissions.
- Letting handoffs pass unstructured prose instead of typed state and source IDs.
- Using append reducers for fields that should replace or deduplicate.
- Treating checkpoint replay as exactly-once execution of side effects.
- Allowing a planning agent to alter retrieved deadlines rather than report missing evidence.
- Evaluating only the final prose while ignoring route, cost, state transitions, and tool attempts.