Skill-Driven Development: rethinking how we build for AI agents

I’ve been thinking a lot about an assumption that’s shaped product development for decades: people use software to get work done. Identify a user need, build a feature that helps accomplish it, and refine that experience over time. Features became the primary way we translated customer problems into product solutions.

AI agents challenge that assumption. Increasingly, the software isn't only serving a human user. It's serving an AI agent acting on that user's behalf. The question is no longer only, "What feature does the customer need?" It's also, "How does an AI agent accomplish this work on behalf of the customer?"

That shift creates a new opportunity for product teams. Instead of designing only for human interaction, we can design capabilities that AI agents can reliably discover, invoke, and combine to complete meaningful work. This is the foundation of Skill-Driven Development. 

Skills amplify the value of our products 

Earlier this year, we launched our ‘A/B Testing’ feature in Forethought by Zendesk’s ecosystem to answer this question: which AI agent policy actually performs better? Customers can test versions of AI Agent policies against each other, revealing the policy which will yield the best results for the business. 

Customers could already configure these tests manually, but we didn’t think they should have to. We wanted to make set up easier (and selfishly, to drive more adoption). So we developed a skill for our in-product AI Studio agent that empowers it to configure A/B Testing the same way a Forethought by Zendesk user would. 

The skill gives AI Studio the context about how our implementation of A/B Testing works, the requisite inputs into an A/B Test, what types of APIs to use to configure the tests, and to always confirm with the customer before publishing a test, among other details. When invoked, AI Studio can now easily work with a customer to configure an A/B Test directly from the conversation, without requiring the customer to click-through the preexisting A/B Testing UI.

Without this skill, it would take AI Studio a retrieval-augmented generation (RAG) through our Knowledge base, or multiple turns in a customer conversation, each time the customer wanted to use A/B Testing. Inefficient at best. The existence of the Skill also encourages AI Studio to suggest customers use A/B Testing to drive statistically significant agent performance enhancements. 

It’s clear to us that skills drive ease of use and adoption, so much so we’ve started retroactively applying skills to existing features. They're a way to make existing features dramatically easier to discover and use, for customers and for AI agents.

We developed a skill for our in-product agent AI Studio that empowers it to configure A/B Testing just like a normal Forethought by Zendesk user would.

Rethinking how our products get work done

Building skills forced me to ask a bigger question about product development: who will actually use the features we build in the future?

More importantly, why do we build features (not skills) in the first place? The answer to this second question points us toward the answer to the first. We build features so customers can achieve their business goals with our product. The customer doesn’t actually need to be the one using the feature. They just need the outcome it produces..

When we strip our thinking back to the job our customers are trying to get done, the possibilities for how that work gets completed become much broader.

Take our A/B Testing example. Customers want to understand which Agent Policy delivers better results, but they don’t necessarily need to configure the test themselves. Those policies could be written, vetted, tested, and published without manual authoring at all. The customer still gets the outcome they care about (higher automated resolution rates, stronger customer satisfaction, lower average handle time) without having to configure the product themselves.

Instead, the customer owns the inputs, such as integrations, policy content, and channel deployment, and monitors the outputs. The product does the work in between.

In my years of speaking with CX admins, I’ve never met someone who loves writing agentic policies. They care about helping users resolve issues quickly and easily, ideally without ever needing to engage a human agent. Their expertise is in the business, not the mechanics of AI. 

This is the opportunity. Our products should capture that expertise and let AI turn it into policies that power clear, effective, delightful user experiences. The way we move this forward is to make AI Agents the primary operators of the features and tools that admins use to run their businesses.

That changes how we should think about who we’re building for. Our features will serve the customer, but increasingly they’ll be used by AI agents. 

This is where my perspective has really changed. If AI agents are increasingly becoming the operators of our products, then we should design for them first. Which leads me to a simple idea: we should design the agent skill before we build the feature itself.

Designing with Skill-Driven Development

When I start thinking about what this might look like in practice, I keep coming back to Test-Driven Development (TDD). In this framework, software teams don’t build the feature first. They first write the tests the feature should pass. By defining the scenarios a feature will face—and how it should respond—teams create a clear set of requirements before they start building. It’s much easier to build the feature itself because it’s now extremely easy to validate whether the feature is complete and properly built. Either the tests pass or they don’t. The real power of TDD is ultra-clear requirements. If you know what you need to pass a test, you know what you need to build.

I think Agentic development can - and should - extend this concept into Skill-Driven Development. Instead of starting with a PRD, or vibe-coding a prototype, product teams should consider pre-writing an AI agent skill that describes how an AI agent should use the feature. The skill defines what the feature is, the technical tools available to it, and other context. It can act both as a requirements document and an end deliverable. You could even pass that new agent skill to a coding agent to help build the feature itself.

Crucially, skills are not the feature itself. Features - especially in the enterprise space - need to be permissioned, tracked, audited, reported on, and optimized for consistent performance. The difference is that we increasingly want AI to operate those features. 

That means the actions AI agents take while using these features need to be visible to humans, can be overwritten, and don’t absolutely require AI agents to function. And yes, of course we should still build user interfaces for humans to engage with our features too. 

Agentic AI promises to usher in a productivity revolution

Building Skills has changed the way I think about product development. I suspect it will change the way many of us build software over the next few years.

We've always built features to help customers achieve their goals. As AI Agents become the primary operators of those features, we have an opportunity to rethink how we design them from the very beginning. For me, that's what Skill-Driven Development is really about.

It’s one framework teams can use to build products that are easier for AI Agents to understand, easier for customers to adopt, and ultimately more effective at helping businesses achieve their goals.