Phase 7: AI Agents & Tool-Using Systems · 90 min · LangGraph · CrewAI Flows · AutoGen

State, Memory, and Workflow Graphs

Useful agents are stateful systems. The hard part is deciding what state is allowed to survive.

Hiring signal: Can design reliable stateful agent workflows instead of uncontrolled chat loops

The Problem

A student builds a job-search agent. It reads a resume, scores job posts, drafts outreach, and tracks applications. The first demo works. Then the product breaks:

It forgets which jobs were already rejected.
It reuses old resume facts after the user edits the resume.
It sends a draft before the user approves it.
It cannot resume after a browser crash.
It mixes private notes from one job with another.

The issue is not “the model has bad memory.” The issue is that the application has no explicit state model.

The Concept

Agent State Is Application State

The most common mistake in agent design is treating state as the LLM's problem — "the model will remember what it's doing." It won't. LLMs are stateless function calls. Every time you call the API, the model starts fresh, seeing only what you put in the context. If your agent needs to remember which jobs it already processed, what the user's resume says, or whether an email was approved, you must store that state and feed it back into the context on each call.

Agent state is not fundamentally different from any application state — it's data that persists between function calls, tracks progress through a workflow, and enables recovery from failures. The difference is that agents generate this state dynamically (the model decides what to do next), so the state model must be explicit and well-structured to prevent chaos.

You need to decide:

What is stored for this run only? — the current task, intermediate results, the current step in the workflow. This lives in memory or a short-lived database record and is discarded when the task completes.
What persists across sessions? — user preferences, resume content, job application history. This lives in a persistent database and is loaded when the agent starts a new session.
What is user-editable? — the resume, job preferences, outreach templates. The user can change these, and the agent must detect when they've changed (versioning) rather than using stale cached versions.
What is derived and can be recomputed? — job match scores, summary of qualifications. These don't need to be stored — they can be regenerated from source data, saving storage and avoiding staleness.
What is sensitive and should not be logged? — salary requirements, personal contact info, authentication tokens. Logging these creates compliance and security risks.
What state transition requires human approval? — sending an email, submitting an application, making a payment. These transitions must pause the workflow and wait for explicit approval.

Workflows Make State Explicit

Without a workflow, the agent is an unstructured loop: "call the model, let it decide what to do, repeat." This works for demos but fails in production because there's no way to enforce ordering, require approvals, recover from errors, or resume after crashes.

A workflow graph makes the agent's behavior explicit and controllable. You define nodes (steps like "retrieve profile," "analyze job," "draft email"), edges (legal transitions between steps), checkpoints (points where state is saved and can be resumed), and outcomes (success, failure, timeout). This transforms the agent from a black box into a debuggable, recoverable, auditable system.

Workflows make state explicit. Instead of "let the model keep going," you define nodes, edges, checkpoints, and outcomes.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Build It, Use It, Memory Design, Ship It, Evaluation, Common Mistakes, Common Pitfalls, Exercises, Key Terms, Interview Framing — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.

Key terms in this lesson

Agent