TAI Labs
TAI Lightning Lesson · Free

Stateful
AI
agents

Design them without overengineering. The simplest thing that works.
Session
Live · one sitting
You bring
One agent that forgets · a workflow tool of choice
Led by
Aki WijesundaraAki Wijesundara
Manu JayawardanaManu Jayawardana
TAI Labs
The Agent Problem

Without state, agents are like talking to someone with amnesia.

01

Forgets everything

Between messages. Every request starts from zero, no matter what came before.

Amnesia
02

Repeats questions

You already answered them. The agent asks again because it can't see the earlier turn.

Loops back
03

Can't track progress

On multi-step tasks. It never knows which step it's on, so it starts every step over.

No place
04

Starts over

Every time you refresh. Every session is a first session. Feels like a chat demo, not a tool.

No memory
The gap: moving from chat demo to actually useful tool. State is what closes it. And you don't need a framework or a database on day one.
TAI Labs
By the end of this session

Three memory types, a three-node pattern, and a Lead Router you can copy tonight.

The receipt: the taxonomy of memory (conversation history, task state, long-term knowledge), the simplest state that works (a JSON blob), the Load → Agent → Save pattern that ports to any stack, and a Lead Router demo you can steal.
01
Name the three memory types. Conversation, task state, long-term. Different lifetimes.
02
Ship the simplest state that works. Workflow variables or a JSON object. Not a framework.
03
Learn the Load → Agent → Save pattern. Works in n8n, LangChain, Python, anywhere.
04
Copy the Lead Router. A stateful agent you can adapt to your own use case.
TAI Labs
Foundations · what is an AI agent

Agent = LLM + Tools + Decision Loop.

Regular chatbot

Question, answer, done.

Fixed path. One shot. No actions. Predictable and dumb.

Every turn is independent. Nothing accumulates. Great for simple lookups; useless for multi-step work.

AI agent

Question · think · pick tool · use tool · think again · answer.

Dynamic path. Loops until done. Takes actions, not just words.

The loop is the point. Every action feeds the next decision. Which is exactly why state matters · the decisions are only as good as what the agent remembers.

Concrete examples: a support bot that searches a knowledge base, a research agent that reads multiple sources, a lead router that qualifies and assigns. Each one takes actions and needs to remember what it already did.
TAI Labs
Architecture · single vs multi-agent

Start single. 80% of real cases stay there.

Single Agent · today

One job. Multiple tools.

Simpler, easier to debug, easier to state-manage. The support bot with three tools: search, ticket, escalate. That's the archetype.

One agent means one context to reason about. One trace. One state blob. One thing that can go wrong.

Multi-Agent · next level

Multiple specialists coordinate.

Each agent has its own role: research, writer, editor. Handoff between them.

Powerful when the work is genuinely parallel or truly specialised. Multiplies the ways things can fail. Skip until you need it.

80% of real use cases equal a single agent with good state management. The value is in the state layer, not the multi-agent orchestration. Get single-agent state right first.
TAI Labs
Memory · the taxonomy

Three types of memory. Different lifetimes, different jobs.

Conversation History

Short-term · session-scoped

Last ten messages. User said X, agent replied Y. Reset per session. What "remembers what I said" means for the user.

Session
Task State

Working memory · in progress

What step are we on. Has the search been done. Status flags (open, resolved, escalated). What the agent uses to decide the next tool.

Active task
Long-term Knowledge

Cross-session · optional

User preferences across sessions. Past tickets, past interactions. RAG or vector database if you have one. Not required for a working v0.

Only if you need it
Today we focus on the first two: conversation history and task state. The third one (long-term knowledge) is real work and belongs in a separate session. Ship the first two first; add the third when a real use case demands it.
The rule of the session

The context window is not memory. It's an attention budget.

Every token you spend in the window is a token the model has to attend to. Memory is what you PICK to put in the window on each turn · not what you dump into it. Storage is cheap; attention is the constraint. Engineer the state layer for the attention budget, not against it.

TAI Labs
Practical · storage

The simplest thing that works.

Bad approach
  • Complex frameworks before you need them.
  • External databases from day one.
  • Overengineered state machines.
  • Redis, Postgres, LangGraph, Redux · for a workflow that has one user.
Good approach
  • Workflow variables (n8n static data, LangGraph state).
  • Simple JSON object.
  • Append new messages to an array.
  • Trim old messages (keep the last ten).
Rule: start with in-memory or workflow variables. Add a database only when you have more than a thousand users, or when you need durability across process restarts. Every other complexity is bought too early.
TAI Labs
Concrete · the JSON blob

This is all the state you need to start.

the whole state store, for a v0
{ "session_abc": { "history": [ {"role": "user", "msg": "Hi"}, {"role": "agent", "msg": "Hello!"} ], "status": "open" } }
That's it. A dictionary of sessions. Each session holds its history (conversation memory) and a status field (task state). Trim history to the last ten messages when it grows. Ship this. Everything more complex is a graduation, not a starting point.
TAI Labs
Halfway through

We stop. We hear the room. We keep going.

What we do
  • Drop the one thing your agent keeps forgetting, in chat.
  • One line. Not the diagnosis. The forgotten moment.
  • Three or four get read aloud.
  • Then straight into the Load → Agent → Save pattern.
What this is for

Most "forgetting" is one of the three memory types.

Repeats questions? Missing conversation history. Doesn't know what step it's on? Missing task state. Forgets between sessions? Missing (or unnecessary) long-term knowledge.

The next slide is the three-node pattern that fixes all three.

The instinct to reach for a framework. Ignore it. Every framework has an escape hatch to a JSON blob and a state file. Start there.
TAI Labs
The pattern

Load → Agent → Save. That is it. Don't overcomplicate it.

Load State

Before the agent runs

Get sessionId from the trigger. Load the conversation history. Pass it to the agent as context. Read side only.

Read
AI Agent

The decision surface

Receives the incoming message plus the full loaded history. Makes decisions. Calls tools. Returns a response.

Decide
Save State

After the agent runs

Append the user message and the agent reply to history. Update task status. Write back to storage. Write side only.

Write
Works everywhere. n8n, LangChain, Python, whatever. The pattern is the pattern. The framework picks how you implement each node · Load might be a database read or an n8n Static Data node; Save is the mirror. Don't invent a fourth node.
TAI Labs
Live demo · a stateful lead router

One agent. Two tools. Real memory.

What it does
  • Qualifies inbound leads through conversation.
  • Remembers the previous turns.
  • Routes to sales when qualified; nurtures otherwise.
  • Tracks qualification status across turns.

Tools it uses

Google Sheets · logs qualified leads.
Built-in memory · conversation context.

The state it tracks
{ // Conversation history "history": [ {"role": "user", ...}, {"role": "agent", ...} ], // Qualification status "status": "open", // "qualified" | "disqualified" // Session tracking "sessionId": "lead_abc" }
The flow: Lead arrives → Qualify Agent (with loaded state) → Route Decision → Sales or Nurture. Load → Agent → Save wrapped around it. Copy the shape, swap the tools, ship your own.
TAI Labs
What you do this week

Give one agent a state blob.

01
Pick one agent that forgets. Support bot, lead router, task assistant. Anything conversational you own. Small scope. Not the whole product.
02
Add the JSON state blob. history array + status field + sessionId. Store it wherever your workflow allows · n8n static data, a JSON file, a hash in Redis. Whatever's shortest for your stack.
03
Wire the Load → Agent → Save pattern. Three nodes. Load reads state. Agent runs with state as context. Save appends the new turn. Ship v0 with only conversation history and a status field.
04
Try a five-turn conversation. Confirm the agent references what you said three turns ago. That's the whole test. If it can, you shipped stateful. If it can't, the Load node isn't reading what Save wrote.
The receipt: a working stateful agent (any tool: n8n, LangChain, Python) with a JSON state blob and the three-node pattern. Send us the workflow export or the code. We'll open Week 1 of the Agentic AI Engineering Bootcamp by reading three of yours together.
TAI Labs
The habit to take with you

Before you reach for a framework, reach for a JSON blob.

Every stateful agent you'll ever ship boils down to a load-node, an agent-node, and a save-node reading and writing a small object. Frameworks help when you have proven need. Skip them until you do. The engineers who ship stateful agents on their first try are the engineers who resist premature architecture.

Next

Agentic AI Engineering Bootcamp

Nine weeks. From loop to production. Certificate for engineers and AI PMs. Cohorts start monthly.

Where this leads
Now

Questions in chat

Post one line: the thing your agent keeps forgetting. Aki or Manu will read a few aloud and name the missing memory type live.

Open floor
Later

Your v0

Ship the three-node stateful agent. Email the workflow or repo. We reply with a short audio review before the bootcamp starts.

The receipt
01 / 14