Your Retool Agent Has Short-Term Memory. It Does Not Remember Last Night's Run.

Think of your scheduled Retool agent as a very capable contractor who shows up, does the night's work, and leaves — and is required to forget the entire building on the way out.

That is not an insult to the contractor. Retool's own description of its agent architecture puts the agent layer in charge of "planning, reasoning, and short-term memory," running a think → act → observe loop until the goal is met or a stop condition fires. Short-term memory. That adjective is doing all the work in the sentence. The loop is alive while the run is alive. When the workflow ends, the loop's memory ends with it.

Retool does offer something it calls long-term memory: knowledge bases and vector search "attached as tools the agent can query." That is a real capability, and it is worth understanding precisely, because the phrasing reveals the limit. The agent does not carry the knowledge base. It queries it. The difference matters at 2 a.m., when your nightly reconciliation agent is deciding whether it has seen this discrepancy before. An agent with memory would know. An agent with a searchable KB has to decide to search, phrase the search, interpret the results, and reconcile them — every single run, from a standing start.

The full inventory: what survives the night

The run logs retain everything, and the agent can read none of it. Inputs, outputs, tool calls, model responses — all of it is surfaced for you in logs and chat or test views, which makes Retool agents unusually observable. But observability is not memory. No part of the next run's loop includes last night's transcript unless you pipe it in yourself.

Data persists; memory does not. Your workflow can write a row to Retool Database at the end of a run — "tonight I learned X" — and read it back at the start of the next one. Operators do this constantly, and it works, right up until the table becomes an unmaintained graveyard of contradictory notes. A database row is state. Memory is state plus selection plus hygiene: what to keep, what to retrieve, what to forget. Retool gives you the first and leaves the other two as homework.

The knowledge base holds reference material, not experience. Product docs, runbooks, curated resolutions — excellent candidates for KB storage, and genuinely useful across runs. But the KB does not contain Tuesday's run. It does not know that the agent tried three approaches to the vendor-payout mismatch before the fourth worked, or that it promised itself to check the staging ledger first next time. That is the agent's own history, and no knowledge base ingests it automatically.

So the honest answer to "does Retool remember between runs" is this: the platform remembers everything about the run; the agent remembers nothing of it. The loop restarts blank, every time, by design.

The DIY trap

The usual response is to build memory yourself: a read step at the top of the workflow, a write step at the bottom, a table in between. Say the quiet part out loud, though: you are now maintaining a memory system. Pruning rules, contradiction handling, retrieval ranking, access hygiene — the entire discipline of agent memory, hand-rolled, on top of a workflow platform, tested only by whatever went wrong in production last month. For one agent, that is a weekend project. For the fleet of scheduled agents an automation operator actually runs, it is a maintenance burden that never ends, and its failure mode is silent: the agent reads a stale note and acts on it with total confidence.

There is an alternative that keeps Retool doing what it is good at — orchestration, tools, observability — while memory lives somewhere built for it. Vilix AI is a cloud-hosted memory layer, which means zero infrastructure on your side: no database to provision, no vector index to babysit, no pruning cron to write. It connects over MCP, so one memory follows your agent across every tool it runs in, not just Retool. It keeps full conversation history rather than compressed factoids, so the agent can revisit the actual reasoning from the night it cracked the payout mismatch. Your data stays yours: export everything or delete it any time in a portable format. The free plan never expires, and the 7-day Pro trial does not ask for a credit card.

Plug that into the nightly workflow and the contractor finally gets a notebook. The run starts, and the agent already knows: the payout mismatch pattern, the staging-ledger-first rule, the approach that failed twice. Not because a workflow step reminded it, but because remembering is now the default instead of a feature you maintain.

Retool built a genuinely good agent runtime: observable, governable, honest about where the loop ends. The loop ending is the whole problem for scheduled work. Give the agent a memory that survives the night, and the schedule stops being a reset button.