Course Content
Agentic AI Patterns
9 sections · 50 lessons
What are Stateful Agents, and how do they enhance decision-making accuracy?
What you need to know
What state holds
- Task state: goal, plan, step number, what is done and what is pending.
- Working data: tool results, or IDs pointing to them.
- Decisions: approvals received, choices made and why.
- Session context: user identity, permissions, budgets used so far.
Long-term memory (preferences, past episodes) is separate. State belongs to one task; memory spans tasks.
Why it improves accuracy
- No re-work. A stateless agent may re-fetch and re-decide, and get a different answer the second time.
- Full history. The agent sees every step of the case, not only the last message.
- Resumability. A run waiting 2 days for a vendor reply continues exactly where it stopped.
- Enables HITL, retries and time-travel debugging, all of which need saved state.
Risks and controls
| Risk | Control |
|---|---|
| Corruption spreads to every later step | Validate state against a schema on every write |
| Stale copy of external facts | Re-read the system of record for anything that can change |
| Unbounded growth | Store large items by ID; compact old entries |
| Leakage between users | Namespace state by tenant and user |
| Schema changes break old runs | Version the state and write migrations |
A real-life example
A procurement agent runs a request for quotation (RFQ) for 50 tonnes of steel over five days.
- Day 1: it sends RFQs to 6 vendors, checkpoints
{"sent": 6, "received": 0, "deadline": "2026-03-14"}, and stops. - Days 2 to 4: each vendor reply triggers a new run from the checkpoint. The agent extracts the quote, normalises it to price per tonne including GST and freight, and saves it. Vendor D's reply asks a question; the agent answers and records it.
- Day 5: the deadline event starts the final run. The state holds 5 normalised quotes and 1 decline. The agent re-reads current steel index prices from a live tool, not from Day 1, and flags that Vendor A's quote is now 7% above the index.
- The buyer approves; the approval is saved in state before the PO step runs.
An earlier stateless version re-read the whole email thread every day, sometimes missed Vendor D's revised quote, and once compared a revised price against an old one. The checkpointed design removed both errors, and each daily run cost a fraction as much because it read only new emails.
Follow-up questions to expect
- "Where do you store state?" — A durable store such as Postgres or a workflow engine's history, keyed by run ID, tenant and user. Not only in process memory.
- "State versus memory?" — State is the working record of one task; memory is knowledge kept across tasks. They have different lifetimes and deletion rules.
- "How do you handle a state schema change mid-run?" — Version the state, and either migrate old checkpoints or let old runs finish on the old code.