Context engineering is deciding what goes into the model's context window at each model call of an agent loop (see Agent Architecture Patterns). Agent memory is what the agent keeps outside the window, for the rest of the run and for future sessions. Take the support agent for Ledgerly, a business-to-business (B2B) invoicing product: one refund investigation takes 40 tool calls, and the same account admin comes back next week with a new ticket.

The principle is that the window is small, costly, and less reliable as it fills, so each step gets a token budget. Old history is compacted, and large tool results move outside the window behind a short handle. The stable part of the prompt stays identical so the provider can cache it. Across sessions, memories are saved to a store under explicit rules, and only the ones relevant to the current task are read back in.

You need this when a run takes dozens of tool calls, when users return across sessions, or when per-step cost is dominated by re-sending the same long prompt. You do not need it for a short task that finishes in a few calls (send the full history), a stateless single-turn feature (pass the facts in the request), or knowledge that is the same for every user, which belongs in a retrieval index.

In agent design rounds this is one of the core prompts, usually asked as one thread: how does your agent decide what it sees at each step, and what does it remember across sessions? A mid-level answer names compaction and a memory store. A senior answer sets a numeric per-step budget, says what must survive compaction, lays out a prompt the cache can reuse, and states when memories are written, read, and deleted. The tutorial follows that question in two halves: the context inside one run, then the memory that outlives it.