Build
Conversation memory
Rails Agent remembers useful facts across turns when you pass a stable session_id. Managed memory is on by default for new agents and is backed by Mem0 on the cloud runtime.
Memory DSL
Declare memory on the agent class. Scaffolds include conversation memory so Knowledge chatbots retain context without extra setup.
class StoreAssistant < RailsAgents::KnowledgeAgent
model :gpt_5_mini, provider: :openai, credential: :company_openai
memory :conversation, provider: :mem0, recall: 5
tool :lookup_order do |order_number:|
Order.find_by!(number: order_number).as_json
end
end| Option | Meaning |
|---|---|
| :conversation | Long-lived chat memory for the agent |
| provider: :mem0 | Managed Mem0 backend on Rails Agent Cloud |
| recall: N | How many relevant memories to inject (e.g. 5) |
Default on
Cloud agents ship with managed memory enabled by default (memory_enabled). Toggle or tune top-k recall from the agent Build → Memory tab without removing the Ruby DSL. Disable there when an agent should be strictly turn-stateless.
Session identity
Pass a stable product-user (or conversation) id on every run. Rails Agent scopes memory by workspace, agent, and a hashed session identity — so users do not leak context across each other.
result = StoreAssistant.run( "What did I ask about shipping?", session_id: current_user.id.to_s ) puts result.output_text
$ bundle exec rails-agents run store_assistant \
"Follow up on that order" --session user-42Mem0-backed storage
Production recall uses Mem0 on the platform side. Your Rails app does not host the vector store or store provider Mem0 keys — the cloud runtime attaches memory for enabled agents during runs. Prefer stating durable preferences and goals in conversation; ephemeral tool noise is not what memory is for.
Memory vs knowledge
Knowledge is curated grounding (docs, DB sources under knowledge/). Memory is per-session recall learned from prior turns. Use both: policy docs in knowledge, “this customer prefers email” in memory.