Agent Memory

Memory is what separates a stateless chatbot from a useful agent. Horizon’s memory system lets agents retain context across conversation turns and even across separate conversations, building up knowledge about your business over time.

Memory layers

Horizon agents have three distinct memory layers, each serving a different purpose.

Working Memory

Working memory is the agent’s short-term scratchpad. It holds information relevant to the current task within the active conversation.

• Scope: current conversation turn and the immediately preceding turns.
• Lifetime: cleared when the conversation ends (unless promoted to episodic memory).
• Use case: holding intermediate results, tracking multi-step tasks, remembering what the user just said.

Working memory is automatic — you do not need to configure it. The model’s context window effectively defines its capacity.

Example: A user asks “What are the outstanding invoices for Acme Corp?” The agent queries QuickBooks, receives 15 invoices, and holds them in working memory so it can answer follow-up questions like “Which of those are overdue?” without querying again.

Episodic Memory

Episodic memory stores conversation-level context — the key facts and outcomes from each conversation the agent has.

• Scope: per-conversation summaries and key data points.
• Lifetime: persists across conversations within the configured retention period.
• Use case: recalling previous interactions (“Last week you asked about Q3 revenue — here’s the update”), maintaining continuity.

Episodic memory is automatically generated at the end of each conversation. Horizon summarizes the conversation into a compact record that includes:

• Topics discussed
• Decisions made
• Skills invoked and their results
• Open items or follow-ups

Example: A user had a conversation last Tuesday about reconciling Q3 invoices. When they return a week later and say “How did the reconciliation go?”, the agent retrieves the episodic memory to recall the context.

Semantic Memory

Semantic memory is the agent’s long-term knowledge base. It stores facts, preferences, and patterns learned over time — independent of any single conversation.

• Scope: cross-conversation knowledge about users, processes, and business context.
• Lifetime: persistent until explicitly cleared or updated.
• Use case: learning user preferences, remembering business rules, building up domain knowledge.

Semantic memories are extracted from conversations. They may carry a caller-supplied confidence value (see below).

Example: Over several conversations, the agent learns that “When the CFO asks for a P&L, she always wants accrual-based accounting and a quarterly comparison.” This preference is stored as a semantic memory and applied to future requests automatically.

Session vs persistent scope

Each memory entry has a scope that controls its lifetime:

Scope	Lifetime	Cleared when
Session	Active conversation only	Conversation ends
Persistent	Across conversations	Manually cleared, retention period expires, or agent is deleted

• Working memory is always session-scoped.
• Episodic memory is always persistent (but subject to retention settings).
• Semantic memory is always persistent.

Retrieval limits

There is no user-facing retention configuration. What memory an agent loads is bounded by engine defaults:

Default	Value
Maximum memories loaded per run	50
Episodic look-back window	30 days
Episodic memories loaded	20

Caution

An earlier version of this page described a Memory tab offering an episodic retention period (90 days), a semantic memory limit (500) and an auto-summarization toggle. None of those settings exist — not in the dashboard, and not as engine configuration you can reach. The three values above are the real limits, and they are engine defaults rather than per-agent options.

Confidence

A semantic memory may carry a confidence value, but it is worth being precise about what it is and is not.

It is supplied by whoever writes the memory. It is an optional field on the write, and it is nullable — the platform does not compute it, does not assign one when the caller omits it, and does not adjust it over time. A memory with no confidence is entirely normal.

Nothing currently reads it. Confidence is stored and returned, and that is all. It does not change whether or how a memory is retrieved, and it does not change how the agent treats a memory once retrieved.

Caution

An earlier version of this page described confidence bands (0.9–1.0 high, 0.7–0.89 medium, and so on) and claimed that high-confidence memories are applied automatically while low-confidence ones prompt for confirmation. None of that is implemented. No threshold anywhere in the platform reads these values. Do not design your agents around that behaviour, and do not expect a low confidence value to make an agent more cautious.

If you are writing memories through the API, treat confidence as a field for your own bookkeeping — a number you can store now and filter on yourself later — rather than a signal the platform acts on.

Turning memory on and off

The user-facing memory control has three settings:

Setting	Behaviour
Off	Memory is not used.
Ask First	The agent asks before writing a memory.
On	Memory is used and written without prompting.

memorySetting is an engine-level control. It is not currently surfaced in the Horizon dashboard.

Viewing and managing memory

Memory is managed through the agent memory API, not through a dashboard tab. Per agent, the API supports:

Operation	Endpoint
List memories	GET /
Memory statistics	GET /stats
Read one memory	GET /:key
Create or update a memory	PUT /:key
Delete one memory	DELETE /:key
Delete all memories	DELETE /

Caution

There is no Memory tab in the Horizon dashboard. If you were sent here to “open the agent’s Memory tab”, that surface does not exist — use the API above.

Best practices

1. Let memory build naturally — resist the urge to pre-load hundreds of semantic memories. Agents learn best from real conversations.
2. Review memories periodically — list them through the API and remove outdated or incorrect entries.
3. Correct wrong memories directly — if an agent keeps making a wrong assumption, find the memory behind it and edit or delete it. Lowering a confidence value will not change the agent’s behaviour, because nothing reads it.
4. Delete rather than rely on retention — there is no configurable retention period, so in compliance-sensitive environments remove memories explicitly (DELETE /:key, or DELETE / for all of an agent’s).
5. Keep the memory set small — each retrieved memory consumes tokens on every run, and retrieval is capped at 50 rather than tuned per agent. The lever is fewer stored memories, not a smaller limit.