Academy AI Systems Engineering · Lesson 10 of 14

Planning and memory

Plans and memory are data your application owns.

Module
3 · Agentic systems
Slide
11 of 15
Reading
About 2 minutes
Published
Slide 11: Planning and memory
Slide 11 of 15 Module 3 · Planning and memory

Two things on the slide are drawn in sienna: the planner’s step list going to the executor, and the write policy in front of the long-term store. Both are gates a person or a rule can hold.

Plan, then execute

Plan-and-Solve prompting (Wang et al., 2023) has the model write a plan and then carry it out inside one prompt. On 100 sampled GSM8K problems with GPT-3, missing-step errors fell from 12 with zero-shot chain-of-thought to 10 with Plan-and-Solve and 7 with its PS+ variant. A small sample on maths problems, so run the comparison on your own tasks before you rely on it.

Plan-and-execute splits the roles. A strong model writes the plan, and a cheaper model or a tool loop runs each step. You get fewer expensive calls, a plan a person can read and approve before anything runs, and natural checkpoints. Trigger the replanner explicitly, on a failed step or a result that contradicts the plan, not on every turn.

Memory

Short-term memory is the context window. It is resent and billed on every call, and part 6’s compactor manages it.

Long-term memory lives outside the model. CoALA (Sumers et al., 2023) splits it into episodic memory of past runs, semantic memory of facts, and procedural memory, which in practice is model weights and agent code such as prompts. Episodic and semantic memory sit in external stores, and reading them back is retrieval over your own writes, which part 12 covers.

Rules for writes

  • Every write carries provenance: where the fact came from, when, and from which run.
  • Every write carries a time to live, so a stale fact expires instead of persisting.
  • Every write carries the tenant key, so one customer’s memory never reaches another.
  • Deletion requests must reach these stores. A memory store holds personal data.

Where it goes wrong

Memory poisoning. One wrong or injected fact is saved, then retrieved into every later session. Provenance lets you trace it, and a TTL limits how long it lives.

What to do

  • Steps knowable when the request arrives? Plan first, and show the plan.
  • Each step depends on the last result? Use ReAct inside limits.
  • Treat memory as a database with a write policy, not as a scratchpad.
The rule

Steps knowable when the request arrives? Plan first. Each step depends on the last result? Use ReAct.