The Shift from Agent as App to Company as Agent

The current model for AI agents, which relies on a single user interacting with a temporary session, does not work for business. It fails as soon as you need isolation, durability, or the ability to handle thousands of concurrent requests. In this conversation, Andrew Barba and Shar Dara of Vercel outline the requirements for moving beyond these pet agents toward cloud native frameworks. Their thesis is that company building is becoming agent building. By defining agents through configuration files rather than hard coded logic, they argue that the agent should exist before the website or the business itself. For engineers and founders, this shift moves toward infrastructure as code for intelligence, where the agent acts as the brain of an automated software factory. Those who adopt this agent first architecture gain an advantage in operational agility.

The Hidden Cost of Hand Rolled Intelligence

Most teams building agents are stuck in a cycle of hand rolled infrastructure. They build a feature, realize they need state management, add a database, then realize they need retries. Suddenly, they are maintaining a complex distributed system just to keep a simple agent running. Barba notes that their internal data agent, D0, required significant custom engineering, including serverless functions, sandboxes, and workflows, before the team could focus on the agent utility.

It was a ton of work by that team basically just getting it to run correctly before even thinking about what D0 does. Right? So, we feel like there was this very large layer sitting below D0 that basically every single agent that we would then deploy to ourselves going to need.

-- Andrew Barba

The systems thinking insight here is that the agent is not the code you write; it is the harness you build to keep it alive. By moving this harness into a declarative framework like Eve, you stop managing the infrastructure and start managing the agent capabilities.

Why the Obvious Fix Makes Things Worse

Conventional wisdom suggests that to make an agent smarter, you should feed it more context. However, this creates a context bloat loop where the model becomes overwhelmed and performance degrades. Barba and Dara argue for a principle of progressive disclosure. Instead of stuffing the model with every piece of documentation, they use a directory based structure where the agent only pulls in what it needs, when it needs it.

This is where the system responds to the developer design. By using skills and tools as modular primitives, the framework allows the agent to learn only the relevant context for a specific turn. This prevents the system from becoming a monolithic, unmanageable mess. The downstream effect of this design is that the framework remains performant even as the agent knowledge base grows.

The 18 Month Payoff: Evals as the New Unit Test

Perhaps the most important insight for long term durability is the elevation of Evals to a first class primitive. Most teams treat Evals as an afterthought, a way to check if the agent is working. The Vercel team treats them as the foundation of the development lifecycle. They use their own Eval framework to test the framework itself, allowing them to ship multiple versions a day with confidence.

We think it is very, very important when you build a non deterministic system like an agent that you can actually test it and monitor it over time and see how it is performing.

-- Andrew Barba

This creates a feedback loop that solves the primary fear of non deterministic AI: the inability to guarantee behavior. By treating Evals as the unit tests of the agentic world, developers can create a system that evolves without breaking. The payoff here is not immediate; it requires the patience to build the test suite before the agent is fully mature. Most teams will not do this, which creates a moat for those who prioritize testing infrastructure early.

Key Action Items

• Audit your current agent stack: Identify which parts of your infrastructure are hand rolled, such as retries, session state, or isolation, and look for frameworks that handle these as declarative primitives. (Immediate)
• Adopt an Eval First mindset: Stop treating Evals as a final check. Start writing your Eval functions before you build the agent tools. This creates a guardrail that prevents drift as the agent evolves. (Immediate)
• Implement progressive disclosure: Structure your agent knowledge base into modular files like skills or tools rather than one massive prompt. This improves model reasoning and reduces context bloat. (Next 30 days)
• Standardize your World: If you are concerned about vendor lock in, ensure your agent framework uses adapter contracts for storage and scheduling. This allows you to move from serverless environments to Kubernetes or local hardware without rewriting your core logic. (Next 3 to 6 months)
• Treat the Change Log as an API: If you are working with coding agents to maintain your project, ensure your documentation and change logs are LLM friendly. This allows your agents to read the evolution of your system and adapt accordingly. (Ongoing)
• Shift to Company as Agent: Begin treating your agentic framework as the central brain of your business operations rather than a side project interface. This pays off in 12 to 18 months as your internal workflows become fully automated. (Long term investment)