Stop Being Held Hostage by Agent Platforms

It is Monday morning, and you are teaching the same job for the fourth time.

The first agent you used learned how you like your follow-ups written — it kept the notes on your machine, in its own memory files, in its own format. The second ran the whole process in its cloud and did it well; the history of what it did lives in that account, in that product, nowhere else. The third remembers a different slice again, scoped to one workspace. Now the fourth one — this quarter's obvious upgrade — is open in front of you, and it knows none of it. Blank chat window. You start explaining. Again.

Nothing here is a conspiracy. Each of those agents did exactly what it was designed to do: keep what it learns close, so you keep coming back. But look at where your working life now sits. Your preferences are in one vendor's memory store. Your task history is in another's cloud. Your team's rules are written three times, in three dialects, in three folder conventions. The models were never the lock-in — models are replaceable, and you replace them constantly. The hostage is not the model. The hostage is your data, held one drawer at a time.

How the hostage-taking works: three drawers

It helps to be precise, because the industry is not uniformly closed — and the honest version of this problem is worse than the slogan version, because it is quieter.

Drawer one: the files you write yourself. Claude Code reads CLAUDE.md (and AGENTS.md). Codex reads AGENTS.md, capped and layered its own way. Cursor reads .cursor/rules/*.mdc, with its own frontmatter semantics for when a rule applies. Copilot reads .github/copilot-instructions.md. These are local files, mostly in your repo, and they are the most portable layer you have. But portable is not the same as shared: every vendor chose a different name, a different directory, a different format, and different rules for what loads when. Moving your instructions from one agent to another is a translation job, every time.

Drawer two: what the platform accumulates for you. This is the layer you did not write and cannot pack. Claude Code's auto memory — notes it writes about your corrections and preferences — lives on one machine, in its projects folder, in a format no other agent reads. Codex offers the same idea as an opt-in feature, and OpenAI's own docs describe the result as "generated state" in ~/.codex/memories/, a recall layer for Codex alone; even inside OpenAI's own house, ChatGPT's memory and Codex's memory are two separate stores. Copilot Memory, GitHub's version, sits on GitHub's side of the fence, is read only by Copilot's own surfaces, and — per GitHub's concept documentation — quietly deletes any entry that goes unused for 28 days. Grok keeps the whole arrangement in your xAI account: chat history, learned preferences, personalization, synced across its apps and exportable only as one account-wide download. Devin's cloud sessions, playbooks and organizational knowledge live in Cognition's platform — and when Cognition deprecated its Knowledge feature, the notes users had accumulated were migrated on the vendor's schedule, by the vendor's decision. Manus runs your tasks in its own cloud sandboxes and keeps the transcripts and artifacts in your Manus account; its API deletes uploaded files after 48 hours.

Drawer three: the work itself. Underneath the instructions and the memories sits the thing that actually matters: the records of the work — the leads and their states, the tasks and who owns them, the drafts, the approvals, the outcomes. When an agent does a job inside its own platform, that state is born inside the platform: in a session transcript, a task list, a sandbox filesystem. When you leave, the transcript is what you get to keep. The state — queryable, structured, still moving — stays behind, or evaporates.

Notice what all three drawers have in common. It is not malice. It is that each platform is a place, and your work accumulates in the place where the agent happens to live. Switch agents and you do not lose the model. You lose the accumulation.

Seven platforms, at a glance

One fair counterpoint before we build on this: the file layer is genuinely converging. AGENTS.md is now an open format stewarded by the Agentic AI Foundation under the Linux Foundation, and Codex, Cursor, Copilot and Devin all read it. SKILL.md — the Agent Skills format — has been adopted just as widely. What you write by hand is learning to travel. What the platform accumulates on your behalf is not. The drawers remain, and the work still lives in them.

Schematic — two answers to the same question: where does the work live?

The alternative fits in one diagram

Stop asking each agent to be the place. Put the place somewhere of your own, and let every agent visit it.

Schematic — one pool, every agent. Not product UI.

The pool is a Busabase workspace, and its contents are deliberately boring — four kinds of things, all of them yours:

• Skills — the methods, as first-class nodes. A Skill in the pool is a standing instruction set any connected agent reads before it acts; Playbooks collect every Skill and every node's custom prompts into one catalog, so "how do we do this here?" is looked up in the same place no matter which agent is asking.
• Apps & code — the AirApps built on the data. The follow-up board your team opens in the morning is the same object the agent updates at night; the app is not one vendor's front end, it lives with the data.
• Database — records — the work itself, as typed records with owners, statuses and relations. A lead is a record, not a paragraph in a transcript. Its state is queryable by you, by a person, by the next agent.
• Structured context — the Docs that hold standing policy (who qualifies, what we never promise) and the relations that say what things mean and how they connect — so a new agent does not have to infer your world from chat logs. (The objects themselves — Company, Contact, Deal — will gain an explicit semantic layer: an ontology, in development and not yet available.)

And the agents? They connect — through the Agent Skill, MCP, OpenAPI, the CLI, or an ACP session; there is no built-in model in the pool and no favorite. An agent can even point its own local skills directory at a Skill node in the workspace, so the method it follows is the pool's copy, not a fork it keeps. Every write an agent makes travels as a Change Request — a proposal with a diff, an author, and a history — so the pool accumulates under governance, not by whoever shouted last. That is the whole architecture: agents are hands; the pool is the memory, the rules, and the record. Hands get replaced. The pool stays.

The switch, walked through

Here is the same week, rerun with a pool. (A walkthrough, not a customer story — the point is what does not have to happen.)

Monday, Claude Code works the lead follow-up. It reads the ICP from a Doc in the pool, follows the follow-up Skill, drafts replies onto lead records, and the sends it makes are logged on the same records, as Change Requests your team can inspect. Wednesday, you are trialing Codex. You connect it to the same workspace — the setup is one skill file — and ask it to continue the follow-ups. It reads the same records: which leads are waiting, what was already sent, what the standing policy says, what the last agent did and why. It does not need your Monday lecture, because there was no lecture; the context was never in Monday's chat window. It was in the pool. Friday, a teammate asks why a lead went quiet. Nobody opens a transcript. The record shows the state, the history shows the writes, the Change Request shows who approved what.

What changed hands? The model, the interface, the bill. What did not change: the data, the rules, the context, the history, the apps on top. That is the entire trick — and it only works because none of those things were ever stored inside an agent.

What this does not magically fix

Honesty, because manifestos rot without it. Moving to a pool does not import the memories your platforms already accumulated — no vendor offers that export, which is rather the point of this article; you start the pool from your own records and rules, and from then on the accumulation is yours. Platform-native conveniences stay behind too: an agent's self-written memory is genuinely delightful, and in the pool model that learning has to land somewhere reviewable — as experience records, reviewed and promoted into the Skill — instead of silently compounding inside one tool. File conventions inside your repos still matter; AGENTS.md in a repo and a Skill in the pool are cousins, not substitutes. And the workflow execution story is the same calibrated one as always: the runtime's first version is in place today (start a workflow manually, or when its records change), with field-value triggers, schedules, webhook headers and approver pickers in the batch now landing.

A pool is not a bigger platform. It is the decision that the accumulation — the thing that makes an agent useful to you specifically — should compound in a place you own, in formats you can inspect, under permissions you set. Busabase is open source and self-hosts in one command; the pool can live on your own machine, which is rather the point. We wrote about that starting point in your own personal database, and about the memory-and-rules layer itself in Supabase vs Busabase.

FAQ

Can't I just standardize on AGENTS.md everywhere? Do — it is the best-traveled layer, and this article's table is partly a recommendation to keep it. But AGENTS.md carries only the first drawer: instructions you wrote. It does not carry the memories a platform accumulated, the history of what was run, or the structured state of the work itself. Standardize the file; just don't mistake the file for the whole estate.

Isn't Busabase just one more platform to be locked into? It is the obvious question, and it has a checkable answer: Busabase is open source, runs on Postgres (or embedded PGlite), and self-hosts with one command — the pool can sit on your laptop or your own server, and the records, Docs and Skills in it are yours to export and inspect. Judge it the way this article judges everyone else: by where the accumulation lives and who can take it away. Sovereignty, not tenancy, is the design goal — the longer version is in Sovereign AI for agents.

Do I have to give up my favorite agent? No — that is the point. Keep Claude Code for the work it is best at, trial Codex next quarter, let Grok answer quick questions. The pool does not ask for loyalty. It asks that whichever hand is working today, it works on your records, under your rules, and leaves the state where tomorrow's hand can find it.

Agents will keep changing. The pool shouldn't have to.

There will be a better agent next quarter. There will be a pricing change, a deprecated feature, an acquisition — Devin's users have already watched one vendor rename the product and retire the memory system mid-flight. None of that is a scandal; it is the normal weather of a young market. The scandal would be letting your company's working memory live wherever that weather blows it.

So: stop letting agent platforms hold you hostage. Keep the agents — all of them, whichever ones win. Move the skills, the apps, the database and the context into one pool with your name on it, and let every agent, present and future, plug into that.

• Start with the pool itself: your own personal database — self-hosted in one command
• The framework inside the pool: Supabase vs Busabase: the memory-and-rules layer
• Why the work in the pool is organized as workflows: The atomic unit of the enterprise is the workflow
• Code: github.com/busabase/busabase · Docs: busabase.com/docs