Module 02 · Agent Frameworks
Memory and State: Giving Agents Context That Persists
Open lesson + course map
On this lesson
Course outline
Module 1 · Agent Fundamentals
Module 2 · Agent Frameworks
Module 3 · Swarm Orchestration
Module 4 · Operational Guardrails
Module 5 · Shipping a Real Agent System
Persistent state lets a workflow resume and coordinate. “Memory” is often an overloaded label for conversation history, run checkpoints, customer facts, retrieved documents, or learned preferences. Store each kind deliberately; never dump everything into a vector database and call it memory.
After this lesson, you can design a state schema with authority, provenance, retention, and conflict rules.
// concept
Classify State
| Type | Example | Lifetime |
|---|---|---|
| run state | current step, attempt, tool result | one workflow plus audit period |
| business state | order status, assigned owner | authoritative business retention |
| conversation context | recent approved messages | shortest useful window |
| profile preference | chosen language | until changed/deleted |
| knowledge | approved policy version | versioned publication life |
| evaluation | expected and actual outcome | controlled improvement dataset |
The agent’s summary is not authoritative business state. Store order, payment, identity, and consent facts in their proper systems.
// concept
Add Provenance and Versioning
Every persisted fact needs source, timestamp, version, confidence where relevant, tenant, and expiry:
{
"key": "preferred_language",
"value": "roman_urdu",
"source": "customer_selection",
"recorded_at": "2026-07-19T10:00:00Z",
"tenant_id": "client_12",
"expires_at": null
}Summaries should link to the source records they represent. On conflict, follow an explicit rule; do not let the newest model-generated sentence overwrite verified data.
// concept
Checkpoint for Resume
Persist a state machine after committed transitions:
run_id, workflow_version, current_state, completed_actions,
pending_approval, budget_used, last_error, next_allowed_actionUse optimistic concurrency or locks so two workers cannot advance the same run. Tool effects remain idempotent if a worker crashes after the effect but before the checkpoint.
// worked_example
Worked Example
A recruitment assistant prepares interview packs. It stores job ID, approved criteria version, candidate reference, completed document checks, draft state, and pending reviewer. CV text has restricted retention and access. It does not store inferred religion, ethnicity, health, or family status.
A worker crashes after creating draft D-44. On restart, the system sees the stable idempotency key and retrieves D-44 rather than creating another pack. A recruiter correction is recorded as human-authored business state; a later model summary cannot overwrite it.
// failure_cases
Failure Cases to Diagnose
7 cases to diagnose
Full transcripts stored forever
define purpose and deletion.
Embedding used as exact lookup
retrieve authoritative IDs and fields directly.
No tenant filter
enforce tenancy in the data layer.
Concurrent workers overwrite state
use version checks or locks.
Model summary loses a critical exception
retain source links and typed fields.
Deleted customer remains in evaluation data
propagate deletion where required.
Workflow code changes mid-run
pin workflow version and migrate explicitly.
// pakistan_angle
Pakistan Angle
Minimize phone numbers, addresses, CNIC data, bank information, CVs, and customer messages. Do not store them merely to make future prompts “smarter.” Define who can access records, how an individual can request correction/deletion, and which legal or contractual retention applies.
For multilingual conversations, store the customer’s explicit language preference and original approved text where needed; do not persist a model’s guess about literacy or education. Keep PKR amounts, dates, and transaction references in typed fields, not narrative memory.
// hands_on
Hands-On Exercise
5 steps
Classify every field in one workflow.
Name its authority, source, tenant, retention, and deletion path.
Design the checkpoint schema and concurrency rule.
Test crash-after-effect, conflicting update, and deletion propagation.
Remove any field without a named purpose.
// completion_rubric
Completion Rubric
6 checks — tick as you verify
// sources
Sources
3 official sources — check every claim yourself
// check_yourself
Check yourself
4 questions · answers and options are taken word-for-word from this course
1 / 4 · diagnose
Your work shows this failure mode: “Full transcripts stored forever.” What does the lesson tell you to do about it?