Serverless Architecure is Failing Agents?
February 17, 2026
Last month I came acros an interesting article from The New Stack and I really felt like I needed to respond. One of my biggest gripes about the modern landscape and serverless is how people associate serverless with functions.
Now again, I understand why this is the case. Prior to the launch of AWS Lambda, the term “serverless” didn’t really exist in our vocabulary. Lambda was the first commercially viable Functions-as-a-Service (FaaS) platform and AWS labeled it as “serverless”.
To give AWS credit, Lambda and by extension FaaS was the first platform to popularize the term serverless. But we really need to shake the idea that serverless is limited to just functions.
So a quick note, I am a Googler and I am a huge fan of Cloud Run. I have been supporting that product as a Googler since its beta launch in 2019. So naturally, I will always promote it. However, I am only going to focus on the facts as it relates to the post on The New Stack and not focus on other features. I will also highlight other companies doing similar things with products.
With that out of the way, let’s address the two key arguments here.
VPCs and On-Premise Data
This quote from the article sums up their stance pretty decently on this topic. “Enterprise AI programs must now assume that agent workloads touching internal data will require VPC-native or on-premises deployment.”
This makes perfect sense as a lot of internal data is behind a VPC or on-premise as it sensitive in nature. Your agent, wherever it is running, needs to access the data. But let’s take a step back. Are they arguing that serverless platforms can’t utilize VPCs? I mean, Cloud Run can. Heck, even Lambda can. You can configure a VPN to connect to on-premise data.
Serverless Data Persistence
Serverless, by nature, is stateless. The service will “wake up”, execute its task, and spin down. When it “wakes up” again, it has no real knowledge of what it did last time. This is a great architecture for workloads such as API endpoints or batch processing data.
Agents, on the other hand, require some statefulness. It needs to know what task it previously completed as it continues to performs autonomous and asynchronous tasks. Traditional serverless platforms make this a challenge.
Cloud Run does support ways to address this though. For example, you can use Memory Bank for short-term memory storage. Long term memory storage can be put into a simple key-value based NoSQL database. Lambda can leverage DynamoDB for data persistence, for example.
Ultimately, I think this article looks at serverless in a vacuum. It sees serverless as just a runtime. If you approach your cloud architecture in that fashion then sure, you will see some shortcomings and a VM may make more sense. However, with every major hyperscaler and even the neoclouds, you can connect serverless runtimes with additional services to easily overcome these issues.
Serverless architecture isn’t failing agents. It’s helping it thrive.
—Photo courtesy Brett Jordan on Pexels—

