Daniel's been thinking about the guts of how this podcast gets made — specifically, the agentic pipeline that builds each episode. It's defined in Python, uses LangChain, runs on Modal. But he's looking at the landscape and asking whether he's painted himself into a corner. He's got four questions for us. One, how portable are workflows between code-defined frameworks like LangChain, CrewAI, and AutoGen? Two, can you move between code frameworks and visual builders like Dify or Coze? Three, what breaks when you switch languages — Python to TypeScript, say? And four, how do you avoid racking up technical debt to a single framework? So let's start with the obvious — how portable are these things really?
Not very. And the reason isn't what most people assume. The instinct is to say, well, they all call the same LLM APIs, they all use tools, they all have some kind of orchestration — surely there's a common substrate. But the orchestration layer is where they diverge, and it diverges hard.
So it's not the LLM calls. It's everything around the LLM calls.
No, wait, I just agreed with my own point. Let me try that again.
That was beautiful. Keep going.
The landscape splits into two broad camps. On one side you've got code-defined frameworks — LangChain with LangGraph, CrewAI, AutoGen, Microsoft's Semantic Kernel. On the other, visual and low-code builders — Dify, Coze, Flowise, n8n. The code frameworks give you maximum flexibility. You define the control flow, the state, the error handling. But that flexibility creates what I'd call implicit dependencies on their abstractions. Tool schemas, memory patterns, graph topologies — every framework does these its own way. The visual builders go the opposite direction. Drag and drop, configure nodes, hit deploy. But when you export, you get a JSON or YAML file that encodes that platform's specific node types, routing logic, variable scoping. It's not a standard format. It's a proprietary snapshot.
So you're saying visual builders give you the illusion of portability because you can export a file, but it's a file only that platform can read.
That's it. The JSON looks reassuring — it's text, it's structured, surely someone else can parse it. But Dify's workflow export has node types like "llm", "code", "knowledge_retrieval", "condition" — those map loosely to concepts in LangGraph, but the routing logic, the way variables flow between nodes, the error handling semantics — those are all Dify-specific. You can't drop that JSON into Coze or Flowise and expect it to run. You can't even use it as a specification to rebuild in LangGraph without essentially reverse-engineering the intended behavior.
Alright, so let's dig into the code-to-code question first. LangGraph to CrewAI. What actually breaks?
The graph abstraction. This is the thing that doesn't get enough attention. LangGraph models agent workflows as state machines — nodes and edges, conditional routing, parallel branches. You define a graph, you define a state object that flows through it, and each node reads from and writes to that state. CrewAI uses a completely different mental model. It's hierarchical — you define agents with roles and goals and backstories, you assign them tasks, and the framework handles delegation. An agent can hand off to another agent, but the control flow is emergent from the role definitions, not explicitly graphed.
So if I've got a research agent pipeline in LangGraph — search the web, summarize findings, write a report — and I want to move it to CrewAI, I can't just translate the nodes.
You can't. In LangGraph, that pipeline is a directed graph. You've got a search node, a summarize node, a write node. You've probably got conditional edges — if the search returns nothing useful, retry with a different query, or fall back to a different source. In CrewAI, you'd define a ResearchAgent and a WriterAgent, give them roles and goals, and set up a task handoff. But the retry logic, the conditional branching — that's not something CrewAI's role model expresses naturally. You'd have to embed it in the agent's instructions or build it into custom tool logic. The architecture is fundamentally different. It's not a port. It's a rewrite.
And AutoGen?
AutoGen is yet another paradigm. It's conversational agent groups. You spin up agents that talk to each other, and the orchestration emerges from their conversation, with termination conditions that decide when the group is done. So that same research pipeline becomes a conversation between a Searcher agent, a Summarizer agent, and a Writer agent, with a group chat manager routing messages. The control flow isn't a graph and it isn't hierarchical delegation — it's a multi-agent dialogue. Three frameworks, three completely different orchestration philosophies. The LLM calls underneath look similar — they all send prompts to an API — but the structure that decides which call happens when and with what context is not portable at all.
So the misconception is "they all use the same LLM APIs, therefore they're interchangeable."
And it's a costly misconception. Because it's not just the graph topology that's different. It's the tool interface. LangChain has BaseTool with an args_schema defined as a Pydantic model. CrewAI has its own tool schema. AutoGen registers functions differently. The error handling is framework-specific. The retry logic. The state persistence — how you checkpoint and resume a workflow. All of these are implementation details that your pipeline comes to depend on, and none of them translate.
So the bright side is... what, exactly?
There's actually something worth watching. Earlier this year — mid twenty twenty-six — a specification called SKILL.md started circulating, alongside something called the Agent Interaction Protocol, or AIP. The idea is to define portable agent skill definitions. A SKILL.md file describes what an agent skill does, what inputs it takes, what outputs it produces, in a framework-agnostic way. The AIP layer handles how agents discover and invoke each other's skills. It's early. Very early. Adoption is limited to a handful of projects. But it's the first serious attempt at a common interchange format for agent capabilities, and if it gains traction, it could change the portability equation entirely.
I'll believe it when I see a production pipeline migrated on it.
Fair. But the fact that someone's trying is worth noting, because the alternative is — well, it's what we've got now, which is every framework as its own island.
So that's the picture within code frameworks. What about moving between a code framework and a visual builder? Daniel mentioned Dify and Coze specifically.
The chasm is even wider. Visual builders don't just abstract the orchestration — they often bundle infrastructure. Dify gives you a built-in vector store for knowledge retrieval, a conversation memory backend, model routing. You drag in a knowledge retrieval node, point it at a document, and it just works. In LangGraph, you're provisioning your own vector database, managing embeddings, writing the retrieval logic. If you've built a Dify workflow that leans on those built-in services, exporting it to LangGraph means rebuilding those services from scratch. The visual abstraction hides complexity, but it also hides dependencies. You don't realize how much of your pipeline is platform-specific until you try to leave.
And the export format doesn't capture those dependencies?
It captures references to them. The JSON says "use knowledge base K" — but it doesn't include the knowledge base. It says "use the conversation memory" — but that's a Dify service. The export is a map of a house that assumes the plumbing and electricity are provided by the landlord. Move to a different landlord, and you're digging trenches.
So the visual builder's promise — "no code, fast to build, easy to change" — comes with a silent asterisk. Fast to build, slow to leave.
That's the trade. And to be clear, that's not necessarily a bad trade for everyone. If you're prototyping, or you're building something that doesn't need to outlive the platform, visual builders are useful. The problem is when you don't realize you're making the trade. You build something that works, it becomes critical, and then you discover the exit door is a lot heavier than you thought.
Alright, let's make it even harder. What if you're moving between languages? Python to TypeScript.
This is the part that surprises people. You'd think that LangChain Python and LangChain.js would be close cousins — same framework, same conceptual model, just different syntax. And at a high level, they are. But the implementations have diverged. LangChain.js has different tool abstractions — the way you define a tool and its schema isn't a direct translation. The callback system is different. The async patterns are different — Python's asyncio versus JavaScript's event loop. These aren't cosmetic differences. They affect how you structure your pipeline, how you handle streaming, how you manage concurrency.
So even staying within the same framework family, switching languages is a meaningful migration.
It is. And if you're moving between different frameworks in different languages — say, LangGraph in Python to Semantic Kernel in C-sharp — you're now dealing with two layers of divergence. Semantic Kernel is Microsoft's entry, and it's C-sharp-first with Python and Java ports. Its core abstraction is the planner — the component that decides how to compose skills to achieve a goal. That planner model doesn't map cleanly to LangChain's chain and agent model, or to LangGraph's state machine. Different orchestration philosophy, different language idioms, different ecosystem. That's not a port. That's a greenfield project that happens to solve the same problem.
So let's pull on the thread Daniel's really asking about. Technical debt. What does framework lock-in actually cost, in practical terms?
Three dimensions. First, migration cost. LangChain went from zero-point-one to zero-point-two to zero-point-three with breaking changes between each. Teams that built deeply on its abstractions had to rewrite significant portions of their pipelines. If you're a startup and your product depends on an agentic workflow, that kind of churn is existential. You're not building features — you're keeping up with the framework.
And that's the most popular framework in the space.
Right. Popularity doesn't guarantee stability. It can mean the opposite — rapid iteration, lots of contributors, lots of surface area changing fast. The second dimension is skill cost. Your team builds expertise in LangGraph's state machine model, or CrewAI's role-based delegation. That expertise is real and hard-won. But if you switch frameworks, a lot of it doesn't transfer. The concepts transfer — you still understand agents and tools and memory — but the specifics of how to debug a graph execution, how to optimize state persistence, how to handle edge cases in the routing logic — that's framework-specific and it evaporates.
And the third?
Ecosystem cost. Integrations and tools that only work within one framework. LangChain has a huge ecosystem of integrations — vector stores, document loaders, tool connectors. CrewAI has its own, smaller but growing. AutoGen has Microsoft's ecosystem behind it. If you've built your pipeline around LangChain's specific integrations and then you move, you're either finding equivalents, building your own, or doing without.
So what does a builder actually do about this? Daniel's asking what to know in advance.
The most practical advice I've seen — and this comes from teams that have been through the migration pain — is to abstract your agent logic behind a thin interface layer. Even if it's just a Python protocol class. Define what your agents do in terms of your own domain, not the framework's. An agent takes a task definition and returns a result. The framework is an implementation detail behind that interface.
So you're not writing LangGraph code. You're writing your pipeline's logic, and LangGraph happens to be how you execute it today.
That's the idea. It's not free — you're adding a layer of indirection, and you have to be disciplined about not letting framework concepts leak through the interface. But the alternative is having LangGraph state objects, CrewAI role definitions, or AutoGen group chat configurations woven through your entire codebase. At that point, migration is surgery.
And for visual builders?
Harder to abstract, honestly. If you're using Dify's built-in knowledge base and conversation memory, those are platform services, not just orchestration. The abstraction layer would need to sit above those services — define what retrieval and memory mean for your pipeline, and treat Dify as one possible provider. But at that point you're building an abstraction that may be more complex than just using a code framework directly. The visual builder's convenience is tightly coupled to its platform.
The fork in the road Daniel's describing — code versus visual — is also a fork in how much lock-in you're signing up for.
It is. And I want to be careful here, because I'm not saying visual builders are bad. They're useful for rapid prototyping, for non-developer teams, for workflows that don't need to be portable. The mistake is assuming they're a shortcut to portability because they export JSON. They're not. They're a shortcut to a working pipeline, with portability as the cost.
The JSON is a receipt, not a passport.
That's... actually perfect. The JSON is a receipt. It tells you what you built, but it doesn't get you into another country.
Where does this leave someone building a pipeline today? Let's pull together what we've learned. Within code frameworks, portability is poor — different orchestration paradigms, different tool interfaces, different state management. Between code and visual, it's worse — platform services and proprietary export formats. Across languages, even within the same framework family, the implementations diverge enough to make migration non-trivial. The one glimmer is AIP and SKILL.md, but they're early and unproven.
The practical takeaway is that thin interface layer. Define your pipeline in your own terms, and treat the framework as pluggable.
Right. It won't save you from all migration pain — the framework-specific code still has to be written and rewritten. But it contains the damage. Instead of your entire codebase being a LangGraph application, you've got a core pipeline with a LangGraph-shaped adapter on one side. When you switch, you write a new adapter.
The other thing I'd add — and this is less technical, more strategic — is to be honest about whether you actually need portability. If you're a solo developer, or a small team, and the framework you've chosen works, and you're shipping, the cost of building an abstraction layer might exceed the cost of just... staying put. Not every pipeline needs to be framework-agnostic.
That's a fair counterpoint. The abstraction layer is insurance. Insurance is worth buying when the thing you're insuring against would be catastrophic. If a framework migration would be annoying but manageable — a few weeks of work — maybe you don't need the insurance. If it would kill your product, you do.
The framework's track record matters. LangChain's version churn is a warning sign. A framework that's been stable for two years is a different risk profile than one that's breaking APIs every six months.
Though stability can also mean stagnation. The agentic AI space is moving fast. A framework that hasn't changed in two years might be stable because it's been left behind.
You're choosing between churn risk and obsolescence risk.
Welcome to software engineering in twenty twenty-six.
Hilbert: Informatica PowerCenter. Nineteen ninety-seven through two thousand. Three years building ETL pipelines with drag-and-drop. Looked just like your visual builders today. Boxes and arrows on a canvas. Every migration to a new version was a complete rebuild. The proprietary transformation logic was baked into the visual workflow, and when the platform changed, none of it came with you.
ETL — extract, transform, load. Data integration pipelines.
Hilbert: Same problem, different decade. Every generation invents a new visual abstraction, promises portability, and then locks you in. BPM engines did it. Workflow automation platforms did it. Now it's agentic AI builders. The difference now — and this is the part you didn't say — is that you've got framework lock-in stacked on model lock-in stacked on platform lock-in. The LLM calls have their own lock-in. Model-specific prompt formats, tool-use schemas, output parsers. Switch from one model provider to another and your carefully tuned prompts might stop working. Switch frameworks and your graph topology is gone. Switch platforms and your vector store and memory backend vanish. It's not one lock. It's three.
Stacked lock-in. That's the phrase. And you're right — we talked about the framework layer and the platform layer, but the model layer is its own dependency. A pipeline built around a specific model's tool-calling format, or its particular way of handling system prompts, or its output structure — that pipeline has model debt on top of framework debt.
Hilbert: The ETL guys learned this the hard way. The survivors abstracted the transformation logic out of the visual tool. Kept it in plain SQL or scripts that could run anywhere. The visual layer was just the trigger. The agentic equivalent would be keeping your core agent logic in plain functions — the prompt assembly, the tool routing, the output parsing — and letting the framework handle only the execution plumbing.
The thin interface layer Herman was describing, but pushed even further down. The framework doesn't own your logic. It just runs it.
Hilbert: That's what we should have done in ninety-seven. We didn't. Three years of pipelines, all of them trapped in Informatica's proprietary format. When the company switched to a different ETL tool in two thousand one, they had to rebuild everything. I spent six months reimplementing pipelines I'd already built. Same logic, different boxes.
That's the migration cost I was talking about, but at enterprise scale. And the thing that strikes me is — the agentic AI community is repeating this pattern almost exactly. The visual builders look different, the technology underneath is different, but the lock-in mechanism is the same. Proprietary node types, proprietary service dependencies, proprietary export formats.
The model layer makes it worse, because the ETL tools didn't have an equivalent. Your transformation logic didn't change behavior because the database vendor updated their query planner. But an LLM update can subtly change how your agent interprets instructions, and you might not notice until the pipeline starts producing different outputs.
Hilbert: The model's a moving part you don't control. That's new.
It is. And it means the abstraction layer has to account for model behavior drift, not just framework changes. That's a harder problem.
Hilbert: The AIP thing you mentioned. I'll believe it when I see a production pipeline migrated on it. Standards bodies have been trying to solve this for thirty years. Some of them succeed. Most of them produce documents that sit on a shelf.
What's the thing you'd tell someone starting a pipeline today?
Hilbert: Write your logic in plain code. Keep it separate. The framework is a runner, not a home. And don't trust anyone who says their export format is portable. Ask them to show you a pipeline migrated to a competitor. If they can't show you that, it's not portable.
That's a good litmus test. If the vendor can't demonstrate a migration to a competing platform, the export format is a lock-in mechanism dressed as a feature.
Where does this leave the portability question? Not resolved, certainly. The next twelve to eighteen months are going to be interesting. Either we see consolidation around one or two dominant frameworks — LangGraph and maybe one visual builder — which makes portability less urgent because most people are already on the standard. Or we see continued fragmentation, which makes the abstraction layer approach essential.
The AIP and SKILL.md effort could tip that balance. If it gains real adoption — if you can define an agent skill once and deploy it across LangGraph, CrewAI, and Dify — that changes the economics of framework choice entirely. But we're not there yet, and betting on a standard that's six months old is... optimistic.
The ETL pattern Hilbert described suggests the optimistic outcome is not the one to bet on. But the thin interface layer is cheap to build today, and it pays off in either scenario. If the ecosystem consolidates, you've wasted a small amount of effort. If it fragments further, you've saved yourself a rewrite.
That's the right way to frame it. Cheap insurance, asymmetric payoff.
Thanks to our producer Hilbert Flumingtop for keeping us honest — and for the ETL scars.
This has been My Weird Prompts. If you're building agentic pipelines and you've got a migration story — or a lock-in horror story — we'd love to hear it. Send it to show at my weird prompts dot com.
We'll be back soon.
