Your Agent Knows the Rules but Forgot the Story: A Memory Field Guide for Automation Operators

Picture a scheduled agent that does something wrong, and when you investigate, the explanation is infuriating: every rule it followed was correct. The refund policy was right. The routing table was right. The decision was still wrong, because the one thing the agent did not know was what had already happened. It knew the rules. It had no story.

That split, between knowing rules and remembering events, is the most useful mental model in agent memory design. It comes from cognitive science, where Tulving's 1972 framework divided memory into semantic memory (general facts, true regardless of when you learned them) and episodic memory (specific events, anchored to a time and place). The CoALA paper on language-agent architectures (2023) carried the same taxonomy into AI agents, and added procedural memory: learned routines and skills.

Here is what each one looks like inside a scheduled automation.

The handbook: semantic memory

Semantic memory holds the timeless stuff. "Refunds over $500 route to the billing team." "The warehouse API allows 2 calls per second." "This client wants summaries that lead with metrics." None of these carry a timestamp, because none of them need one. They are true until they change.

This is the memory most DIY setups build first, usually as facts in a vector database or rows in a table. It feels productive: the agent stops asking questions it should already know the answer to. And it is productive, right up until the agent needs to know something that only exists as an event.

The diary: episodic memory

Episodic memory holds what actually happened. "On Monday's 9 AM run, the supplier API returned 429s and the retry at 9:40 succeeded." "Thursday's triage run escalated the Acme ticket; the customer confirmed resolution on Friday." These records are useless without their timestamps and context, and they are irreplaceable with them.

This is the memory most setups skip, because storing full transcripts feels wasteful. So the agent gets summaries instead, or nothing at all, and then it cannot answer the questions that matter most in production: what did the last run do, did we already try this, what changed since Tuesday.

The muscle memory: procedural memory

The third type gets the least attention and quietly delivers the most leverage. Procedural memory is the learned routine: "when the morning sweep finds zero new leads, skip the report and post a one-line all-clear," or "drafts for the support channel always open with the ticket number." It is what makes an agent get faster at the workflows it repeats, instead of re-deriving the same approach every run. Most agents fake this by stuffing examples into the system prompt. A real procedural layer learns the pattern from repeated episodes and retrieves it when a similar situation comes up.

Two failure modes, one root cause

When an automation keeps failing in ways that feel dumb, the diagnosis is usually a missing memory type.

An agent with facts but no episodes is a bureaucrat with no past. It applies the rulebook flawlessly to situations the rulebook was never meant for. It re-sends the follow-up because the policy says to follow up, with no record that the follow-up already went out. It cannot resume a failed run, cannot notice its own drift between runs, and cannot tell a fresh problem from a repeat.

An agent with episodes but no facts is a witness with no judgment. It can recount every failure in detail and still walks into the same one tomorrow, because nobody ever converted the incidents into rules. Every correction you make lives in a transcript the agent must re-read and re-interpret on every run, instead of living in the handbook where it belongs.

The bridge between the two is consolidation: periodically turning repeated episodes into durable facts. The Generative Agents research (Park et al., 2023) demonstrated this as reflection, synthesizing recent experience into higher-level insights. The operational takeaway is simple and often ignored: you cannot consolidate what you deleted. A memory layer that stores only summaries has thrown away the raw material that future learning needs.

Running the split in production

For operators running scheduled agents in n8n, Make, Zapier, or plain cron scripts, the split turns into four working rules:

Keep the full transcript. Full conversation history is the episodic substrate. Summaries make a fine index, but discarding the raw record caps everything the agent can ever learn from it, and removes your ability to audit a strange decision later.

Promote repeated corrections into rules. When the same correction shows up in two or three episodes, it has graduated. It belongs in semantic memory, where every future run absorbs it without re-reading the incident.

Let recency break ties. Episodic retrieval should favor recent events; semantic retrieval should favor established facts. When they disagree, the newer episode usually wins. Last-write-wins is not just a conflict policy, it is how memory stays fresh instead of letting a six-month-old fact overrule yesterday's reality.

Scope both. Episodic and semantic memory both need boundaries: per client, per workflow, per environment. A fact learned from one customer's data must never surface in another customer's run, and a staging incident should not rewrite the production handbook.

The no-infrastructure option

Doing all of this by hand means a transcript store, a fact-extraction pipeline, a consolidation job, recency-weighted retrieval, and scoping rules, all hosted and maintained by you. It is a legitimate engineering project, and for most automation operators it is not the project they signed up for.

Vilix AI exists so you do not have to build it. It is a cloud-hosted memory layer: no database to run, nothing to maintain. One shared memory follows your agents across every tool over MCP, the n8n workflow, the cron script, the coding assistant, the phone app, all reading and writing the same store. It keeps full conversation history alongside extracted facts and preferences, so both the diary and the handbook survive between runs. Retrieval stays current with last-write-wins semantics, and memory is scoped per user so one client's history never leaks into another's.

The commercial terms are deliberately boring: a free plan that stays free, a 7-day Pro trial with no credit card required, and full portability. Export everything or delete it anytime. Your agents' memory should belong to you, not to the infrastructure you rented to hold it.

Most agent amnesia is not a prompt problem. It is a missing memory type. Give the agent both the rules and the story, and the 7 AM run stops starting from zero.