The four layers, and what you mortgage in each
The question almost everyone shows up with is which of the platforms for building AI agents is the best one. It has no answer, because there is no list of products: there are four layers, and picking the layer decides far more than picking a brand inside it. Top to bottom: the vendor assistant you already pay for, the no-code builder, the code framework, and your own code against the API. The higher up you go, the sooner you have something running and the less control you have over what happens next.
| Layer | What it is | Live examples | What you mortgage |
|---|---|---|---|
| 1 · Vendor assistant | The agent lives inside a product you already pay for | ChatGPT and its GPTs, Microsoft Copilot Studio, Google Gemini Enterprise, Claude | Portability: you leave with whatever the vendor decided to let you export |
| 2 · No-code builder | Visual canvas, connectors ready to go, hosted execution | n8n, Make, Zapier Agents, Relevance AI | The history and the connections. The flow usually comes out; the rest depends on the plan |
| 3 · Code framework | A library in your repository; you run it yourself | LangGraph, CrewAI, OpenAI Agents SDK, Google ADK, Microsoft Agent Framework, Pydantic AI | Nothing on the licence: they are all MIT or Apache 2.0. You mortgage the team |
| 4 · Your own code | The model's API plus your integrations | Any stack + MCP | Time. The most expensive to start and the cheapest to walk away from |
The rule that orders that table isn't technical. It's that layers 1 and 2 sell you speed today in exchange for an exit cost that appears on no pricing page. And that cost only comes due once it's late: month 7, when the agent is doing something that matters and the person who built it is long gone.
Proof that layer 1 expires: Agent Builder lasted thirteen months
This is not a consultant's warning. OpenAI launched Agent Builder, its visual canvas for assembling agents, in October 2025. On 3 June 2026 it announced the deprecation and set the shutdown for 30 November 2026. Today its own documentation files it under "Legacy APIs", next to the Assistants API, and ships a migration guide. Thirteen months of shelf life for what was, for a year, "OpenAI's agent platform". Source: Agent Builder, OpenAI documentation, accessed 7 September 2026.
The three exit questions
Before you look at a single feature there are three questions whose answers already sit in the vendor's public documentation, and they decide what leaving costs. They take twenty minutes, they don't depend on the demo, and nobody has to answer them for you over the phone.
Can I take the prompt with me?
In ChatGPT, not entirely. OpenAI documents that uploading exported conversations to another account does not transfer "custom instructions, memories, GPTs, or other account settings". Translated: the conversation history comes out, but the GPT definition — the instructions that took weeks to sharpen — is not in the export. And there is a second edge: self-service export is not available in Business and Enterprise workspaces, which are exactly the ones a company buys; there you go through the workspace owner. Sources: Transfer exported conversations between ChatGPT accounts and Exporting your ChatGPT history and data, OpenAI Help Center, accessed 7 September 2026.
At the other end of the same layer sits Copilot Studio. An agent lives inside a Power Platform solution, and solutions export and import as ZIP files between environments; with the CLI (pac copilot clone / pull / push / pack) you can have it as files on disk and put it in git. With one caveat worth saying out loud: that is portability inside Power Platform, not out of it. And it comes with a documented trap — agents are created by default in the default solution, and from there they cannot be exported; you have to create a custom solution on purpose. Sources: Solutions overview (29 April 2026) and pac copilot (10 July 2026), Microsoft Learn.
Can I take the history with me?
This is where layer 2 shows the seam, and the honest answer is almost always "some of it, for a while". Zapier guarantees a maximum of 60 days of run history and displays up to 10,000 entries. Make archives blueprint versions as soon as they pass 60 days. n8n hands it over through its public API and, if you host it yourself, you decide the retention. Sources: View and manage your Zap history, Zapier Help; Scenario blueprints, Make Developer Hub; Execution API, n8n Docs. Accessed 7 September 2026.
Why the history matters isn't obvious until the day you need it. It's what you use to understand why the agent did that thing back in March, to build the next agent on what the last one already learned, and to answer an audit without making things up. An agent with no exportable history is an agent you can't build on next year.
Can I take the integrations with me?
The short answer is that the flow exports and the connections do not. Make documents it without hedging: on importing a blueprint, the user has to recreate the connections to their own accounts. And in Zapier, exporting your own workflows is flatly a paid feature — available on Team and Enterprise, and not on Free or Professional. Sources: Blueprints, Make Help Center; Import and export Zap workflows, Zapier Help. Accessed 7 September 2026.
Who runs this in month 7
This is the criterion that actually decides, and the one nobody looks at during the demo: who is going to be sitting in front of this seven months from now. Not who builds it. Who maintains it when the model changes, when the vendor deprecates something, and when the process stops being what it was.
A concrete example, with the product's own documentation in hand. n8n has three project roles — Admin, Editor and Viewer — but Editor requires the Cloud Pro plan and Viewer requires Enterprise. On the entry plan, therefore, the only project role available is Project Admin: everyone who joins the project can delete everything. n8n also warns that there is no way to see who created a given workflow, and recommends the owner create a second account with the Member role for day-to-day work. That isn't a hidden defect: it's written in their documentation, and almost nobody reads it before signing up. Sources: Available roles and Instance roles, n8n Docs, accessed 7 September 2026.
Microsoft reaches the same conclusion from the other side. Its architecture guidance for AI workloads recommends starting with between 5 and 10 distinct personas to split up access, and justifies it with a sentence that sums up the whole problem: unlike traditional systems, where you know exactly which services will be called and in what order, agentic systems make decisions on their own at runtime. Hence the need for just-in-time permissions and traces that connect the autonomous decision back to the person accountable for it. Source: AI workload personas, Azure Well-Architected Framework, 1 April 2026.
That part — its own identity, scope by task, tested revocation — gets decided before you pick a platform, and it is worked out in full in what permissions to give an AI agent. If the agent you have in your head is going to touch systems belonging to several teams, that is the right order: access first, canvas second.
MCP standardises the connector, not the identity
The argument you hear most often for playing down lock-in is MCP: if everything speaks the same protocol, switching platforms is unplug and plug back in. It is half true, and the missing half is the one that costs money.
What is true: MCP stopped belonging to one vendor. In December 2025 Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation, with AWS, Google, Microsoft and OpenAI among its platinum members. All four of the big ones expose their services over MCP today and each announced it separately. Source: MCP joins the Agentic AI Foundation, official MCP blog, 9 December 2025.
What is not: authorization is optional in the spec itself, and the details of the authorization server are explicitly out of its scope; every server defines its own scopes. The most honest proof came from AWS on its own blog when it announced general availability of its MCP server: to use its local AWS credentials over MCP, which only supports OAuth 2.1, it configured the agent to call the server through a proxy. The largest cloud in the world needs a middleman for its own identity model to speak the protocol. Source: The AWS MCP Server is now generally available, AWS News Blog, 6 May 2026.
And the protocol breaks backwards too: the 28 July 2026 revision removed the initialize/initialized exchange and the Mcp-Session-Id header, deprecated the legacy HTTP+SSE transport, and the announcement itself acknowledges there will be a migration cost for anyone who depended on session identifiers. MCP lowers the cost of integrations. It does not take it to zero, and it does not touch the cost of identity. Source: Spec update 2026-07-28, official MCP blog.
The fine print on "open source"
If the conversation gets to self-hosting, read the licence and not the slogan. n8n is not open source in the OSI sense: its licence is the Sustainable Use License v1.0, which allows using and modifying the software only for internal business purposes or personal, non-commercial use, and distributing it only free of charge and for non-commercial purposes. On top of that, files with .ee in the name or the directory fall outside that licence and require the Enterprise one, and the contents of branches other than master are flatly unlicensed. Source: LICENSE.md, n8n repository, accessed 7 September 2026.
For a company automating its own operation that is covered and there is no drama. For an agency running n8n for its clients, or for anyone planning to resell access, it is not: that is the moment to read the Enterprise licence instead of assuming. n8n itself calls its model "fair-code" and not "open source", and it does so for exactly this reason.
Layer 3 doesn't have this conversation. LangGraph, CrewAI, OpenAI's Agents SDK, Microsoft Agent Framework and Pydantic AI are MIT; Google's ADK is Apache 2.0. There the exit cost isn't the licence: it's the team. Which is exactly the criterion from the previous section, again.
How to choose in one afternoon
- Write the agent's sentence: what it does, over which systems, and who finds out when it fails. If it doesn't fit in one sentence, don't pick a platform yet — pick a process.
- Put a first and last name on whoever runs it in month 7. If that person cannot read code, layer 3 is not an option no matter how clean its licence is.
- Answer the three exit questions using the candidate's public documentation, not their sales rep: prompt, history, integrations.
- Check the roles on the plan you're actually going to buy, not the ones on the enterprise plan in the comparison table. If everyone on your plan is an admin, you already know what happens the day somebody slips.
- Export on day one, not on the day you need it. The day the thing works, pull the export and file it wherever you file everything else.
None of the five steps is about features, and that's the point. The features of an agent platform look more like each other every six months; what doesn't converge is who can run it and what they let you take with you. Choosing on the first is choosing on what is going to change. Choosing on the second is choosing on what is going to hold you back.
We build the part that decides all of this: the infrastructure the agent runs on, with its own identity, export from day one and a named person operating it — the enterprise AI infrastructure that holds up any agent that actually works. And if what's in front of you is still the previous decision, buy or build, that one is settled in buying AI agents or building them. We don't sell a platform. We charge for the one you pick not locking you in.