Here's a question that sounds simple until you try to answer it. If you were building an agent today, and you wanted to be sure you could pack it up and move it somewhere else later, how would you actually build it?
And the honest answer is that almost nobody builds that way, which is exactly why it's worth an episode.
That's Daniel's prompt this week. He starts from the observation that agentic AI is still early, and that every agent is a complex recipe. Model choice, memory store, system prompt, connected MCP servers. In theory you can swap any of those out for something better. In practice, lifting an agent off Vercel and dropping it into a different cloud, or onto a laptop that never touches the network, runs straight into a wall. Vectors embedded in one format aren't necessarily usable with a different model. You end up spinning up a new vector database of the matching type and migrating everything over.
Which is the part people underestimate. They think migration is a copy operation. It's a rebuild.
And Daniel's instinct is that there's real appetite out there for composable agents that are portable. His argument is that you keep the memory as raw material. Conversation history, prompts, the source files that feed the vector store, all in non-proprietary, interchangeable formats, even if that means duplicating a small amount of data. The vector store becomes a derived thing you can rebuild, not the place the truth lives. That's how you dodge vendor lock-in, but also the subtler one, the infrastructural or technological kind. So the question he lands on is the practical one. If portability is a requirement from day one, how do you architect and build?
There's a lot in there. And the diagnosis part is more interesting than the fix, because the fix is mostly discipline.
Start with the diagnosis then. What is an agent, actually, when you sit down to build one?
The cleanest way to say it is that an agent is the shift from a model that responds to a model that acts. A chat model takes a turn and hands you text. An agent takes a goal, calls tools, keeps state across turns, executes multi-step plans, and touches external systems. The tool-calling part is what makes it an agent rather than a conversation.
And the tool connection has largely standardized, right?
It has. MCP, the Model Context Protocol, has become the de facto way agents connect to tools. That part of the stack actually converged, which is good news and worth acknowledging before we spend the rest of the episode complaining.
But the agent isn't just the tool layer.
Not remotely. An agent is a composite noun. It's a stack. There's the model. There's the memory store, which is often a vector database. There's the system prompt, which is doing far more work than people admit. There are the MCP connections. There's the orchestration logic that decides what happens next. And sometimes there's a sandbox or an execution environment where the code the agent writes actually runs.
Six or seven components, each with its own format, its own API, its own assumptions about the world.
And here's the sentence that matters. The agent as a whole is only as portable as its least portable part.
That's the whole episode in one line.
It's the same modularity that makes agents flexible in theory and brittle in practice. Every component you can swap is also a component that can silently refuse to come with you.
So let's go to the part that refuses hardest. The vector database.
The vector store is the canonical portability trap, and the reason is embeddings. An embedding is a model's opinion about what a piece of text means, expressed as a list of numbers. And that opinion is specific to the model that produced it. A vector from one embedding model is not semantically compatible with a vector from another. It's not that the numbers are slightly off. It's that they're speaking a different language.
So you can't just copy the table over.
You can copy the bytes. They'll sit in the new database quite happily. They just won't mean anything to the new model. If you move from a hosted embedding model to a local one, or from one provider to another, you re-embed the entire corpus. Every document, every chunk, every conversation turn you ever stored.
And that's not a copy job, that's a compute job.
It's a batch job with a bill attached. And it gets worse at the storage layer, because vector dimensions vary by provider. Fifteen thirty-six is a common one. Seven sixty-eight is another. A table expecting seven sixty-eight dimensions will simply reject a fifteen thirty-six vector. It's not a soft failure where results get a bit worse. It's a hard incompatibility. The insert fails.
So the database schema itself is coupled to the embedding model.
Tightly. And nobody writes that down anywhere. It's implicit in the table definition, and it's invisible until the day you try to leave.
Let's walk through Daniel's actual scenario, because it's a good one. Agent built on Vercel, hosted vector database, working prototype. Now it needs to go to production in a different cloud, or it needs to become a local-only offline tool. Enumerate what breaks.
Everything, in sequence. The vector format breaks first, because you're re-embedding. The embedding model itself breaks, because even if you stay with the same provider, the model version may not be available in the new environment. API keys break, because they're scoped to the old provider's account and often to the old region. Network egress breaks, because a local-only tool by definition can't call out to a hosted embedding API, which means you now need a local embedding model, which means you're re-embedding anyway.
Cold-start behavior.
Cold-start behavior changes completely. On Vercel you're in a serverless world where the function spins up on demand and someone else worries about capacity. On a local machine the model has to be resident in memory, and if it isn't, the first query takes however long it takes to load several gigabytes off disk. That's a user experience that didn't exist before.
And the cost model inverts.
The cost model inverts entirely. On the hosted side you pay per token and per query, and the marginal cost of the hundredth user is nearly zero. Locally, the cost is all upfront, in hardware, and then it's free at the margin forever. Those are two completely different businesses wearing the same product.
So the prototype was never really the same thing as the production deployment.
It was the same source code. That's all it was. And that's the trap, because the source code is the part that looks portable, and it's the part that lies.
There's a distinction buried in Daniel's prompt that I want to pull out, because I think it's the sharpest thing in there. He separates vendor lock-in from infrastructural or technological lock-in.
And the second one is the one that should keep people up at night.
Vendor lock-in is the familiar kind. You can't leave a provider, usually because of contracts, pricing, or data gravity. It's a commercial relationship. It's annoying but it's legible. Everyone knows what it is.
Technological lock-in is subtler. You can leave the provider any time you like. Nothing is stopping you. It's just that the artifacts you built won't run anywhere else.
You have the freedom to leave and nothing to leave with.
That's the exact shape of it. And it's more dangerous precisely because it doesn't feel like a cage. There's no contract to renegotiate. There's no invoice that goes up. You just discover, on the day you actually try to move, that the thing you built is welded to the place you built it.
And the welding happened in a hundred small decisions that each seemed reasonable.
Every one of them. Using the provider's embedding model because it was one line of code. Letting the vector store be the system of record because it was convenient. Never exporting the raw conversation logs because why would you, they're already embedded.
Now, there is progress on the standards front, and I want to give credit where it's due.
MCP has won the tool-connection layer. That's real convergence, and a year or two ago it wasn't obvious that would happen. And A2A, Agent-to-Agent, has been picking up governance traction through this year as a complementary protocol for agents talking to other agents. Those two are starting to standardize the communication layer.
But neither of them touches memory.
Neither of them touches memory or state. You can have two agents that speak perfect MCP and perfect A2A and still have no way to hand one agent's memory to another. The protocols standardized how agents talk. They didn't standardize what agents remember or how they store it.
Which is precisely the gap Daniel's pointing at.
And it's an active research area now, not just a practitioner complaint. There's a paper on portable agent memory, the arXiv identifier is two six zero five point one one zero three two, that treats this as a first-class problem. The fact that it's showing up on arXiv rather than only in blog posts tells you the field has noticed.
So the communication layer is converging and the memory layer is still wild.
That's the state of play. And the memory layer is where the next wave of lock-in lives, because it's the part nobody has standardized and everybody has already built on.
So that's the diagnosis. Now let's talk about what a portability-first architecture actually looks like.
The organizing principle is one sentence. Keep memory as raw material, and treat the vector store as a derived index.
Unpack that.
The vector store is not the system of record. It's a cache. It's a fast lookup structure built from the raw material, and it can be thrown away and rebuilt at any time. The raw material is the asset. Conversation history, system prompts, the source documents that feed the vector store. Those live in plain, non-proprietary formats. JSONL for conversation logs. Markdown for prompts and documents. Parquet if you've got serious volume and want columnar storage.
And the test of whether you've done it right is simple.
Delete the entire vector database. Can you rebuild it from what's on disk? If yes, you're portable. If no, the vector store was the system of record and you didn't notice.
That's a useful test. You could run it tomorrow.
You could run it in an afternoon. And most people would fail it.
Daniel raises the objection himself, which I appreciate, because it's the first thing anyone says. Isn't storing the raw text alongside the embeddings just wasteful duplication?
It's the opposite of wasteful. It's the insurance policy. Yes, you're storing the same information twice, once as text and once as vectors. But the text is the thing that survives a model swap and the vectors are the thing that doesn't. You're not duplicating data. You're separating the durable asset from the disposable one.
And the cost of the duplication is trivial next to the cost of re-ingesting.
Text is cheap. A million words of conversation is a few megabytes. Vectors for the same corpus are larger than the text they came from, often substantially. So the raw material you're "duplicating" is the smaller half of the pair.
That reframes it completely. You're not paying a duplication tax. You're keeping the cheap copy and the expensive copy.
And when the model swap comes, and it will come, re-embedding is a batch job rather than a data-loss event. You run the script, you wait, you have a new index. Nothing is lost because nothing was only in the index.
Now the abstraction layers. What actually helps here?
Three things, and each one has a caveat. First, model-agnostic interfaces. Something like LiteLLM, where you write against one interface and route to whatever provider you want underneath. That helps for the chat completions layer.
Caveat?
The abstraction covers the common denominator. The moment you want a provider-specific feature, you're reaching through the abstraction, and now you've got provider-specific code anyway, just hidden one layer down where it's harder to find.
Second?
Embedding-provider abstractions. Same idea, applied to the embedding call. And the same caveat, only worse, because embeddings are where the semantic coupling lives. An abstraction that lets you swap embedding providers doesn't make the vectors compatible. It just makes the swap easier to trigger.
So the abstraction helps you move, but it doesn't help you arrive.
The abstraction makes the migration cheaper. It doesn't make it free, because you're still re-embedding.
Third?
MCP as a portable tool layer. And this one's the strongest of the three, because it's an actual protocol with actual buy-in rather than a library that wraps other libraries. If your tools are MCP servers, they come with you.
But MCP servers have their own dependencies.
They do. An MCP server that wraps a hosted service is still a hosted service. The protocol is portable. The thing behind the protocol might not be.
So every abstraction leaks, and each one adds a little lock-in of its own.
The abstraction layer is a dependency. It's a dependency you chose, which is better than one you fell into, but it's still something that can be abandoned, break, or change its license. There's no free portability. There's only chosen dependencies instead of accidental ones.
Let's take Daniel's composability question head-on. What would it actually take for agents to be swappable the way containers are?
Containers are the right comparison, and the reason is instructive. Docker didn't win because it was the best runtime. It won because it standardized the artifact. The image format. Once there was a standard thing you could build, ship, and run anywhere, the runtime became almost interchangeable and the ecosystem exploded.
The artifact came first.
The artifact came first, and the runtime followed. And agents have no equivalent standard artifact. There's no agent image. There's no file format you can hand someone that contains the model configuration, the prompts, the memory schema, the tool connections, and the orchestration logic in a way that any conforming runtime can execute.
So today, "moving an agent" means reading the source code and rebuilding it.
It means reading the source code, understanding what the original author assumed, and rebuilding those assumptions by hand in the new environment. Which is why it's a project and not a command.
What would the artifact even contain?
That's the hard design question, and I don't think anyone has a satisfying answer. It would need to declare the model requirements in a way that's portable, which is hard because models differ. It would need to declare the memory schema and the embedding requirements. It would need to declare the tool connections. And it would need to declare the orchestration logic in a form that isn't just "here's the Python."
The orchestration logic is the hard part.
It's the hardest part, because orchestration is where all the implicit assumptions live. The retry behavior, the fallback path when a tool fails, the decision about when to stop. That's the part that's bespoke, and it's the part that resists standardization.
If that artifact existed, what changes?
The market shifts. If agents become portable, the competition moves from platforms to components. You'd pick your model on merit, your memory store on merit, your orchestration on merit, and swap any of them without a migration project. That's wonderful for builders.
And bad for anyone whose moat is switching cost.
Bad for exactly those platforms. If your product is good, portability doesn't hurt you, because people stay for the product. If your product is mediocre and people stay because leaving is expensive, portability is an existential threat. Which tells you something about which platforms will resist the standard and which will embrace it.
The ones confident in their product will publish the export format themselves.
They should, and some do. The ones who won't are telling you something.
Let's get concrete about the stack, because Daniel asked for practical. If someone's starting today with portability as a requirement, what's actually in the box?
Raw conversation logs in JSONL, one line per event, append-only, on storage you control. Prompts and source documents as Markdown files in a git repository, so they're versioned and diffable and reviewable like code.
Source documents as Markdown rather than PDFs?
Markdown for anything you author. PDFs for anything you receive, but keep the original PDFs, don't shred them into chunks and throw away the source. The chunks are derived. The PDF is the asset.
Then the vector index.
The vector index is a build artifact. You should be able to delete it and regenerate it with a script, the same way you'd regenerate a compiled binary. It lives in whatever store you like, and you should be able to point that store at a different backend with a configuration change.
Tools over MCP.
Tools over MCP, so the tool layer is protocol-shaped rather than vendor-shaped. And a model-router abstraction so the chat completions call isn't hardwired to one provider.
And the discipline that holds it together.
The discipline is the part that doesn't show up in the architecture diagram. It's refusing to let the vector store become the system of record. It's exporting the raw logs even though they're already embedded. It's writing the rebuild script on day one rather than day four hundred.
Because the rebuild script is the proof.
The rebuild script is the proof that you actually did it. If you can't point to the script that regenerates your index from raw material, you have portability as an aspiration, not as a property.
And the cost of all this is what? A little duplication and a lot of discipline.
That's the honest accounting. You store the raw text and the vectors, so you're using somewhat more storage than you strictly need. And you spend real effort keeping the raw material clean and the rebuild path working. In exchange, you never have a migration project. You have a rebuild job and a config change.
Which is the difference between a weekend and a quarter.
It's exactly that difference. And the cruel part is that the decision is made at the very beginning, when you have the least information and the most pressure to just ship something.
So the practical advice is to pay the small tax early.
Pay the small tax early, because the large tax arrives later and you don't get to choose when.
There's a knock-on effect here I want to get to, which is what portability does to the vendor landscape.
It's the same story as every infrastructure market. When the artifact is portable, vendors compete on the quality of the thing rather than the cost of leaving. That's a better market for everyone except the incumbents who were winning on switching cost.
And it tends to happen suddenly.
It happens suddenly because the standard is worthless until it's universal. Nobody wants to be the only one publishing an agent artifact format. Then one major player does it, everyone else has to follow, and within a year it's just how things work. That's how container images went. That's probably how agent artifacts will go, if they go at all.
The governance angle matters here too.
It does. MCP and A2A are getting real governance attention this year, which means the communication layer is on a path to being properly standardized with actual stewardship. The memory and state layer has no equivalent effort that I'm aware of, at least not one with the same institutional weight.
So the gap is narrowing at the edges and staying wide in the middle.
The edges are converging and the middle is where the lock-in lives. That's where the next wave of tooling will be built, and it's where the next wave of lock-in will be sold.
The paper on portable agent memory is a signal that the middle is being worked on.
It's an early signal. One paper isn't a standard. But it's the kind of thing that precedes a standard, and it's worth watching.
Alright. I want to push on one thing before we get to Hilbert, because I think there's a trap in the portability argument that Daniel's prompt doesn't quite name.
Go on.
The trap is that portability can become its own kind of debt. If you spend all your effort keeping every door open, you never walk through any of them. You end up with an agent that runs everywhere and excels nowhere, because you never used the features that made any single environment good.
That's a real risk, and I think the resolution is to be deliberate about which couplings you accept. You accept coupling to your model, because you have to pick one. You refuse coupling to your vector store's format, because that's the one that costs the most to undo.
So it's not "avoid all lock-in." It's "choose your lock-in on purpose."
Choose it on purpose, and write down why. The couplings you chose are fine. The couplings you fell into are the ones that bite.
Which is a much more honest framing than the usual "just use open standards" advice.
"Just use open standards" is advice that sounds free and isn't. Every standard is a dependency. The question is whether it's one you'd choose again.
There's something I keep circling back to, which is that the raw material argument is really an argument about what counts as the asset.
Say more.
People treat the vector store as the asset because it's the expensive thing to build. But expensive to build isn't the same as valuable to keep. The vectors are expensive because you paid a model to produce them. The text is valuable because it's the thing you can always re-derive from.
The expensive thing and the valuable thing are different things, and the accounting makes you think they're the same.
Which is exactly how people end up deleting the raw logs after embedding them. The logs look like the redundant copy.
They look redundant right up until the day the embedding model is deprecated and you need them back. And by then they're gone, because someone cleaned up storage six months ago.
That's the whole failure mode in one sentence. You delete the cheap thing and keep the expensive thing, and then the expensive thing becomes worthless.
The expensive thing is worthless without the cheap thing. It's a derived artifact. It's a cache. And caches get invalidated.
And the invalidation event is a model deprecation, which is not a rare event.
It's a routine event. Embedding models get retired. Providers change their default. Versions get pinned and then unpinned. If your only copy of the corpus is in vector form, every one of those events is a crisis.
And if you kept the raw material, every one of those events is a Tuesday.
Every one of them. You run the rebuild script, you go get coffee, you come back and you have a new index.
You know what this reminds me of? The mobile phone number portability fights in the nineties and two thousands. Carriers resisted it for years because the number was the lock-in. Once portability was mandated, the number stopped being the moat and the network quality started to matter.
And the carriers who'd been coasting on switching cost had a very bad decade.
They had a terrible decade. And the ones who'd invested in the actual network did fine.
There's a version of this for agents where the memory store is the phone number.
The memory store is the phone number. It's the thing that makes leaving expensive, and it's the thing that has no business being proprietary.
The raw material is the number. It should be portable by right.
And the platform that offers to export it is the platform confident in what it's actually selling.
There's a practical wrinkle here, which is that the raw material itself isn't quite enough. You need the raw material plus the recipe.
The recipe being what?
The chunking strategy. The metadata schema. The way you split a document into pieces, the fields you attach to each piece, the filters you apply at query time. If you keep the raw text and lose the recipe, you can re-embed, but you'll get different results because you chunked differently.
That's a good point and it's the part people miss. The raw material is necessary but not sufficient. You need the processing recipe too, and the recipe is usually implicit in the code.
So the recipe needs to be an artifact too.
The recipe needs to be written down somewhere that isn't just the ingestion script. A config file, a schema document, something that travels with the data. Otherwise you've kept the flour and lost the recipe, and you can't bake the same bread.
Which is a nice place to hand over, because I think our producer has been sitting on something.
Hilbert: You shred the paper.
Sorry?
Hilbert: That's what they did. Insurance company, mid-sized, I did six months there. They were migrating the document management system off one vendor onto another, and the whole thing stalled for about five weeks. Not because of the software. Because the old system stored every scanned document as an IDF file, which only the original vendor's viewer could open, and the vendor had gone under. And the paper had been shredded. Years earlier. To save storage space.
The only copy of the documents was in a format nothing could read.
Hilbert: The only copy was in a format that needed a program that no longer existed. We had the microfilm, which nobody had looked at in a decade, and we had to re-scan everything off it. Six people, five weeks, one of those flatbed scanners that jammed every forty pages.
The microfilm was the raw material.
Hilbert: The microfilm was the raw material. But here's the thing I actually came out to say. The microfilm wasn't enough.
How so?
Hilbert: Because we'd lost the indexing rules. The old system had a metadata schema, and it was implicit in how the files were named and how the folders were nested, and once the system was gone nobody could reconstruct it from memory. So we had the documents, and we could scan them, and we had nowhere to put the metadata, because we didn't know what the fields were supposed to be. We spent two of those five weeks rebuilding the schema by hand, from the paper itself, guessing at what the old system had known.
You had the raw material and you'd lost the recipe.
Hilbert: We had the flour and no idea what the bread was supposed to look like. And the lesson I took from it wasn't keep the paper. Everyone says keep the paper. It was keep the rules about the paper. The paper's useless if you can't file it.
That's the chunking strategy and the metadata schema.
Hilbert: I don't know what those words mean, but if they're the rules about how the documents get filed, then yes. That's what we lost. And it cost us two weeks we didn't have, on a contract that was already late.
The raw material and the recipe, both as artifacts.
Hilbert: Both. And the recipe is the one people forget, because the recipe is invisible while the system's running. You don't notice it until you turn the system off and the recipe turns out to have only existed inside it.
Which is the same mistake as deleting the raw logs after embedding them.
Hilbert: It's the same mistake at a different layer. You keep the thing you can see and throw away the thing that gives it meaning. And then you find out which one you needed.
The paper had been shredded to save storage.
Hilbert: To save storage. Which is the funniest part, in retrospect, because storage was cheap by then. Someone made a decision in a budget meeting in about nineteen ninety-four and it cost us five weeks in twenty nineteen. Anyway. That's what I had.
Portability isn't a feature you add later. It's an architectural stance you take at the first commit.
The whole thing turns on one decision, made once, at the beginning, when you're least equipped to make it. Do you keep the raw material and the recipe, or do you let the derived index become the only copy?
Keep both, and keep them somewhere you control, in formats that don't need anyone's permission to read.
The cost is a little duplication and a lot of discipline. The alternative is finding out, five years from now, that the only copy of something you care about is in a format that needs a program that no longer exists.
Which is a thing that has already happened, repeatedly, to people who were sure it wouldn't.
There's an open question I want to leave people with, which is whether agents ever get their Docker moment. A standardized artifact format that makes them portable, the way container images did for software.
The communication layer is standardizing. MCP and A2A are getting real governance attention, and that's good news. The memory and state layer is still wild, and that's where the next wave of lock-in lives. Whether someone builds the agent image format, or whether portability stays a discipline each builder practices by hand, is open.
Which means the answer, for now, is that you practice it yourself. Nobody's going to hand you portability. You either build it in from the first commit or you pay for it later.
The payment is always larger than the premium would have been.
Thanks to Hilbert Flumingtop, our producer, for that one. This has been My Weird Prompts.
If you're building agents and thinking about portability, we'd like to hear what's working. Reviews help other people find the show, so if you've got a minute, that's the thing.
We'll be back soon.
See you then.
