How AI Agents Should Handle Memory and Scheduling

A conversation with an AI assistant is, by default, ephemeral — when it ends, so does everything the model was holding in context. That's fine for a question with an immediate answer. It breaks down the moment the right response to something is "act on this later," because "later" doesn't exist inside a chat session that's already over.

The gap between "remember" and "act later"

Ask an assistant to "remember I need to renew my passport in a month" and, without a tool to back that up, what actually happens is: it acknowledges the request, and then forgets it the moment the session ends. There's no mechanism for the model to reach forward in time and do anything a month from now — chat has no concept of "later" as a first-class thing that can happen without you.

Turning "remember this" into something that actually happens later requires a system outside the conversation entirely — durable storage, a scheduler, and a delivery mechanism (email, a notification, another agent run) that doesn't depend on the original chat session still existing.

Why this is a tooling problem, not a model problem

It's tempting to think a "better" model would just handle this natively. It won't, structurally — a language model call is a stateless function: text in, text out. Anything that needs to persist past that single call, or trigger independently of a user being present to prompt it, needs infrastructure the model calls into, not a capability the model develops on its own. This is exactly the class of problem MCP exists to solve: giving a model a well-defined tool (create_reminder, schedule_task) that hands off the actual state management to a system built for it.

What a good scheduling primitive for agents looks like

• Durable by default — survives the session, the app closing, the model changing entirely
• Independently triggered — fires on a schedule, not only when the user happens to open the app again
• Actionable from the notification itself — completing or rescheduling shouldn't require re-opening the original context
• Callable from more than one surface — the same reminder should be reachable whether it was set from a chat, a script, or a dashboard

This is already how the best agent workflows are built

The pattern shows up anywhere an agent needs to do more than answer in the moment: a coding agent that needs to check back on a long-running CI run, an automation that needs to follow up if something doesn't happen within a window, a personal assistant that needs to nudge you about something days out. In each case, the agent doesn't hold the state itself — it hands off to a scheduling tool and gets called back into later.

Reminders as a primitive, not just a feature

A reminders MCP server is a small, concrete example of exactly this pattern: an agent gets a create_reminder tool, hands off a task and a time, and something outside the conversation takes over — storage, scheduling, delivery, and the ability to mark it done later from a completely different context than where it was created. It's a narrow tool, but it's the same shape every "act on my behalf, later" capability needs.