Long-Term Memory for AI Agents: Teaching a ByteChef Coding Buddy to Remember You

TL;DR: Chat memory only covers the conversation you're in. Spring AI's AutoMemoryTools add a second layer: the agent deliberately writes down facts worth keeping and reads them back in later chats. ByteChef ships the same six memory tools as the Auto Memory Tool, stores memories in its database, and keeps a separate memory per project deployment and environment. Want to see it? Deploy the Remember coding preferences across chats template, tell it your build tool once, then open a new chat.

This is Part 6 of the AI Agentic Patterns in ByteChef series.

The problem: agents with amnesia

You tell your assistant you use Gradle. Next conversation, it hands you a Maven pom.xml. You mention you're on Java 25. A week later it suggests a workaround for Java 17.

The reason is simple: chat memory is a sliding window. It keeps the recent turns of one conversation and drops the oldest when it fills up. Great for the task at hand, useless for something you want the agent to know next month.

For that you need a second layer: a place where the agent writes facts down on purpose and reads them back in future conversations. Let's build one in ByteChef with a single template.

The template: a coding buddy that remembers

Remember coding preferences across chats has three steps:

1. New Chat Request – a message arrives in the workflow chat.
2. AI Agent – an Anthropic model with two kinds of memory: Chat Memory for the current conversation and the Auto Memory Tool (in the Tools slot) for long-term memory.
3. Reply – the answer goes back to the chat.

The system prompt tells the agent how to use its memory:

You are a coding buddy for a Java developer. At the start of every conversation, read your memory index and any relevant memory files. When the user states a lasting preference (build tool, Java version, testing style, answer length), save it as a memory right away and say that you saved it. Apply remembered preferences without being asked. 

The Auto Memory Tool itself needs no configuration. The one thing that matters is in the green note on the canvas: long-term memory only works in a deployed run (more on that below).

Two kinds of memory

The Spring AI team sums it up well: use ChatMemory for the current task, and AutoMemoryTools for facts that should still be there next week.

The template uses both: Chat Memory lets you say "now add a test" without repeating context, and the Auto Memory Tool lets a brand-new conversation start from what the agent already knows about you.

How the agent remembers

Long-term memory is a small set of entries plus an index:

• Entries – short Markdown files with frontmatter (title, optional description, type) followed by the fact.
• The index – MEMORY.md lists every entry on one line, newest first. The agent reads it at the start of a conversation and opens only what it needs. ByteChef keeps it in sync automatically, so the agent never edits it by hand.
• Four types that guide what's worth saving:
  • USER – facts about the user: role, preferences
  • FEEDBACK – corrections, or approaches the user confirmed
  • PROJECT – decisions and constraints of the ongoing work
  • REFERENCE – pointers to external systems

Tell the buddy "I always use Gradle with the Kotlin DSL and Java 25" and it might save something like this (illustrative):

--- title: Build setup description: Gradle with the Kotlin DSL, Java 25 type: USER --- Always use Gradle with the Kotlin DSL and target Java 25. 

The agent manages memory through six tools, with names and behavior straight from Spring AI:

Entry names are flat (e.g. build_setup.md) – no folders.

Where ByteChef differs: database storage, scoped per deployment

In Spring AI, memory is a folder of Markdown files on disk. Perfect for one agent on one machine, but a platform has harder questions: Whose memory is this? Does it survive moving to another server? Can someone inspect it and fix a wrong fact?

Spring AI keeps storage behind two small interfaces, and ByteChef plugs its own implementation in there. The agent still sees the same six tools and the same format, but entries go through ByteChef's memory service – the database by default. Self-hosted installs can set bytechef.ai.auto-memory.provider to use file storage instead.

Whose memory is it?

ByteChef works out the owner from the run itself – nothing to configure:

• Automation projects: memory belongs to the project deployment + environment. All workflows and runs in that deployment share it; another deployment (or the same one in another environment) has its own.
• Embedded integrations: memory belongs to the integration instance, so each of your customers gets a separate memory.

When memory is unavailable

If a run has no owner, the tool still loads, but every call returns a short "memory is unavailable" message with the reason, so the agent can tell the user instead of failing. That happens for:

• Editor test runs – a test run isn't a deployment. Bonus: experiments in the editor never pollute a real deployment's memory.
• Microservices installs – memory requires the ByteChef server application.
• Runs without a workflow context – e.g. when the agent is invoked from somewhere that doesn't identify the running workflow.

Hence the canvas note: deploy first.

Try it yourself

1. Import the template – open Remember coding preferences across chats and add it to a project.
2. Connect the model – add your Anthropic connection.
3. Deploy – deploy the project and enable the workflow in the deployment.
4. State a preference – in the deployed workflow's chat, say something lasting, like "I always use Gradle with the Kotlin DSL and Java 25." The agent saves it and tells you so.
5. Check it in a new conversation – start a fresh chat and ask for a build file.

Here's step 5 in a real deployed chat. The request mentions neither Gradle nor Java, yet the agent checks its memory first and produces a Gradle Kotlin DSL build with a Java 25 toolchain:

Try step 4 in an editor test run instead and the agent will tell you memory is unavailable – that's expected.

See and fix what it remembers

Stored memories live under Settings → AI → Memories. You can search by title or description, filter by type or owner (deployment or integration instance), and open, edit, or delete any entry. When a preference changes, fix it there – or just tell the agent and let it update the entry itself.

What you get from Spring AI vs. what ByteChef adds

ByteChef keeps the Spring AI design – the curated memory layer, six purpose-named tools, index plus typed entries, and the short-term/long-term split – and changes what's underneath:

• Storage: files on disk become database entries that survive restarts and server moves.
• Ownership: memory is scoped to a project deployment + environment, or to an integration instance.
• Visibility: review, edit, and delete memories in Settings → AI → Memories.
• Wiring: no advisors or directories to set up in code – just drop the Auto Memory Tool into an AI Agent's Tools slot.
• Safe testing: editor test runs have no memory owner, so testing never writes into real memory.

Memory also pairs nicely with the other patterns in this series: Agent Skills give an agent know-how that's the same for everyone; long-term memory gives it what it has learned about your users and project.

Wrapping up

Chat memory answers "what did we just talk about?" Long-term memory answers "what do I already know about you?" Spring AI packaged the second as six tools and a simple file format. ByteChef keeps both and adds a database and per-deployment ownership, so memory lasts, stays separate per deployment or customer, and is there for you to inspect.

The fastest way to get it is to run it: import Remember coding preferences across chats, deploy, tell it your build tool once, and open a new chat.

Originally published on the ByteChef blog. If you found this useful, give ByteChef a ⭐ on GitHub!