Organizing companies by the maturity of their dev tooling makes the pattern obvious. There are three regimes, and which one you are in determines what your agent stack looks like.
Mature engineering orgs — Stripe, Spotify, Coinbase — already had infrastructure to repurpose. They forked an open-source harness, plugged it into existing CI/CD and observability, and started shipping. Their agent infra is mostly reused human dev infra. The marginal cost of adding agents was low because the platform was already there.
Less mature organizations — Ramp is the standout — bought almost everything off the shelf. Modal for sandboxes. Cloudflare for orchestration. GitHub for auth. They purchased every layer because they had no existing platform to extend. That is the right call when you are validating whether the use case works at all. But every one of those decisions has a half-life. When a core part of how you make money depends on infrastructure, you eventually bring it in-house. Buying buys you time, not a permanent answer.
Then there are the scrappy teams. Earthly: one engineer, an EC2 instance as the sandbox, no orchestration, building it themselves because at that scale you can. It works until it does not — until the engineer goes on vacation and the load-bearing side project breaks.
The opportunity sits in the gap. The small companies that are scrappy today will need real infrastructure tomorrow. Whether they hire another engineer or pull up a search bar depends entirely on whether a platform exists that meets them where they are. This is the same dynamic I've described in the build-vs-buy map — buyable categories solidify around problems where the answer becomes obvious enough to package.
If you are running a company in the middle gradient, the most useful question is which layer you can buy now and bring in-house later without rewriting. The wrong answer is to buy everything and hope the integration layer holds. The right answer is to buy what is settled, build what is core, and refuse to over-commit to vendors at the layers that are still moving.
Sources
Related Essays
The Atomic Agent Mesh: Architecture, Build-vs-Buy, and the Review Layer
Enterprise AI will not be one mega-agent. It will be a mesh of atomic, auditable units, and the companies that nail review and context will own the next infrastructure layer.
The Convergent Agent Stack
Fifty companies building internal agent platforms have independently arrived at the same architecture. That convergence is the productization tell.
The Mesh, Not the Monolith
One mega-agent that handles everything is exhilarating to demo and chaotic in production. Enterprise wants a mesh of specialized agents with human pilots.
Key takeaways
- Mature engineering orgs reuse their existing dev tooling. Their agent stack is mostly forked open source plus existing CI/CD.
- Less mature orgs buy almost everything. That is correct early but has a half-life.
- Scrappy teams hand-roll on a single EC2 box and live with the load-bearing side project.
FAQ
What predicts how a company builds its agent stack?
The maturity of their existing dev tooling. Companies with strong platform teams extend what they have. Companies without one buy. Companies below buying scale hand-roll until something breaks.
Where is the platform opportunity?
In the middle. Small companies that are scrappy today will need real infrastructure tomorrow. Whether they hire another engineer or pull up a search bar depends on whether a credible platform meets them where they are.