AI Agent Backup and Restore: What to Save and How to Test It

To back up an AI agent, save everything that defines how it behaves and what it knows, not the model itself. That means configuration, instructions, memory, skills, tool definitions and references to credentials. Then prove the backup works by restoring it into a clean environment and checking that the agent behaves as it did before. A backup you have never restored is only a hope.

Key takeaways

• The model is usually rented. What you must protect is the layer around it: configuration, memory, skills, tool connections and permissions.
• Back up references to credentials (what exists, who owns it, what it can do, how to reissue it), never the secrets themselves.
• Memory has two kinds of content: what can be rebuilt from source documents and what exists only because the agent learned or recorded it. Prioritize the second kind.
• Include a small set of test cases in the backup so you can measure whether a restored agent behaves correctly.
• Run a restore drill on a schedule and after major changes, in a separate environment, with a named person responsible for the result.

What does an AI agent consist of, and what is yours to back up?

Most business agents are assembled from parts. A model provider supplies the reasoning. Everything else is specific to your company and lives somewhere you must be able to reach: the instructions that define the role, the memory the agent has built up, the skills it follows, the tools it can call, and the accounts it uses to act.

It helps to sort these parts by how hard they are to recreate:

• Easy to recreate: the model itself, general-purpose libraries, the hosting platform.
• Costly to recreate: role instructions refined over months, skills tuned against real cases, tool definitions that match your systems.
• Impossible to recreate from outside: memory the agent accumulated, decisions about what it may do without approval, the history of why a rule exists.

The second and third groups are your backup scope. If you want a wider picture of how these parts fit together, the seven layers of company AI infrastructure give a useful map.

One more point before the lists. A backup is a plan for several different failures: a deleted setting, a bad update, a compromised account, a provider outage, a move to a new host. The same backup should serve all of them, which is why the restore test matters more than the backup itself.

Which configuration should you save?

Configuration is the part people most often assume is safe because it lives "in the platform". It may be, until the platform changes, an administrator leaves, or a setting is overwritten by mistake. Export it into a readable, versioned form that you control.

A good configuration backup includes:

• The role definition and system instructions, in full, with the date and author of the last change.
• The model choices and parameters the agent uses, including any fallback model.
• Channel settings: which inboxes, chat spaces or forms the agent listens to and replies on.
• Permission and approval rules: what the agent may do alone, what needs a person, and who that person is.
• Schedules and triggers for recurring or event-driven work.
• The names of environment variables and settings the agent expects, without their secret values.
• A short change log explaining why important settings are what they are.

The change log is underrated. A restored agent that has the right settings but no explanation invites someone to "fix" a rule that was added after an incident. Pair this with a disciplined update process, such as the one described in how to update an AI agent in production without breaking it, and each version of the configuration becomes a restore point you can name.

How do you back up an agent's memory and knowledge?

Memory is where backups get subtle, because the word covers several different things. Treat them separately.

• Working state: notes an agent keeps to continue a task across sessions, such as progress files or task lists. Long-running agent designs depend on this kind of handoff between sessions, as Anthropic describes in its write-up on [effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents). Losing it means losing the thread of unfinished work.
• Long-term memory: facts, preferences and corrections the agent has recorded about your company, customers or processes. This is often the most valuable and least reproducible content.
• Knowledge sources: the documents, wikis and records the agent retrieves from. The original files usually live in your own systems.
• Derived indexes: the searchable representation built from those sources. It can normally be rebuilt, though rebuilding may take time.
• Conversation and action history: useful for audit and for diagnosing problems, but subject to retention decisions.

The practical rule: back up long-term memory and working state in a readable export, back up the source documents and the settings used to ingest them, and treat the index as optional unless a rebuild would take longer than your business can tolerate. For each item, write down who may read it.

There is a privacy consequence. A memory backup contains company data, sometimes personal data. It needs the same access controls as the live system, and it should sit in a location consistent with your obligations. AI data residency for business covers how to think about where that data may live. Decide too how long history is kept, because a backup that keeps everything forever can become a liability of its own.

What about skills, tools and workflows?

Skills are the written procedures an agent follows: how to triage a request, how to prepare a weekly summary, how to check an invoice against a purchase order. Tools are the connections that let it act on systems. Both encode how your company works, and both deserve a backup.

Save the following:

• Each skill or procedure as plain text, with its trigger and its expected output.
• Tool definitions: names, descriptions, input and output formats, and the scope each tool is allowed to touch. Clear tool descriptions strongly affect agent behavior, which is why Anthropic's guidance on [writing effective tools for agents](https://www.anthropic.com/engineering/writing-tools-for-agents) is worth reading before you rewrite one from memory.
• Connector settings, including which endpoint or server each tool points to. If you use the Model Context Protocol, record which servers are connected and what each exposes. The [protocol introduction](https://modelcontextprotocol.io/docs/getting-started/intro) explains the model.
• Workflow definitions that chain several steps, including the approval points.
• A set of test cases: realistic inputs with the outcome you consider correct, including a few where the right answer is to refuse or escalate.

That last item turns a backup from a pile of files into something you can verify. Without test cases, "the restored agent seems fine" is an opinion. With them, it is a result. If you have not written such cases yet, defining success criteria for a pilot is a good place to start.

How do you handle credentials without storing secrets in the backup?

The safest backup of a secret is no copy at all. API keys, passwords and tokens belong in a dedicated secrets store with its own access controls and its own recovery process. What your agent backup should hold is an inventory of references.

For every credential the agent uses, record:

• What it is for and which system it connects to.
• Which account it belongs to, and which person or team owns that account.
• The scope it grants, written as precisely as possible, so you can confirm a replacement is no broader.
• Where the secret is stored and who can retrieve it.
• How to rotate or reissue it, and how to revoke the old one.

Two details matter at restore time. First, authorization tokens issued through OAuth are typically tied to a specific grant and often should not simply be copied to a new environment. Plan to re-authorize, and know who has the authority to approve the consent. Google's [OAuth 2.0 overview](https://developers.google.com/identity/protocols/oauth2) describes how those grants and refresh tokens work. Second, a restored agent must not come back with broader permissions than it had. Review the restored access against the principle of least privilege, as laid out in the [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html).

This is far easier when the agent has its own identity and accounts rather than borrowing a staff member's login. Why your company AI agent needs its own identity explains the reasoning. It is also easier when the company, not a vendor, owns the model accounts and keys, a point covered in who owns AI API keys in a business.

How do you test a restore, step by step?

A restore test answers one question: if the live agent disappeared today, could we have a working equivalent, and how long would it take? Run it in a separate environment so nothing in production is touched.

• Name an owner and a purpose. Decide who runs the drill, who judges the result, and which failure you are simulating (lost host, bad update, compromised account).
• Choose the restore point. Pick a specific backup version, not "the latest", so you also learn whether versions are labeled clearly.
• Prepare a clean environment with nothing carried over from the live agent. If the restore only works because of leftover state, you want to find that out now.
• Restore configuration first, then skills and tools, then memory and knowledge sources. Note every step where someone had to guess or ask.
• Reissue credentials from the inventory, using the documented procedure. Confirm each new credential has the intended scope and nothing more.
• Rebuild derived indexes if they were not backed up, and record how long that takes.
• Run the saved test cases. Compare behavior with what you expect, especially refusals, escalations and approval steps.
• Check boundaries. Confirm the restored agent cannot reach systems or data it should not, and that approvals still route to the right people.
• Record the elapsed time, the gaps found and the fixes. Update the backup scope and the written procedure before closing the drill.
• Retire the test environment and revoke any temporary access created for it.

An illustrative scenario: a finance team uses an agent that drafts payment reminders and flags unusual invoices for review. During a drill, the team restores the configuration and skills without trouble, but the agent drafts reminders in the wrong tone. The cause is a correction recorded in long-term memory months earlier, which the backup had skipped because it was assumed to be rebuildable from documents. The fix is small: add the memory export to the backup scope. The discovery is the point of the exercise, and it happened in a drill rather than in an outage.

Repeat the drill on a regular schedule and after any major change to the agent's role, tools or hosting. Each run should be shorter and less surprising than the last.

How does Be Human approach backup and restore?

Be Human treats backup and restore as part of operating an agent, not as a separate project. During an engagement, the agent's configuration, skills, tool definitions, memory and approval boundaries are documented as part of the agent's operating context, and credentials are tracked as references with named owners rather than copied into the backup. Managed operations can include recurring restore checks, permission review after a restore, and controlled changes with a recorded version history. The company keeps control of the accounts and the data, so a restore never depends on a single person or on Be Human alone. For the recurring work this involves, see what managed AI services include, and for the portability side, what to keep, export and document in an AI provider exit plan.

Frequently asked questions

Do I need to back up the AI model itself? In most business setups, no. The model is supplied by a provider and can be reached again or replaced. What you need to back up is everything that makes the agent yours: its instructions, memory, skills, tool definitions and permission rules. Record which model and version the agent used so you can reproduce its behavior or compare a replacement.

How often should an AI agent be backed up? Match the frequency to how fast each part changes. Configuration and skills should be saved whenever they change, as part of the update process. Memory that grows daily deserves a regular automated export, while source documents are usually already protected by your normal document backups. Ask how much recent learning you could afford to lose, and set the schedule from that answer.

Can I store API keys and passwords in the backup? Avoid it. Keep secrets in a dedicated secrets store and put only an inventory of references in the agent backup: what each credential is for, who owns it, its scope and how to reissue it. This keeps the backup safe to share with the people who need it and makes rotation after an incident much simpler.

How do I know a restore actually worked? Run saved test cases against the restored agent and compare the results with what you expect, including cases where it should refuse or ask for approval. Also check that its permissions match the original and that it connects only to the systems it should. If a person who did not build the agent can complete the restore from the written procedure, the backup is in good shape.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.