> ## Documentation Index
> Fetch the complete documentation index at: https://docs.duvo.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent Memory
> Personalize how an agent works for you with a private context layer, without changing the shared AOP everyone else uses.
Agent Memory is subject to change. Duvo is still developing how Memory is
saved, read, and shown. The defaults on this page, such as the memory budget
and the rules for what an Agent saves, can change between releases. Check this
page and the [changelog](/changelog) before you build a workflow that depends
on a specific Memory behavior.
## Introduction
Agent Memory is a powerful feature that allows you to personalize how an agent works specifically for you, without changing the core AOP that everyone else uses. This means multiple users can run the same agent with their own individual preferences, thresholds, and requirements automatically applied.
## What is Agent Memory?
Memory is your personal context layer for any agent you have access to. When you add information to Memory, the agent will remember and apply those preferences every time you run it—but only for your runs. Other users running the same agent will have their own Memory settings applied to their sessions.
Think of Memory as your agent's personalized notepad about your specific preferences, while the main AOP remains the shared "company policy" that applies to everyone.
## How Memory Works
When you run an agent, Duvo combines:
* The agent's core AOP (shared by all users)
* Your personal Memory settings (specific to you)
* Any run-time prompts you provide during that specific session
This allows the same agent to adapt to different users' needs automatically, without requiring separate agents for each person or constant manual adjustments.
## The AOP Takes Priority
The current AOP takes priority over saved Memory and the default memory rules.
By default, an Agent saves reusable lessons rather than checkpoints, cycle logs,
individual-item records, or work output. It can save those records when the AOP
explicitly asks it to.
For an explicit requirement, the Agent follows the AOP's instructions about what
to record, where to keep it, when to read or reuse it, and when to clear it. It
does not remove required data to meet the default memory budgets or cleanup
rules. Access restrictions and the rules against saving secrets and personal
data still apply.
A general instruction to "use memory" does not create an exception. State the
required records and their purpose in the AOP. A saved note cannot change the
AOP or create permission to skip a required check.
## Memory File Size Warnings
When an Agent creates or edits an Agent or Queue Memory file, the memory tool
warns it if the saved file exceeds the default 1,200-character budget. The
count includes the full file, including frontmatter.
The write succeeds and the file stays saved. The warning asks the Agent to
consider pruning or shortening the file while keeping all data the current AOP
explicitly requires. The warning does not delete or shorten content, and the
Agent does not need to repeat the write.
## Why Use Memory?
**Personal thresholds and preferences**: Set approval limits, priorities, or preferences that match your role and authority level
**Saves time**: Avoid providing the same context or guidance every time you run an agent
**Maintains consistency**: Your preferences are automatically applied to every run, ensuring the agent always works the way you need it to
**Preserves shared workflows**: The core AOP stays intact for everyone else while you get personalized behavior
## How to Add Memory
To add information to Memory for a specific agent:
Open the agent you want to personalize.
Navigate to the Memory section in the agent settings.
Describe your preferences in plain English, just like you would in the Agent Builder.
Your preferences will now automatically apply every time you run this agent.
## Enable or Disable Agent Memory
You can control whether an Agent uses its saved Memory from the **Memory** tab
in the Agent Builder.
Open the Agent in the Agent Builder and select the **Memory** tab.
Select **Enable** when the Agent has no Memory files, or **Re-enable** when
saved files already exist. To turn Memory off, open the Memory actions menu
and select **Disable memory**.
When Memory is off, the Agent does not read or update its saved files. The files
remain available to view and return when Memory is re-enabled.
If an administrator archived the Agent's Memory, you can disable it but cannot
enable it again until an administrator restores it.
## Deleting Memory Files in Bulk
When you have edit rights on an Agent or Queue's Memory, you can clear out several files at once instead of removing them one by one.
Open the Memory section for the Agent or Queue.
Tick individual files, tick a folder to include everything inside it, or use **Select all**. Shift-click the first and last file in a range to select everything in between.
Choose **Delete** and confirm. Duvo removes the selected files together and updates progress as each one completes.
If some files can't be deleted, Duvo removes the rest and shows how many were deleted; anything that failed stays in the list so you can retry it.
## Real-World Examples
These examples apply where the AOP permits the described preferences. Memory
cannot remove an AOP requirement.
### Example 1: Purchase Order Approvals
Your company has a PO approval agent that processes purchase orders. The core AOP requires human approval for orders over a certain amount.
**User A (Department Manager)** adds to Memory: *"Auto-approve all purchase orders under $5,000 from approved vendors. Flag anything over $5,000 for my review."*
**User B (Director)** adds to Memory: *"Auto-approve all purchase orders under $10,000. For orders between $10,000-$25,000, check if they're budgeted before requesting approval. Anything over $25,000 requires VP sign-off."*
Both users run the same agent, but it automatically adapts to their different approval authority levels.
### Example 2: Customer Communications
Your team uses an agent that drafts customer response emails. Different team members have different communication styles and preferences.
**User A (Account Manager)** adds to Memory: *"Always use a warm, conversational tone. Include my direct phone number in the signature. CC me on all customer correspondence."*
**User B (Technical Support)** adds to Memory: *"Keep responses concise and technical. Include links to our documentation. Don't CC me unless it's urgent."*
The same agent produces emails that match each user's style and preferences automatically.
### Example 3: Report Generation
A weekly sales report agent pulls data and distributes reports to leadership.
**User A (Sales Manager - West Region)** adds to Memory: *"Only include data for California, Oregon, and Washington territories. Highlight accounts over \$50K in annual value. Send the report to my regional team."*
**User B (Sales Manager - East Region)** adds to Memory: *"Only include data for New York, New Jersey, and Pennsylvania territories. Highlight accounts over \$100K in annual value. Send the report to my regional team and VP of Sales."*
Each manager gets a personalized report from the same agent without duplicating the workflow.
## What to Include in Memory
Memory works best when you provide:
* **Personal thresholds**: Dollar amounts, quantity limits, time frames specific to your role
* **Preferences**: Communication style, formatting choices, notification preferences
* **Contextual rules**: Exceptions or special handling for your department, region, or responsibilities
* **Contact information**: Who should be notified, CC'd, or involved in your runs
* **Priority guidance**: What matters most to you when the agent needs to make judgment calls
## What Happens When an Agent Moves to Another Team
When an Agent moves to another team, its Memory moves with it, along with the
Memory attached to any Queue that moves in the same operation. The Agent arrives
on the new team with its context intact, so runs behave the same way after the
move as before it.
If the destination team already has Memory for that Agent or Queue — which
happens when the Agent lived on that team before and left its Memory behind —
the destination team's existing Memory is kept and the incoming Memory stays
where it is. Nothing the destination team already relies on is overwritten.
Archived Memory on the destination stops the move, and the error identifies
the Agent or Queue that is blocking it. Restore or delete that Memory on the
destination team, then move the Agent again. Duvo stops rather than silently
leaving the Agent's Memory behind.
Unusually large Memory is also refused rather than moved in part. The message
names the limit — clear out Memory the Agent no longer needs, then retry.
## Key Takeaways
* Memory personalizes agent behavior for your specific needs without changing the core AOP
* Multiple users can run the same agent with their own individual Memory settings
* Memory is perfect for thresholds, preferences, and personal context that applies to all your runs
* Memory complements (but doesn't replace) run-time prompts for one-time guidance
* You can update Memory settings at any time
* Memory behavior is subject to change; keep records a workflow cannot lose in a system of record, and state that requirement in the AOP, instead of depending on Memory defaults
Agent Memory ensures that automation works the way you need it to, while maintaining consistency and collaboration across your team. Set it once, and let your agents remember what matters most to you!
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.