A familiar pattern seems to be playing out with agent frameworks: everyone is building opinionated end-to-end solutions that bundle everything together (design, test, deploy, observe). But if we’ve learned anything from previous platform shifts, this might be the wrong approach…
Sep 16, 2025 · 4:57 PM UTC
We tend to see this typical pattern whenever there's a new architectural paradigm: everyone rushes to build vertically integrated solutions. "This new thing is complicated; we'll handle everything for you in one neat package."
When web and cloud emerged, we saw the emergence of hundreds of “cloud management platforms” and PaaSes, from Heroku to Rightscale to EngineYard. The pitch was simple: "building, deploying and managing this new breed of apps is complicated, so we'll do it all."
But here's what always happens next: developers get comfortable with the new paradigm, they start wanting the right tool for the right job. They realize the trade-offs of convenience. They need flexibility. They want to compose their own stack.
Along the way new standards + best practices emerge. The monolithic platforms disaggregate into specialized building blocks: databases, orchestration engines, message queues, configuration management, etc. Building cloud apps became the ultimate choose-your-own-adventure.
For upstarts, owning a discreet layer of the cloud app stack - becoming a standard - proved far more lucrative vs. building an end-to-end solution. Look no further than the enterprise value of Mongo, Confluent, Hashicorp, Datadog, etc. against the PaaS category as a whole.
Looking at agents today, I see the exact same pattern forming. We're in the "Heroku moment" where everyone's building vertically integrated agent platforms. Complete solutions that promise to handle everything from orchestration to observability to tool calling.
This won't last. As teams get serious about productionizing agent applications, they'll want composable components. What does the disaggregated agent stack look like?
I'm betting on at least few key primitives:
- Specialized memory/state layers that can be swapped based on use case
- Message buses designed for tool calling and orchestration
- Durable execution engines that can handle long-running agent workflows
