Tines Agents Do Not Persist Between Runs. Records and Resources Carry the State.
Tines Agents Do Not Persist Between Runs. Records and Resources Carry the State. Tines has a documented opinion about agent memory, and the opinion is that your AI agent should not have any of its own. In the platform's own community guidance for building AI agents, "holding state in the agent" is listed as an anti-pattern, with the stated reason: agents do not persist between runs. For state, the guidance says, use Records or Resources. That is an unusually direct answer. What Tines genuine
Tines Agents Do Not Persist Between Runs. Records and Resources Carry the State.
Tines has a documented opinion about agent memory, and the opinion is that your AI agent should not have any of its own. In the platform's own community guidance for building AI agents, "holding state in the agent" is listed as an anti-pattern, with the stated reason: agents do not persist between runs. For state, the guidance says, use Records or Resources.
That is an unusually direct answer.
What Tines genuinely keeps
Start with what is real. A Story is a graph of Actions, and every time an Action executes, it records its own audit trail: who built the workflow, who edited it, what data went in, every manipulation, every output. Run the story a hundred times and you get a hundred fully instrumented runs you can inspect end to end, retained as long as you want. That is observability most automation platforms never reach.
Then there is deliberate cross-run state, and Tines gives you two purpose-built stores for it. Records are a lightweight key-value and structured-data store for tracking state inside a story or across story runs. Resources are a centralized data store, text, JSON, or files, shared across stories within a team. Think of Records as the fields your story reads and writes to remember where things stand, and Resources as the shared files every story on the team can reach.
This matters because the honest answer to "does Tines remember between runs" is yes, in a way that is designed, governed, and auditable. A scheduled story can look up last night's verdict, compare it to tonight's, and act on the difference. In the newer 3B runtime, every workflow step runs in an isolated environment that executes and then disappears, which makes cross-contamination between runs architecturally impossible rather than merely unlikely.
So the platform remembers. The question is whether the AI agent remembers, and those are different things.
The gap: the agent starts fresh, and key-value state is not memory
A Tines AI Agent can run in two modes. In Chat mode it holds a conversation with a human in real time, with the history of that conversation available to it. In Task mode, the mode your scheduled story uses, it takes an input, reasons with tools, and produces a structured output. When that task run ends, the agent's working state ends with it. The next run starts with a fresh agent, the current event payload, and whatever you explicitly fed it from Records and Resources.
You can absolutely write tonight's verdict into a Record. That is the designed pattern. But a Record is a key-value slot you defined in advance: "indicator 203.0.113.44: verdict=benign, confidence=0.62." It stores what you decided to store, in the shape you decided to store it. What it does not store is the agent's working memory: the five enrichment sources it weighed, why it discounted two of them, the edge cases it flagged for a human, the pattern it noticed across the last three alerts from the same subnet.
Picture the hourly phishing triage story. An AI Agent action reads each reported email, enriches the sender, and classifies it: malicious, benign, needs review. On Monday it sees an email from a lookalike domain, classifies it "needs review" with a note about the reply-to mismatch, and a human analyst confirms it malicious. That verdict goes into a Record, so Tuesday's run knows this sender is bad. What Tuesday's run does not know is what the agent learned on Monday: that lookalike-domain campaigns from this actor recycle the same reply-to trick, that the confidence threshold for auto-quarantine was almost met, that the analyst's note said "watch for the invoice lure variant." All of that was in the agent's context window, and all of it evaporated when the run ended. The Record remembers the conclusion. It does not remember the reasoning.
Key-value state is infrastructure. Agent memory is the working past: full conversations, reasoning traces, corrections, the texture that lets next run's judgment be better than last run's instead of merely informed by its output. Tines gives you the first deliberately and well. It gives you the second not at all.
What your scheduled work actually needs
The fix is not more Records. Records store exactly what you tell them to, and designing the schema for "everything the agent might need to remember" never ends. What the scheduled agent needs is a memory that keeps the run itself: what the agent saw, what it decided, what happened after, what the human changed, in full, retrievable by the next run before it acts.
Before the triage agent classifies tonight's alert, it should see last night's classification of the same indicator, the reasoning behind it, and what the analyst said about it. Before the escalation-drafting agent writes the note, it should know which of its last five drafts got rewritten and how.
That memory has to live outside Tines, because the work does not live inside Tines alone. The alert enrichment comes from the threat intel platform, the confirmation comes from the analyst in Slack, the escalation goes to the ticketing system. A memory that only one platform can see recreates the same problem one layer down: one store, every tool, through something standard like MCP.
It also needs to keep full conversation history, not just extracted facts. "Verdict: malicious, confidence 0.9" is a fact. The exchange where the agent walked through three enrichment sources, noticed the reply-to mismatch, and decided this matched a campaign from last week is the context that makes the next run smarter. Summaries and key-value pairs compress away exactly the texture scheduled agents need most.
The memory layer underneath the stack
This is what Vilix AI is built for: one shared memory your agents and automations all read from, no matter where they run. It is cloud-hosted, so there is nothing to install and no infrastructure to manage. The same memory follows your work across every tool over MCP. It stores full conversation history, not just extracted facts, so the reasoning survives alongside the verdict. It is free forever, with a 7-day Pro trial that needs no credit card, and your data stays portable: export everything or delete it anytime.
Tines is right that state should not live in the agent. Keep it in Records for the facts, in audit trails for the proof, and give the agent itself a real memory underneath all of it.
The short version
Tines remembers more than most platforms: full audit trails on every action run, Records for cross-run key-value state, Resources as a shared team data store. That covers the platform's own history. What it does not cover is the AI agent's working memory. By design, Tines AI agents do not persist between runs, and its own guidance calls holding state in the agent an anti-pattern. You can carry verdicts and counters across runs in Records, but the agent's reasoning, its observations, its corrections, and its conversations evaporate with each run. That is the gap a shared memory layer closes: not the state you engineered into slots, but the working past of the agent itself, remembered across every run and every tool.