Why AI Agents Are a New Kind of Software: Lessons from Vercel's Andrew Qu

TL;DR

• AI agents aren't just chatbots with APIs—they're a new software primitive that requires rethinking how we architect products, moving from request-response patterns to autonomous, goal-driven systems.
• Skills matter more than tools: The future of agent frameworks lies in building reusable, composable skills (like "book a flight" or "analyze data") rather than one-off tool integrations.
• Agent-readable environments are critical: Products that expose structured, machine-readable interfaces will become the infrastructure layer for the agent economy—think Stripe for payments, but for every domain.
• Product builders must design for both humans and agents: The most successful products in the next five years will serve dual interfaces—beautiful UIs for humans, clean APIs and skills for agents.

---

We're in the middle of a quiet revolution in software architecture, and most product builders haven't noticed yet.

Andrew Qu, VP of Product at Vercel, recently sat down with the Latent Space podcast to articulate something I've been feeling but couldn't quite name: AI agents aren't just a feature—they're a new kind of software. Not an iteration on what came before. Not "chatbots plus." A genuinely different primitive that demands we rethink how we build products from the ground up.

If you're building AI products right now and treating agents as glorified API wrappers, you're missing the forest for the trees. Let me break down why Qu's framework matters—and what it means for how you should be thinking about your roadmap.

The Evolution of Software: From Procedures to Agents

Qu frames software evolution as a progression through distinct paradigms. We started with procedural programming—step-by-step instructions. Then came object-oriented programming, which let us model the world as interacting entities. The web gave us distributed systems and APIs. Mobile brought us always-on, context-aware computing.

Now we're entering the agent era.

What makes agents different? They're software that pursues goals autonomously rather than executing predetermined workflows. You don't tell an agent how to do something; you tell it what you want accomplished. The agent figures out the how—breaking down the goal, choosing tools, adapting when things go wrong, and iterating until success.

This isn't just a UX shift. It's an architectural one. Traditional software is fundamentally reactive: user input → processing → output. Agents are proactive: goal → planning → action → evaluation → replanning. The control flow inverts.

For product builders, this has profound implications. You can't just "add AI" to your existing product and call it agent-ready. The entire stack—from data models to APIs to error handling—needs to be rethought for a world where autonomous systems are first-class users.

Skills vs. Tools: The Architecture That Matters

Here's where Qu's thinking gets really interesting, and where I think most teams are getting it wrong.

The current generation of agent frameworks focuses on "tools"—discrete functions an AI can call. Need to send an email? Give the agent a send_email() tool. Need to query a database? Add a query_db() tool. This works for demos. It doesn't scale.

Qu argues for a higher-level abstraction: skills. A skill isn't just a function call—it's a composable capability that encapsulates intent, context, and error handling. "Book a flight" is a skill. "Send an email" is a tool.

Why does this distinction matter? Because skills are:

1. Reusable across contexts: A "book a flight" skill works whether the agent is planning a vacation, organizing a business trip, or comparing travel options. The same tool-based approach would require rebuilding logic in each scenario.

2. Composable: Skills can call other skills. "Plan a conference trip" might use "book a flight," "reserve a hotel," and "schedule meetings" as sub-skills. Tools are flat; skills are hierarchical.

3. Adaptive: A well-designed skill knows how to handle edge cases. If a flight is sold out, it searches for alternatives. If a hotel doesn't have availability, it expands the search radius. Tools just fail.

4. Marketplace-ready: Skills can be packaged, versioned, and distributed. Imagine an npm registry for agent capabilities—that's where this is headed.

My take: If you're building agent infrastructure right now, you should be designing for skills, not tools. The teams that crack reusable skill architecture will own the next decade of software development. Think about how React components changed web development—skills will do the same for agents.

Agent-Readable Environments: The Next Platform Layer

Here's the part that keeps me up at night as a product manager: most software today is built exclusively for human consumption. Beautiful interfaces, intuitive flows, visual feedback. All critical—for humans.

Agents can't see your beautiful UI. They can't click buttons or interpret visual hierarchies. They need structured, machine-readable interfaces.

Qu calls these "agent-readable environments," and they're going to become the most valuable real estate in software. Companies that expose clean, well-documented, semantically rich interfaces for agents will become the infrastructure layer of the AI economy.

Stripe is the canonical example. Their API is so good that it's become the de facto payment processor for thousands of products—not because their dashboard is pretty (though it is), but because their API is a joy to integrate. Now imagine that model applied to every software category.

Want to be the scheduling infrastructure for agents? Build an agent-readable calendar API with natural language time parsing, conflict resolution, and preference learning. Want to own CRM for the agent era? Design a contact management system that agents can query, update, and reason over without human intervention.

The products that win in the next five years will serve dual interfaces: a delightful UI for humans and a powerful, agent-friendly API for autonomous systems. If you're only building for one, you're building half a product.

What This Means for Product Strategy

Let's get tactical. If agents are a new kind of software, what should you actually do differently?

1. Design Your Data Models for Agent Consumption

Your database schema should expose semantic meaning, not just relational structure. Instead of generic metadata JSON blobs, use typed fields with clear intent. Add descriptions to your API endpoints that explain why someone would use them, not just how. Think of your data layer as documentation for a very literal-minded colleague who's going to build on top of it.

2. Build Idempotent, Fault-Tolerant APIs

Agents will retry operations. They'll call your API in unexpected orders. They'll misinterpret documentation. Your endpoints need to be bulletproof: idempotent where possible, gracefully degrading when not, and returning rich error messages that an LLM can actually parse and act on.

"Invalid input" is a useless error message for an agent. "The 'start_date' field must be in ISO 8601 format (YYYY-MM-DD) and cannot be in the past" is actionable.

3. Invest in Observability and Debugging

When an agent fails, you need to understand why. Traditional logs aren't enough—you need to trace the agent's reasoning, see which tools it considered, understand why it made certain choices. Build observability into your agent infrastructure from day one. LangSmith, Weights & Biases, and Helicone are good starting points, but you'll likely need custom tooling.

4. Think in Capabilities, Not Features

Stop asking "What feature should we build next?" Start asking "What capability should we enable?" A capability is outcome-oriented and composable. "Let users export data" is a feature. "Provide programmatic access to user data in multiple formats with filtering and pagination" is a capability that enables countless use cases—including agent-driven ones you haven't thought of yet.

5. Create Skill Marketplaces, Not Just Plugin Ecosystems

If you're building a platform, don't just let developers add tools. Enable them to create and share skills—higher-level capabilities that other agents can use. Provide templates, testing frameworks, and discovery mechanisms. The platform that becomes the "app store for agent skills" will be enormously valuable.

The Uncomfortable Truth About Agency

Here's where I'll offer a contrarian take that I think the industry needs to hear: most products claiming to use "agents" today aren't actually agentic.

They're chatbots with function calling. They're scripted workflows with LLM-generated text. They're glorified if-then statements wrapped in conversational UI. Real agency—the ability to autonomously pursue goals, adapt to changing circumstances, and improve over time—is hard. It requires rethinking your entire architecture, not just sprinkling some LangChain on top of your existing codebase.

I think we're going to see a shakeout in the next 12-18 months. Products that are truly agent-first—designed from the ground up for autonomous operation—will start pulling away from the pack. The rest will be stuck in the uncanny valley: smart enough to seem capable, not reliable enough to trust.

The question for product builders is: which side of that divide do you want to be on?

The Vercel Advantage: Why Infrastructure Companies Are Winning

It's no coincidence that Qu's insights come from Vercel. Infrastructure companies—the ones providing the pipes and platforms—have a natural advantage in the agent era. They see patterns across thousands of implementations. They feel the pain points firsthand. They can build abstractions that work at scale.

Vercel's bet on the AI SDK and their agent framework isn't just about staying relevant. It's about becoming the deployment platform for the next generation of software. If agents are the new primitive, whoever makes it easiest to build, deploy, and scale agents wins.

This is why I'm bullish on infrastructure plays in the agent space. The companies building the Stripe, Twilio, and Vercel equivalents for agents—the ones providing the fundamental capabilities that every agent needs—will capture outsized value.

Where We Go From Here

Qu's framework gives us a mental model for understanding what's happening in AI products right now. We're not just adding features to existing software categories. We're creating a new category entirely—one that will eventually subsume much of what came before.

For product builders, this is both exciting and terrifying. Exciting because we're in the early innings of a platform shift, and the winners aren't decided yet. Terrifying because the skills that made you successful in the last era (beautiful UIs, intuitive workflows, human-centered design) are necessary but no longer sufficient.

You need to think like a platform architect now. You need to design for both human delight and machine consumption. You need to build capabilities, not just features. You need to make your product agent-readable, not just user-friendly.

The good news? Most of your competitors haven't figured this out yet either. The teams that internalize these lessons now—that start building with skills and agent-readable environments as first-class concerns—will have a 12-24 month head start.

In software, that's an eternity.

Practical Next Steps

If you're convinced that agents represent a new kind of software (and you should be), here's what to do this week:

1. Audit your API: Is it agent-friendly? Can an LLM understand your documentation? Are your error messages actionable?

2. Map your product as skills: What are the high-level capabilities your product enables? How could they be packaged as reusable skills?

3. Prototype an agent interface: Even if it's just internal, build a simple agent that can accomplish a core workflow in your product. You'll immediately discover where your abstractions break down.

4. Talk to your power users about agents: How would they use autonomous systems to interact with your product? What would they want to delegate?

5. Invest in observability: You can't improve what you can't measure. Start instrumenting agent interactions now, before you have thousands of them to debug.

The agent era isn't coming. It's here. The only question is whether you're building for it—or getting built around.