Does a Claude iMessage Agent Remember Earlier Texts?

Because an inbound text and a Claude session are not the same thing, and nothing connects them unless your code makes that connection on purpose. A contact who texted your business last Tuesday and texts again today produces two separate webhook events. If the handler for each event calls the Agent SDK or the API fresh, with no resume and no prior context in the prompt, Claude starts from zero both times, same as it would for two different people. The model has no built-in sense that "this phone number" means anything across those two calls.

The Agent SDK does have a real session mechanic, and it is worth understanding exactly what it does and does not give you. A session is the conversation history the SDK accumulates while an agent works, written to disk automatically so you can return to it later by its session_id (code.claude.com). Resuming that session sends the full saved transcript back to the API, so the agent has everything it had before, at the cost of resending and re-billing that whole transcript on every turn. Resuming is genuinely useful if you deliberately map one session_id to one phone number and store that mapping yourself, since the SDK has no idea a session belongs to a given contact unless your code tracks it. But a thread that runs for months grows into a transcript that is slow and expensive to resend in full just to answer one new text, which is a real limit worth planning around rather than discovering later.

Beam's own API gives a texting agent a second, often better option for building that context: GET /v1/conversations/{phone}, which returns the full message history for one contact, oldest message first, with each message's direction, channel, body and timestamp. An existing claudeimessage.com guide already covers calling this through a conversation_read MCP tool so Claude can read and reason over a thread inside one active session; see our guide on whether Claude can analyze a text thread. What that guide does not cover, and what this one does, is the part between sessions: pulling that history back out, or distilling it, so the next session does not start blank.

1. Add one table or document store keyed by the contact's phone number, with at minimum a summary text field and a last_updated timestamp. Nothing fancier is required to start.
2. Before the agent's system prompt is built for an inbound text, look up that phone number in the store. If a row exists, inject its summary as a short block of context, labeled clearly as prior history rather than the current message.
3. Let the agent answer the current text normally, using that injected summary the same way it would use any other fact in its context window.
4. After the exchange finishes, make one small, separate Claude call whose only job is to update the summary: take the old summary plus the new exchange, and return a short, revised summary, not a running transcript.
5. Write that revised summary back to the same row, overwriting the old one rather than appending to it, so the stored text stays small no matter how many times the contact has texted before.
6. Cap what the summary holds to the handful of facts a human teammate would want on screen before replying: who they are, what they are trying to do, what is still open, and anything they explicitly asked not to be asked again.
7. Decide a retention rule up front, such as dropping or anonymizing a summary after a stated period of no contact, and write that rule down where a teammate can find it later.
8. If the agent's send tool already follows our guide to giving a Claude Agent SDK agent a send-text tool, add the memory lookup and write as two extra steps around that existing tool call, not a new pipeline.

That sequence deliberately avoids the Agent SDK's resume option for the long-term memory layer. Resume is still worth using inside a single exchange, if an agent needs several tool calls to answer one text; it is just the wrong tool for remembering a contact across a gap of days or weeks, for the cost reason covered above.

1. Text a number you control, have the agent reply, and confirm a summary row gets written for that number afterward, not just a successful send.
2. Wait, then text the same number again from a fresh process restart, with no session resumed, and confirm the agent's reply shows it knows something from the first exchange, such as referencing what was discussed rather than asking from scratch.
3. Check the actual stored summary text after that second exchange, not just the agent's reply, and confirm it grew by a sentence or two rather than by the full new transcript.
4. Text from a second number you control and confirm the agent's reply to that number carries no trace of the first number's history. Cross-contact leakage here is the single most damaging bug this kind of store can have.
5. Manually edit or clear one contact's stored summary, then text from that number again, and confirm the agent now answers as if meeting that contact for the first time, proving the lookup is actually driving the behavior rather than something cached elsewhere.
6. Let one test thread run past your planned retention window, then confirm the summary is dropped or anonymized on schedule rather than sitting indefinitely.

Diagram: a horizontal flow showing an inbound text arriving on the left, an arrow down into a small box labeled "look up phone number in memory store," another arrow into "build system prompt with injected summary," then into "Claude replies," then an arrow out to "update and overwrite summary," looping back to the memory store box, with a separate dashed box off to the side labeled "claude.ai Chat Memory" connected to nothing on the diagram at all.

Run that sequence against a live number before anything here touches a real contact list, the same way you would test a new send tool. A memory bug that leaks one contact's details into another contact's conversation is worse than no memory at all.