Skills Are the New Features: Building the Next Generation of Agentic Products

Talk @ AI Engineer World’s Fair 2026 by Yogi

I maintain verifyclaw security checks openclaw skills registry.

The transition from traditional software applications to agentic products demands a fundamental shift in how we architect, build, and ship capabilities. In a recent presentation at the AI Engineer World’s Fair 2026, the concept that “Skills Are the New Features” was introduced as a foundational mental model for this new era [1]. Rather than constructing monolithic prompts or brittle execution chains, modern agentic products rely on a decoupled architecture where discrete, well-governed skills serve as the primary unit of functionality.

How to Build Agents without Losing Control — the talk that set the stage for this mental mode

This article explores the core concepts of this architectural shift, drawing from the presentation slides and the accompanying skills-demo repository [2], and examines how operating a skill ecosystem requires rigorous governance and evaluation.

1. The Problem with Monolithic Prompts

A common anti-pattern in early generative AI applications is the “huge prompt” approach — attempting to cram persona, instructions, routing logic, and tool usage into a single, massive context window. This approach quickly becomes unmaintainable and limits the ability to scale functionality.

What it is NOT about (coding assistants, MCP wrappers, how to write tools) vs What it IS about (organizing agentic products, building support bots, scaling skills across the enterprise

The talk is explicit on this point: it is not a talk about coding assistants, MCP wrappers, or how to write tools. It is about how to organize agentic products, how to build support bots on your own terms, and how to scale skills across the enterprise. The distinction matters because it reframes the conversation from tooling to architecture.

Visualization: Old monolithic prompt architecture vs. new skill-based architecture

The diagram above illustrates the contrast clearly. In the old model, a chatbot delegates everything to a single, undifferentiated “huge prompt.” In the new model, an agent delegates to a set of focused, individually-defined skills — each responsible for exactly one job.

2. The Decoupled Agent Architecture: Who, What, and How

The most important conceptual contribution of this talk is a clean three-part decomposition of any agent into Who, What, and How.

The Who / What / How framework with examples for each dimension.

Who is the system prompt — it defines the agent’s identity and role. Examples include “You are a financial analyst,” “You are a drone copilot,” or “You are an insurance adjuster.” What is the set of tools the agent can access: web search, databases, APIs, and the file system. How is where skills live — they define the specific, reusable procedures the agent can execute, such as “Write quarterly report,” “Analyze earnings,” or “Generate invoice.”

By decoupling these three concerns, developers can build agents that are composed of deterministic building blocks rather than opaque, monolithic prompts. The user interacts with a standard product UI, which invokes an agent. The agent, in turn, selects and executes the appropriate skills, orchestrating the underlying LLM and tools. The customer never sees the orchestration.

The full agentic product stack from User down to LLM and Tools.

3. Shipping Skills Instead of Features

In a traditional software development lifecycle, product engineers focus on shipping UI features. In the agentic era, this paradigm shifts: teams ship skills. The role of the product engineer evolves from feature delivery to skill authorship.

Consider a wealth management application. Instead of building a single, complex “Financial Agent,” the functionality is broken down into discrete skills. The slide below illustrates this directly, showing two domains — Equity Research and Wealth Management — each decomposed into a library of named, reusable skills.

Skills are New Features — Equity Research and Wealth Management skill libraries.

Each entry in that list — earnings-analysis, tax-loss-harvesting, portfolio-rebalance — is a packaged, independently-maintainable unit of business logic. This is the key insight: every feature becomes its own skill.

Anatomy of a Skill

A skill is not merely a prompt snippet; it is a standardized package that teaches an AI agent how to perform a specific task reliably.

“A standardized way to teach AI agents how to do specific tasks well.”

Definition of a Skill — directory structure with SKILL.md, scripts, references, and assets.

As demonstrated in the skills-demo repository [2], a skill is encapsulated in a directory containing at minimum a SKILL.md file with metadata and instructions, and optionally scripts, references, templates, and assets.

Anatomy of a skill package — directory tree and SKILL.md frontmatter fields.

The frontmatter of a SKILL.md file carries structured metadata: the skill’s name, a natural-language description, its expected inputs and outputs, the tools it requires, and constraints on tool usage. The instructions section then provides step-by-step guidance that the agent follows when the skill is activated. This is essentially a packaging convention for business logic.

4. Descriptions as Routing Signals

One of the most critical insights for operating a skill ecosystem is that a skill’s description is not merely documentation — it is a core component of the inference and routing process.

Instead of relying on rigid, hierarchical menus (e.g., Finance → Tax → Quarterly → Skill), agentic products utilize semantic routing based on user intent. When a user states “I need to pay my taxes,” the system matches this intent against the rich descriptions of available skills. This means the description must be written to be discoverable by an LLM, not just readable by a human.

Instead of naming a skill simply “tax,” it should be described as: ”Prepares quarterly tax filing. Calculates deductions. Produces IRS-ready forms.” Now an LLM can discover it from a natural language request. The description is not documentation — it is a routing signal.

The agentic loop that drives this process is continuous rather than one-shot: the agent finds skills, executes them, observes the results, updates its context, and repeats until the goal is achieved.

The agentic loop — Goal → Find Skills → Execute → Observe → Update Context → Repeat.

5. Operating a Skill Ecosystem: Governance and Trust

As organizations scale their agentic products, they move beyond building individual skills to operating a comprehensive skill ecosystem. This requires a robust registry that handles discovery, versioning, activation, and lifecycle management. A registry is not merely storage — it is responsible for the full operational lifecycle of every skill it contains.

Furthermore, a skill library demands rigorous governance. The presentation highlights five key dimensions:

Skill Library Governance Dimensions — a radar chart across Admission, Ownership, Boundaries, Lifecycle, and Coherence.

| Dimension — — — -| Core Question — — — — — — - | Key Considerations | | — — — — — — — — — | — — — — — — — — — — — — — — | — — — — — — — — - — — | | Admission — — — -| Should this skill exist? — — — | Security, quality, uniqueness, licensing | | Ownership — — — | Who is accountable? — — —- | Maintainer, organization, contact, update history | | Boundaries — — — | What is it allowed to do? — — | Allowed tools, filesystem, network, secrets, permissions | | Lifecycle — — — — - | How does it evolve? — — — — | Versioning, deprecation, rollback, migration | | Coherence — — — — | Does the library still make sense? | Duplicate detection, conflict avoidance, abandoned skills |

These five dimensions map almost perfectly to the concerns of a production software library, which points to the final key insight of the talk: we should borrow software engineering practices and apply them to skill maintenance and governance. Pull requests, code review, version control, CI/CD, automated testing, semantic versioning, security scanning, and deprecation policies — all of these apply to skills just as they do to code.

The Imperative of Evaluation

Perhaps the most crucial principle in building reliable agentic products is this:

“Skills without evals are just wishful thinking.”

A skill cannot simply “work on my machine.” It must be backed by measurable quality metrics — accuracy, latency, success rates, regression tests, and benchmarks. Evaluation is not an afterthought; it is a core artifact of the skill registry. A skill that cannot be measured cannot be trusted in production.

— -

Conclusion

The shift towards agentic products represents a new frontier in software engineering. By embracing the mental model that “Skills Are the New Features,” developers can build robust, scalable, and maintainable AI applications. This requires not only a decoupled architecture — separating the Who, What, and How — but also a commitment to rigorous governance, semantic routing, and continuous evaluation.

The practical starting point is simple: stop building chatbots with huge prompts, and start building agents with focused skills. Each skill is a directory, a SKILL.md file, and a clear set of instructions. From there, the same engineering discipline that makes software reliable — versioning, testing, ownership, governance — makes skill ecosystems trustworthy and scalable.

Build Skills Instead — the central call to action from the talk.

References

[1]: https://yogendramiraje.com/2026/07/03/skills-are-new-features.html “Yogi Miraje. “Talk @ AI Engineer World’s Fair 2026.” yogendramiraje.com, 3 July 2026.”

[2]: https://github.com/yogi-miraje/skills-demo “Yogi Miraje. “skills-demo: Minimal skill-running agent demo.” GitHub, 2026.”