Every AI agent platform on your shortlist will one day stop being the thing its vendor is excited about. Plan for that, not against it.
Choose an AI agent platform by asking what happens when the vendor stops investing in it, because that is the outcome you should expect. In 2026 both of the largest vendors retired their flagship agent product without switching anything off. AWS closed Amazon Bedrock Agents Classic to new customers on July 30, 2026 and froze its model catalogue on the same date. OpenAI removes the Assistants API on August 26, 2026, a year after it gave notice. Neither event is an outage, which is why most teams will not notice, and the cost of both lands on whichever layer of your build holds your tool definitions and your conversation state.
I build automation and agent systems for a living, 500+ projects across 30 countries, and the rebuild calls I take are almost never about a model getting worse. They are about a platform quietly stopping.
A platform does not have to shut down to cost you a rebuild. It only has to stop moving while everything around it keeps going.
The mistake: comparing the layer that is cheapest to replace
The evaluation always looks the same. Someone runs the three hardest tickets through three platforms, watches which one handles the messy one, and declares a winner. That is a fine way to choose, except it measures the model and the orchestration prompt, and those are the two things you can change in an afternoon.
An agent is four separable layers: the model, the loop that decides what to call next, the tool definitions that connect it to your actual business, and the memory that remembers who the customer is. Nobody ever migrates because the model got worse. They migrate because the platform stopped shipping, and then find that the expensive part is that layers three and four were written in a shape only that platform reads.
You do not have to take my word for which parts hurt. AWS published its own comparison of what does and does not carry across when you leave Bedrock Agents Classic. Stage specific prompt overrides are "not directly replicated". Routing mode multi-agent is "not straightforward today", and full multi-agent collaboration requires custom framework code. The built in user reprompting tool becomes an explicit tool definition you write yourself rather than something the platform elicits automatically. None of those are model problems. They are the places where you wrote your logic into somebody else's shape.
"We ran all three against our worst support ticket. This one handled it best, so we are building on it."
You have measured the model and the prompt. Both take an afternoon to change. Neither is the thing that will cost you money in two years.
"Our tools are defined once, outside the platform. The platform is a runtime, and we could point it somewhere else this quarter."
Same build, same vendor, same result today. The difference only shows up on the morning the vendor announces maintenance mode.
What AWS and OpenAI did in 2026, in their own words
AWS states it plainly: Amazon Bedrock Agents, launched November 2023, is now Amazon Bedrock Agents Classic and will no longer be open to new customers starting on July 30, 2026. Existing agents keep working. Every API stays available except CreateAgent and InvokeInlineAgent, and only for accounts with no prior usage. There is no migration deadline and, in AWS's own words, no planned end of life date.
Read as a customer, that sounds generous. Then read the FAQ two answers further down. The model catalogue available in Bedrock Agents Classic is frozen as of the maintenance mode effective date, and new models released after that date are available only through AgentCore. That is the real invoice. Your agent runs happily on the models that existed in July 2026 while your competitor's runs on whatever ships next spring, and nothing ever alerts you, because nothing broke.
OpenAI's version is blunter. Its deprecations page records that on August 26, 2025 it notified developers using the Assistants API of removal exactly a year later, on August 26, 2026, with the Responses and Conversations APIs as the replacement. Scroll down the same page and you find that the Assistants API v1 beta was already discontinued on December 18, 2024. So the product being removed this month is itself the replacement for a product removed two years ago. Two generations of one idea gone inside three years, from the vendor with the most to gain from developers staying put.
The per-account rule that catches agencies
This is the paragraph I would tape to the wall of any agency building on somebody else's cloud.
AWS decides Bedrock Agents access per AWS account, not per company. If an account has had Bedrock Agents activity in the past 12 months it is allowlisted. That applies per account, and where a business runs several accounts, only the ones with prior usage are allowlisted. Everything else gets an AccessDeniedException, HTTP 403, the moment it calls CreateAgent.
Now picture the normal agency sequence. You prototype in your own AWS account. The client approves. You deploy into the client's production account, the fresh one opened for this project. Your account has history. Theirs has none. The pilot works and production returns a 403, and it will not be obvious why, because the credentials are correct and the code is the code that just worked.
There is also no way to talk your way out of it. Asked directly whether an exception can be requested for a new account after July 30, AWS answers no, and says there is no exception process, because the allowlist is determined automatically from account history. Nobody can help you. That is the shape of constraint worth hunting for on every platform you evaluate, and the question is not what it costs. The question is what is decided by an identifier you do not control, and whether it can be appealed.
Three moves before you commit to a platform
The bottom line
None of this is an argument against building on a managed platform. Managed agent runtimes are worth the money, and writing your own orchestration loop to avoid lock in usually buys you a worse loop plus the lock in of your own code. The argument is against choosing one as though the choice were permanent.
So stop trying to pick the platform that survives. Pick the one whose exit you can price. Define your tools as services you own, keep conversation state somewhere you can query without the vendor's SDK, and put the pilot in the account that will run production. Do those three things and a maintenance mode announcement is a Tuesday rather than a quarter.
I build these systems as fixed scope engagements: tools defined as portable services, a runtime chosen for how cheaply you can leave it, and the AI voice agents or back office automations running on top of it. Builds start at $2,497, the managed programme runs $1,997 a month, and most go live in two to six weeks. Who I am.
Book a 30 minute call: cal.com/zeeshanwaheed/30min or email [email protected].