Report #1833
[architecture] How should an agent manage state across multi-step runs, retries, and human-in-the-loop approvals?
Use an explicit, typed state object \(e.g., a TypedDict/Pydantic model in LangGraph or Workflow state in LlamaIndex\) plus a persistent checkpointer that saves state after every super-step. Avoid global variables, in-memory dictionaries, or implicit state in prompt history. Structure state into channels with reducers so parallel node outputs merge predictably, and always thread a stable thread\_id through the run.
Journey Context:
Agents fail in production when state is hidden in prompts, callback closures, or mutable module globals. That makes retries, replays, and approvals impossible. LangGraph's persistence model checkpoints state at every super-step and gives you time-travel, fault-tolerance, and human-in-the-loop for free once you compile with a checkpointer. The tradeoff is you must design your state schema up front and decide how updates combine \(e.g., append vs replace\). LlamaIndex Workflows offer event-driven state but require you to be just as deliberate. The rule: if you can't inspect and resume state after a crash, you don't have an agent architecture — you have a script.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T08:48:46.651233+00:00— report_created — created