Return one more time to the demo greeting: “Hi Ajitesh. Great to have you back. Today we’ll dive into another classroom scenario and sharpen those escalation strategies together.”
Now imagine the same product without memory: “Hello! I’m your teaching coach. What’s your name? Have we worked together before? What would you like to practice today?” Every single session, forever. By the fifth time the user answers the same onboarding questions, they quietly churn. Nobody files a bug report for this. They just stop coming back.
The difference between those two products is not model quality, latency, or voice. It is one design surface: memory. Without it, every session starts from zero: no continuity, no progress, no relationship. Memory is what turns a demo into a coach.
Memory vs. history vs. state
Three terms builders conflate, worth separating once:
Conversation history is the transcript of the current session. It is managed automatically, grows every turn, and dies (or is archived) when the session ends. You met it in Chapter 6 as component three of the context.
Memory is the curated residue that survives across sessions: who the user is, what happened before, what comes next. Small, structured, deliberate, and entirely a design artifact. Nothing persists unless something decided to persist it.
State is where the agent is right now: the current flow step, the active scenario, pending tool results. Session-scoped and machine-managed.
The agent equation from Part 1 (reasoning plus tools plus state) gets its third pillar its full meaning here: memory is engineered state that outlives the session.
What to remember is a product decision
The technical machinery of memory (next chapter) is largely solved and largely platform-provided. The part that cannot be provided for you is the schema: what, exactly, should your agent remember?
Start with the defaults that most platforms write down automatically, because they transfer to almost any scenario unchanged: a summary of the previous conversation, the user’s preferences, and what should be covered next session. That trio alone kills the re-onboarding failure above.
The fourth category is where you must actually think: domain-specific facts. The heuristic that cuts through it: imagine you are the human coach meeting this person again next week. What would you want to remember about them?
And the research move behind the heuristic: look at what human experts in your domain actually note down. Peek at a coach’s meeting minutes, an interviewer’s scorecard, a therapist’s session notes. Whatever they write down is what your agent should write down:
- A personal-branding coach notes the user’s background, goals, and desired brand.
- A meditation coach notes environment, stressors, cultural context.
- An interviewer notes performance per question, strengths, weaknesses.
- A memoir maker notes life chapters covered, names of key people, emotional threads.
- A dungeon master notes the character sheet, party decisions, unresolved plot lines.
Notice what this list is not: it is not “remember everything.” Experts note selectively, and so should agents. Chapter 12 covers why over-remembering has a real cost.
What memory unlocks: multi-session products
Memory doesn’t just polish single sessions. It makes an entire product category possible.
Take the AI memoir maker, the flagship example. Session one: childhood. Session two: career. Session three: relationships. Session four: turning points. Session five: lessons and legacy. Each session, the agent builds on what was shared. When family comes up in session three, it refers back to the grandmother mentioned in session one, and the user feels heard across weeks, not minutes.
Without memory, this product cannot exist at any level of model quality. With it, five twenty-minute conversations compound into a life story.
The same structural pattern powers multi-week coaching courses, language tutors that track your vocabulary, ADHD accountability buddies that learn your patterns, and elderly-care companions that notice changes and report them to families. If your product roadmap has the word “journey” anywhere in it, memory is the foundation it stands on.
On Tough Tongue: memory is a per-scenario toggle (
memory.is_memoryin the scenario configuration), and the platform’s Coach agent type is built around it: a persistent agent that remembers the same user across sessions, for ongoing training and accountability. The API reference covers the configuration surface.
Knowing what to remember is half the design. The other half is where it lives, and the answer is Chapter 10’s hybrid pattern, applied to memory. That is the two-tier architecture, next.