smolagents Remembers Every Step. Your Scheduled Scripts Still Wake Up Blank.

Set up a smolagents CodeAgent on a nightly schedule and the first run feels like magic. It plans, writes code, calls tools, reads the results, fixes its own errors, and files a clean summary. Then the second night comes. You ask it what changed since last night's scan, and it answers with total confidence based on absolutely nothing. Last night never happened.

This is the most common surprise for people who put smolagents on a schedule. Inside a single run, its memory is excellent. Between runs, it starts from zero. Both of those statements are true, and understanding why saves you from designing around the wrong one.

What smolagents memory actually is

Every smolagents agent carries an AgentMemory: the system prompt plus a chronological list of steps. A TaskStep records the task it was given; each ActionStep records what the agent thought, the code it ran, the tool output it saw, and any error it hit. The official docs describe this as "a memory of past steps, drawing a history of planning, execution, and errors."

It is genuinely good memory for what it covers. You can replay a run with agent.replay() and watch every decision unfold. You can read agent.memory.steps directly, or dump the whole history as dictionaries with agent.memory.get_full_steps(). For observability inside one run, this is the real thing: full conversation history, not just a summary of what happened.

The reset switch that controls everything

Here is the detail that decides your architecture: agent.run() resets the agent's memory by default. Call it twice in a row and the second call starts blank.

The escape hatch is a single parameter. Call agent.run("follow up", reset=False) and the memory is not flushed, so the conversation continues from the earlier steps. This is exactly how the Gradio chat UI works under the hood: each new user message launches the agent with reset=False, and the Gradio UI even exposes a reset_agent_memory flag for people who want the opposite. So yes, smolagents remembers. As long as you never leave the process.

Where scheduled runs break it

Cron jobs, GitHub Actions workflows, serverless functions, Docker containers that exit when the script finishes: every one of these is a fresh process. A fresh process means a fresh agent object, and a fresh agent object means blank memory. The reset=False trick only works inside one long-lived Python process, because the memory lives in the agent instance, not anywhere durable.

The docs-adjacent guides are explicit about this: memory and state are instance-level, and run() resets memory by default. If you need continuity, you persist memory.steps yourself. Even the code sandbox has the same boundary: the local Python executor keeps its state across steps and runs within an instance, but "within an instance" is the whole trap. Nothing in smolagents writes agent memory to disk on its own.

So your nightly script faces a hard boundary. Everything the agent learned on Monday exists only in Monday's process. Tuesday's run cannot see it unless you built the bridge yourself.

What scheduled operators actually do about it

There are three honest options, and they cost very different amounts of your time.

First, keep the agent process alive around the clock so reset=False can keep working. This converts a script into a service you now babysit: restarts, deploys, and memory growth all become your problem.

Second, serialize the memory yourself. get_full_steps() gives you plain dictionaries, so you can write them to disk or a database at the end of each run and reload them at the start of the next one. This works, and plenty of teams do it. It is also a second project hiding inside your first one: you now own the storage format, versioning when smolagents updates its step classes, pruning so the history does not eat your whole context window, and merging when two runs overlap.

Third, stop making each run carry its own memory and give every run one shared memory it can reach over the network. The agent saves and recalls full conversation history from a single place, and it does not matter whether the run happens in a cron job, on a teammate's laptop, or inside a completely different tool. The memory follows the work instead of the process.

That third option is what Vilix AI is built for. It is cloud-hosted, so there is no infrastructure to babysit. The same memory is available to every MCP-connected tool, so your scheduled Python script, your n8n workflow, and your coding assistant can all read and write the same context. It stores full conversations, not just extracted facts, so nothing gets lost in summarization. The plan is free forever, the Pro trial runs seven days with no credit card, and you can export or delete everything whenever you want.

The verdict

Does smolagents remember between runs? Inside one process, with reset=False, yes. Across separate scheduled runs, no, not unless you built the persistence yourself.

The better question to ask of any agent framework is not "does it have memory" but "does the memory survive the process boundary." For smolagents the answer is crisp: the memory is excellent and instance-level. Decide which side of that boundary you want to live on before your third nightly run, because by then the re-briefing tax is already compounding.