Remember, Recall, Checkpoint: Agent Memory Tools Explained
Agent memory tools are ordinary tools with an unusual target: instead of acting on your CRM or your repo, they act on the agent's own knowledge. Five verbs cover the whole discipline: remember, recall, checkpoint, set_goal, and get_pending. Learn what each one is for and when it fires, and the vague idea of "an agent with memory" turns into a concrete, inspectable workflow.
These are real tools on Tulimoa's gateway (free on every plan, to say it plainly once), but the vocabulary is worth learning regardless of vendor, because it names the moments where agents lose things.
The running example
One scenario carries the whole post. Your agent is helping you launch a pricing change: update the billing plans, adjust the website copy, email the affected customers. The work spans three days and two different clients (desktop app and IDE). Here is where each tool earns its place.
remember: store a fact at the moment it becomes true
What it does: writes one durable fact to the memory store, ideally with its reason attached.
Day one. You and the agent settle the core decision: the new Pro price is 29, existing customers keep 19 until January, and the FAQ must not mention the old price to new visitors. Three remember calls, ten seconds:
- remember("New Pro price 29 from Sept 1, decision 2026-07-29")
- remember("Existing customers grandfathered at 19 until January, per founder decision")
- remember("FAQ must not show old price to new visitors")
The discipline: remember fires when something becomes true, not at the end of the day. Facts stored in the moment carry their context; facts reconstructed later carry guesses. And store the why: "grandfathered until January" without the reason invites the agent to relitigate it in October.
recall: pull back what matters, when it matters
What it does: queries the store by topic and returns the relevant facts, compact.
Day two, different client. You open the IDE and say "update the pricing page." The agent's first move: recall("pricing change"). Back come the three facts from yesterday, a few hundred tokens, and the agent edits the page correctly without re-reading yesterday's chat, which it could not do anyway, because that chat lives in another app's history.
That is the quiet superpower of memory at the connection layer: the store follows the protocol, not the app. Stored in the desktop client, recalled in the IDE. The architecture behind that portability is covered in [MCP memory](/blog/mcp-memory).
The discipline: recall at session start, always, and again before any decision that smells like it was discussed before. A recall costs little; acting on a forgotten constraint costs a redo.
checkpoint: save the state of the work itself
What it does: stores a snapshot of the plan and its progress, so the thread survives session ends and context compaction.
Day two, evening. The billing plans are updated, the website is half done, the emails are not started. The session has to end, so: checkpoint("Pricing launch: billing done, website copy 50 percent (pricing page done, FAQ open), customer email not started. Blocker: legal wording for grandfathering note.").
Day three starts from that sentence instead of from an investigation. The difference between remember and checkpoint is the difference between facts and state: remember holds what is true, checkpoint holds where you are. Long tasks die without the second kind, and they die quietly, mid-compaction, when the oldest context gets squeezed out first. If you have watched an agent forget its own plan halfway through, this is the tool that fixes that specific heartbreak.
set_goal and get_pending: the frame around multi-step work
What they do: set_goal declares the mission once ("launch the pricing change: billing, website, emails"); get_pending replays open loops after an interruption or a reconnect.
These two matter most when things go wrong. The session crashes, the context gets compacted, the agent reconnects: get_pending answers "what was I doing?" with the declared goal and the outstanding items, instead of the agent cheerfully asking you what you would like to do today. On day three, after a restart, get_pending returns the checkpoint state and the goal, and the agent resumes the customer email without being re-briefed.
The habits that make the tools work
- Open with recall, close with checkpoint. Make it the session's first and last move until it is automatic.
- remember decisions with reasons, IDs always. Doc IDs, plan names, customer segments: cheap to store, annoying to re-find.
- Do not store secrets. Keys and passwords belong in a credential vault, never in memory.
- Prune occasionally. Memory is a curated store, not a landfill. Stale facts recall stale answers.
If you want the architectural comparison (client memory vs framework stores vs gateway tools) before adopting the vocabulary, that survey is in [how to give an AI agent persistent memory](/blog/give-your-ai-agent-persistent-memory). And if you are evaluating where these tools should live in your stack, [the gateway](/gateway) is our answer, early beta and all.
Frequently asked questions
What is the difference between remember and checkpoint?
remember stores durable facts (decisions, IDs, preferences) that stay true across tasks. checkpoint stores the state of the current task: what is done, what is open, what blocks. Facts versus progress. You need both, at different moments.
Do agents call these memory tools on their own?
Good agents do, once instructed: a system prompt or gateway instruction telling the agent to recall at start and checkpoint at end is usually enough. The tools also work when you say it explicitly ("remember this decision"), which is a habit worth keeping for anything important.
Are memory tool calls expensive?
They are small calls with compact payloads, cheap next to what they replace: re-reading, re-fetching, and re-deriving context. On Tulimoa's gateway they cost no credits at all; whatever you use, check that metering does not punish the exact behavior you want the agent to have.