Configuration
One agent.json5 file: the agent's name, model, prompt, tools, channels, schedule and permissions. Plain text you can open in any editor.
Explainer
AI agent platform lock-in: what you keep if the vendor disappears
Portability comes from formats, not promises: what an agent is on disk decides what you keep if the vendor disappears. Somewhere in the second call, procurement asks exactly that, and the honest answer cannot be a promise, because a promise is the thing that goes with the vendor. This page is the description of formats for Olano - what an agent actually is on disk, which of it you would keep if we were gone tomorrow, which of it you would genuinely lose, and what you would have to rebuild. It is written to work as a checklist for any vendor, including us.
The question procurement now asks
The first call used to be about capability. Now, somewhere around the second call, someone asks what happens to the agents if the vendor is acquired, pivots or shuts down. It has become a standard question for a plain reason: enough people have been through it. A product was switched off, the export turned out to be a spreadsheet of chat logs, and the instructions, corrections and accumulated knowledge went with it.
The tempting answer is a promise - a data-portability clause, an escrow arrangement, a line in the contract. Those are worth having. They are also exactly the things that evaporate with the vendor, because a promise needs someone around to keep it. The answer that survives is structural: what format is this in, and can I read it without you.
Three kinds of lock-in, and a fourth nobody prices
Data lock-in is the crude version: can you get your material out at all. It is the easiest bar to clear and the least informative, because an export that exists says nothing about whether you can use it.
Format lock-in is the one that actually bites. You got the export; can anything read it. An agent's instructions as rows in a proprietary database are yours in the legal sense and useless in every practical one. The same instructions as a markdown file are a thing you can open, paste into another product, or hand to a person.
Protocol lock-in is about the integrations. If every connection to your CRM, your calendar and your inbox was built on the vendor's own connector framework, leaving means rebuilding all of it. If they speak an open protocol such as the Model Context Protocol, the far end does not care who the client is. The same logic runs in reverse: an agent that can itself be reached over MCP or the Agent2Agent protocol is a door other software can use, not just a door into ours - see exposing your agent as an MCP server.
Operational lock-in is the fourth, and it is the honest one. Part of what you buy from any hosted platform is a running service - the process that keeps the channels open, fires the schedules and renews the tokens. That does not export, because it is not data. Every vendor has this form of lock-in, us included. The question is only whether you could run the service yourself if you had to.
What an agent is on disk
Formats first. This is the whole argument, so it is worth being concrete.
Instructions
AGENTS.md, SOUL.md, IDENTITY.md, USER.md and TOOLS.md - markdown files the agent reads at the start of every conversation. Editing one changes its behaviour on the next reply.
Memory
MEMORY.md for durable facts and a dated daily log per day under memories/, both markdown. Self-learning writes into them in the background; you can read and correct them directly.
Skills
A folder per skill, each holding a SKILL.md with a YAML header plus whatever scripts, templates and reference files it needs. The layout is the Agent Skills format, which is not something we own.
Notes, knowledge and output
A linked markdown wiki under notes/, the documents you added under knowledgebase/, everything the agent produced for you under reports/, and what you sent it under uploads/.
Transcripts and credentials
Conversation transcripts are files under the same home directory as everything else. Credentials live in an encrypted vault, never in a config file - which is also why they are the one thing you would not want in a plain copy.
What you would keep, and what you would lose
Line by line, if Olano stopped existing tomorrow.
| Part of an agent | If the vendor vanished | What it takes to use it elsewhere |
|---|---|---|
| Instructions and persona | Still readable. Markdown files in a folder you own. | Paste them into anything that accepts a system prompt, or hand them to a person. |
| Memory and daily logs | Still readable, same folder, same format. | The same. A distilled memory file is useful to a human on its own. |
| Skills | Still readable and still forkable - a folder with a SKILL.md and its scripts. | Any runtime that reads the same layout, or a person following the procedure by hand. |
| Configuration | Readable text, but written to Olano's schema. | The facts transfer - which tools, which schedule, which channels. The file itself does not run somewhere else. |
| Tools connected over MCP | Still there. An MCP server is a URL or a command in the agent's config, and the server itself is not ours. | Point another MCP client at the same servers. |
| Connector authorisations | Encrypted in the vault. Connections made through Olano's own app depend on that app existing. | Re-authorise each service with your own OAuth app or key. Unavoidable on any platform, and correct. |
| Conversation history | Transcripts are files. The live state a thread resumes from is in a database. | History is readable. A half-finished thread does not carry across, and we do not claim it would. |
| Channels | Stop. WhatsApp, Telegram and the rest are held open by the running service. | A running service - a self-hosted Olano, or another product with its own connectors. |
| The improvement loop | Stops. Everything it already wrote - learned skills, distilled memory, sharper procedures - stays in the files. | Run the runtime yourself, or accept the files as they stand. |
| Managed model tiers | Stop. Your own provider keys keep working. | Point the agent's model at a provider you hold a key for. One field. |
What you would actually rebuild
Read the table from the bottom up and the pattern is clear. What survives is everything that was a file. What you lose is everything that was a running process or a hosted relationship: the channels, the loop, the managed models, the connections that went through our app rather than yours.
Two of those are honest losses on any platform, and it would be dishonest to pretend otherwise. Connector authorisations have to be redone wherever you go, because the far end - Google, your CRM, your messaging platform - granted them to a specific application, and the new application is not it. And a service that holds a WhatsApp connection open at 3am is a service; you either run one or you pay someone to.
The rest is where design decisions show. Skills are folders because a folder can be copied. Memory is markdown because markdown can be read. Tools reach out over MCP because an open protocol means the integration you built is an asset rather than a hostage. None of that was accidental, and none of it is a promise - it is just what the files are.
The configuration file is the one honest middle case. It is readable text and it is written to our schema, so what transfers is the knowledge in it - which tools this agent had, what it was allowed to do, when it ran - rather than the file. That is the normal state of affairs for the configuration of anything, and we would rather say so than claim it runs elsewhere.
What we are not going to claim
There is no single export button, and we are not going to describe one that is not there. What there is: every file in a workspace can be opened and downloaded from the Files tab, the Memory view has its own Download, the Revisions tab shows any tracked file exactly as it was at an earlier point, and on a self-hosted install the configuration, workspaces and transcripts sit under one home directory on a machine you already own. That is less convenient than a button and considerably more trustworthy, because a button is a feature the vendor has to keep shipping, and a folder is just there.
Two more honest limits. One folder inside every workspace, named system, is Olano's own and is replaced on upgrade; nothing of yours lives in it. And the running conversation state - the part that lets a thread pick up where it left off after a restart or a model switch - lives in a database rather than a text file. The transcripts beside it are files, so nothing is unreadable, but you should not imagine carrying a live thread across to another product.
Files tab: open AGENTS.md and SOUL.mdMemory tab: read MEMORY.md, press DownloadSkills tab: open one skill, read its SKILL.md and bundled filesMCP tab: note each server's URL or commandRevisions tab: view an earlier version of any fileDecide what, of all that, you could not reproduce elsewhere
Questions to ask any vendor
Take these to every platform on the shortlist, including us. The good answers are all boring.
Ask to see the instructions in a text editor
If the agent's instructions can be opened as a file, you can read, copy and correct them without the product. If they can only be viewed inside the product, that is format lock-in with a nice interface.
Ask whether memory is a file or a feature
"The agent remembers" can mean a markdown document you can open, or a store you can only query through the vendor. Only one of those is yours in any practical sense.
Ask what a skill looks like on disk
A folder with a readable instruction file and its scripts can be copied and forked. A skill that exists only as rows in the vendor's database goes wherever the vendor goes.
Ask which protocol the integrations speak
Connections built on MCP can be pointed at by another client. Connections built on a proprietary connector framework have to be rebuilt from scratch, every one of them.
Ask whether you can run it yourself
Not because you plan to, but because a vendor who supports self-hosting has already made the exit possible, and one who does not has decided the exit is their call.
Ask what happens if their models go away
If an agent can only run on the vendor's own model tiers, the vendor's model supply is your single point of failure. Being able to point it at your own provider key is the difference between a bad week and a dead agent.
Why we would rather answer this than dodge it
Three facts make this an easy page for us to write. Olano can be self-hosted on your own infrastructure, and it runs the same either way - the same dashboard, the same configuration files, the same features. You can bring your own model keys on every plan at no surcharge (see the platform page), and one agent can run on them while another runs on the managed tiers; the plans themselves are on the pricing page. And each customer gets an isolated deployment rather than a slice of a shared one, in a region they choose, so the question of whose machine your files are on has a plain answer.
The corollary is worth stating without flinching. If Olano disappeared, what you would lose is the part we are paid for: the hosting, the updates, the channels held open overnight, the connections that went through our app, the managed models, and the loop that keeps improving the agents while nobody is watching. That is a real loss, and it is the correct thing to be paying for - a service you could replace with your own labour, rather than a format you could not replace at all.
What you would keep is the agent. Its instructions, its memory, its skills, its notes, its history: a folder of files a person can read. It is the only kind of portability that does not need us around to honour it, and it is why we would rather you asked.
FAQ
What happens to my AI agents if the platform shuts down?
It depends entirely on what the agent was made of. Anything stored as a readable file - instructions, memory, skills, notes - is still yours and still usable, with or without the vendor. Anything that was a running service - live messaging channels, scheduled work, managed models, connections authorised through the vendor's own app - stops, and has to be run or re-authorised somewhere else. On Olano an agent is a folder of markdown, a configuration file and a skills directory, so the first category is most of it.
Are AI agent skills portable?
On Olano, yes, in the plain sense: a skill is a folder holding a SKILL.md with a YAML header plus any scripts and templates it needs, in the Agent Skills format rather than a private one. That folder can be copied, read and forked by a person or by another runtime that understands the same layout. What does not travel automatically is any credential the skill relies on; the procedure is portable, the sign-ins behind it are re-established wherever it lands.
How do I avoid lock-in with an AI agent platform?
Judge formats, not promises. Ask to see the agent's instructions as a file you can open in a text editor, ask whether memory is a document or a query-only store, ask what a skill looks like on disk, ask whether integrations use an open protocol such as MCP, and ask whether the software can be self-hosted and run on your own model keys. A vendor who answers all five plainly has already built the exit; one who answers with a contract clause has not.
Can I export my agent's configuration and memory from Olano?
There is no single export button, and we do not describe one. Every file in an agent's workspace can be opened and downloaded from the Files tab, the Memory view has its own Download, and Revisions shows any tracked file as it was at an earlier point. On a self-hosted install the entire deployment - configuration, workspaces, transcripts - sits under one home directory on your own machine. Credentials are encrypted in the vault and are deliberately not part of any plain copy.
Can I self-host Olano?
Yes. Olano runs on your own machine or server as well as on Olano Cloud, and it runs the same either way: the same dashboard, the same agent configuration, the same features. A self-hosted install uses your own model provider keys rather than managed credits, and you take on keeping the service running, updated and connected. A cloud deployment can also use your own keys, so choosing managed models is a setting you can change rather than a one-way door.
What would I lose by leaving a hosted agent platform?
The service, not the material. On Olano that means the hosting and updates, the messaging channels held open around the clock, the scheduled and background work, the managed model tiers, the connections made through Olano's own app, and the improvement loop that keeps writing better memory and skills. What that loop already wrote stays in the files, because that is where it wrote it.
Related reading
Where to go next.
Agent skills portability
The skills question on its own: what a SKILL.md folder is and what actually moves with it.
Self-hosted AI agents guide
Running the same runtime on your own machine, and what you take on when you do.
Local AI agent vs cloud AI agent
The session-versus-service line, which is the operational half of this page.
Security at Olano
Isolated deployments, the credential vault, approvals and the audit trail.
Checked 14 September 2026. This page describes formats and dashboard surfaces as they exist today, not an export procedure; where a step is not documented we have said so rather than implied a button. If we have described something wrongly, write to support@olano.ai and we will correct this page.
Ask us the lock-in question first.
Bring the procurement checklist. We will go through it line by line - what is a file, what is a service, what you would rebuild - before anyone talks about a plan.