Most companies have a backup routine for databases and shared drives. Very few have one for the AI agent they put into daily work. The agent runs, it answers, it slowly accumulates settings, rules and notes, and nobody can say what would happen if it all vanished: a deleted workspace, a vendor account closed by mistake, a change that broke the behaviour and cannot be undone.
This article is for technology leads who own, or will soon own, an agent in production. It lists what an agent consists of, what is worth saving, what should never be saved, and how to prove that a restore works.
What an agent actually consists of
It is tempting to think of the agent as "the model". The model, however, belongs to the vendor and you cannot lose it. What you can lose is everything that makes the agent yours. In practice there are five parts.
Instructions. The system prompt, role description, tone rules, examples and the list of things the agent must not do. This is often the most valuable part and the least protected, because it lives in a text field of a web console and was edited several times by several people.
Configuration. Which tools are connected, which model and version is used, temperature and other parameters, routing rules, escalation thresholds, working hours, languages. Small values, large consequences.
Memory. Anything the agent keeps between conversations: notes about customers, stored preferences, summaries of past work, a vector index built from your documents. Memory is the part most likely to be both valuable and unique.
Sources. The documents the agent reads. These usually have an owner and a home already - a wiki, a shared drive, a help centre. Our article on preparing company documents explains why the owner matters.
Access settings. Accounts, roles, permissions, and the secrets that make the connections work. The principles in least-privilege access for AI agents apply here as well: what the agent may touch is part of what you must be able to restore.
Each of these fails in its own way. A prompt gets overwritten. A configuration is changed during a vendor update. Memory is polluted by a wrong note. A permission is lost when an employee leaves. Treat them as separate items on one list, not as one blob.
What to back up, and what to leave out
The simple rule is: back up what you cannot rebuild from somewhere else in reasonable time.
| Part | Back up? | How |
|---|---|---|
| Prompts and examples | Yes, always | Plain text in version control, with date and author of each change |
| Configuration | Yes | Export to a readable file, or a written table if the platform has no export |
| Memory | Yes, if it holds approved knowledge | Periodic export; keep the last few versions, not only the latest |
| Source documents | Pointer only | Record where they live and who owns them; they have their own backup |
| Search index | Usually no | Rebuild it from the sources; keep the recipe and the settings |
| Conversation logs | According to policy | See the retention rules in the activity log article |
| Secrets | Never in the backup | Record which exist, who owns them and where they are stored |
Two points deserve a comment. First, versions. A backup that overwrites itself every night will happily save your mistake. If someone broke the prompt on Monday and noticed on Thursday, you want Sunday's copy, not last night's. Keep several generations and name them by date.
Second, secrets. It is convenient to export "everything" in one file, and that file will contain keys. Do not allow it. A backup is copied, shared with a contractor, attached to a ticket. Store in the backup only a list: which connection, which account, who can issue a new key, and where the current one lives. After a restore, the keys are issued or retrieved through your normal secret management, and the old ones that might have leaked are rotated.
The memory problem
Instructions and configuration are small and clear. Memory is harder, for three reasons.
It changes constantly, so a backup is always slightly behind. It can contain personal data, which means the backup falls under the same rules as the live system, including deletion requests. And it can be wrong: an agent that stored a false note will repeat it, and a faithful backup will faithfully restore the falsehood.
For these reasons we suggest separating memory into two kinds. Approved memory is knowledge a person has read and accepted - a rule, a customer preference, a standing decision. Working memory is whatever the agent collected on its own. Back up approved memory carefully and often. Treat working memory as something you can lose with limited damage, and decide how often it needs a copy by asking what the cost of losing a week of it would be.
If you cannot separate the two, that is itself a finding. It means nobody reviews what the agent remembers, and the problem is bigger than backups.
Decide what loss you can accept
Before you build anything, answer two questions with the people who rely on the agent.
How much change can we afford to lose? If the prompt was improved on Tuesday and the system fails on Wednesday, is it acceptable to return to the version from the previous Friday? For some agents yes; for an agent that handles customer promises, probably not.
How long can the agent be off? Count the time it takes to restore, not the time it takes to notice. Then decide who covers the work meanwhile. The same fallback thinking appears in our article on a plan B when the vendor changes the model or price, and a person who takes the work back is often the simplest plan.
Write the answers in two sentences and put them next to the backup list. They decide how often to copy and how much effort the restore deserves.
A restore test you can run in an afternoon
A backup is a claim. A restore test is the evidence. Here is a short version that fits into half a day.
- Prepare a clean environment. A new workspace or project, with no connection to production data and no live access to customers. Use test accounts.
- Restore from the backup only. One person follows the written steps, using nothing but the backup and the documentation. If they need to ask the original author, write down the question; that is a gap.
- Reconnect access properly. Obtain keys through the normal process. Note how long it takes and who had to approve it.
- Run a fixed set of test questions. Ten to fifteen is enough: a few routine questions, a few that need a source, a few the agent must refuse, and one or two that should trigger a handoff to a person. Use the cases from the agent's original brief and acceptance test if you have them.
- Compare with the live agent. Not word for word, because answers vary, but in decisions: did it answer, refuse and escalate in the same cases?
- Record time and gaps. How long did the restore take? What was missing? What depended on a person's memory instead of a document?
Fix the gaps, update the list, and set a date for the next test. Once or twice a year is reasonable, and always after a major change of platform, model or ownership.
Common mistakes
- Backing up only the prompt. The prompt is the part people remember; configuration and permissions are the parts they forget.
- Keeping one copy. A single overwritten backup saves the mistake together with the file.
- Storing secrets with the rest. Convenient today, a leak later.
- Restoring into production to "see if it works". Test in a clean environment.
- No owner. If nobody is named for the backup, nobody notices when it stops running.
- Forgetting the people. The restore instructions should be readable by someone who did not build the agent, since that may be exactly who needs them.
Where to start
Open the agent's console and write down, for each of the five parts, where it is stored and who can change it. Most teams find at least one part that exists in a single place, edited by a single person, with no history. Export that one first. Then agree on the acceptable loss and downtime, and schedule the first restore test. If you have not yet prepared for the situation in which the agent has to be stopped quickly, read kill switches and incident response next; a restore is much calmer when stopping was calm.
