Your Relevance AI Agent Has a Memory Feature. Your Scheduled Runs Still Start Blind.

You set a Relevance AI agent on a recurring schedule. Every morning at 7 it wakes up, pulls the new leads, scores them, and fires off the follow-ups. It works beautifully for a week. Then one morning it re-scores a lead it already contacted on Tuesday, sends a second follow-up to a prospect who said no, and completely misses the one who said "call me next week" because nobody told the agent that last week ended.

The agent did not malfunction. It did not hallucinate. It just started blank, the same way it starts every scheduled run.

Yes, Relevance AI has Agent Memory, and it is opt-in

This is the part most summaries get wrong, so let us get it exactly right. According to Relevance AI's own documentation, Agent Memory is a feature you switch on per agent: a memory field in the agent configuration with an enabled flag and a scope, either project-wide or per user. When it is on, the agent receives two special "phantom tools", one to save a memory and one to delete it. Whatever the agent stores is persisted and injected into its system prompt at the start of each conversation. The documented purpose is remembering user preferences and facts across conversations.

The Invent assistant works the same way: with Memory enabled, it can save and recall details you want carried across conversations, things like naming conventions, preferred models, workflows, and recurring constraints.

So the honest answer to "does Relevance AI remember?" is: yes, for conversations. If you chat with the agent on Monday and tell it your team writes follow-ups in a casual tone, Tuesday's chat starts already knowing that. That is real, documented, cross-conversation memory.

The gap: a scheduled run is not a conversation

Read the mechanism again, slowly: memories are injected "at the start of each conversation."

A recurring schedule firing at 7am is not a conversation. Relevance AI's own docs describe what happens when a trigger fires: the trigger sends a message to the agent, the agent processes it based on its prompt and executes its tools. Then the run ends. Nobody is chatting. There is no conversation for the memory system to inject into, because Agent Memory was designed around chat continuity, facts about the user, things the user said.

What a scheduled operator needs is a different category of memory entirely: run state. What did last night's run finish? What failed halfway through? Which records were already processed, so the dedupe list keeps growing instead of resetting? "The user prefers casual tone" is a memory. "Lead #4821 was already contacted on Tuesday, do not email again" is run state. The first one is what the phantom tools were built for. The second one is what your 7am run actually needs.

What actually persists between runs on Relevance AI

An honest inventory, no more and no less:

• The trigger configuration persists. The schedule itself survives, obviously.
• Datasets and tables persist. If your agent writes its results to a table at the end of a run, that data is there tomorrow. This is the honest DIY state store, and it works, with caveats below.
• Conversation history persists in the dashboard. You can read yesterday's chat. But a scheduled run does not get yesterday's chat injected into its context. History you can read is not memory the agent has.
• Agent Memory persists across conversations, for chat agents, scoped to a project or a user.

Notice the hole in the middle: nothing on this list automatically hands a scheduled run what the previous scheduled run did. The platform gives you the pieces to build it. It does not build it for you.

The options, honestly compared

1. Write run state to a dataset or table, read it at the start of every run. This is the default answer, and it works. The tax is real: you design the schema, you manage retention, you build the "read yesterday's row" step into every agent yourself, and the agent only knows what you told it to write down. It cannot retroactively recall something it never stored. Fine for structured state, clumsy for judgment calls.

2. The knowledge base. Static by design. Wrong tool for run state. Good for SOPs the agent should follow, bad for "what failed at 3am."

3. Keep one long conversation going and run everything inside it. Brittle. Breaks on timeouts, redeploys, and long threads, and scheduled triggers are not built for it. This is the duct tape option, and you will feel it the first time a thread dies mid-quarter.

4. Give the agent a shared memory layer it reads at run start and writes at run end. Relevance AI agents execute tools and can call external APIs, so a hosted memory store reachable over HTTP fits inside the existing architecture without rebuilding anything: the run starts, the agent pulls "current state plus what I learned," the run ends, the agent writes back what happened. Because the memory lives outside any single run, it also survives across tools, so the Relevance AI agent, the n8n workflow next to it, and the coding agent on your laptop can all read and write the same state.

This is what Vilix AI is built for: a cloud-hosted memory layer with zero infrastructure to manage, the same memory reachable from every tool over MCP. It stores full conversation history, not just extracted facts, so you can revisit what the agent actually did on any given run. It is free forever, with a 7-day Pro trial that needs no credit card, and you can export everything or delete it anytime in a portable format.

What belongs in scheduled-run memory

If you build the ledger, be deliberate about what goes in it. The highest-value items:

• The completion ledger: what finished, what failed, what is still pending. This is the single entry that stops duplicate outreach and repeated work.
• Dedupe keys: IDs already processed, so "new since last run" is a lookup, not a guess.
• Decisions plus reasons: "we excluded these leads because the enrichment API was returning stale data." The reason matters more than the decision. Two weeks later the agent sees the decision without the constraint and repeats the mistake.
• Freshness timestamps: when each fact was last verified. Stale memory presented as fresh is worse than no memory.
• Not this: raw transcripts of every run (retrieval cost and noise), secrets and API keys (never in memory, ever), personal data you do not need.

The ten-minute test

You do not need to take any of this on faith. Schedule a run that writes one fact down, let the next scheduled run fire, and ask the agent to recall the fact. If it can, you have run-state memory. If it cannot, you now know exactly which category is missing, and you know it is not the Agent Memory toggle, because that toggle was never designed for this job.

Relevance AI remembered your chat preferences just fine. Your scheduled runs were never part of that conversation.