A skill might be focused on a single task: generating pull requests, reviewing Terraform changes, validating Kubernetes configurations, testing Databricks code, or analyzing Prometheus metrics. These skills are easier to maintain, easier to share, and easier to adapt to different customer environments.

One of the frameworks that accelerated these experiments was BMAD (“Breakthrough Method for Agile AI-Driven Development”, an open-source, agent-based software development framework). Although BMAD is often discussed as a methodology for building agents, we found its value elsewhere. It provided a structured starting point for creating workflows, tasks and reusable capabilities without forcing teams to start from scratch every time.

The important lesson, however, was that BMAD itself was rarely the final solution. Installing a framework is relatively easy. Making it useful inside a customer environment is considerably more difficult. Every project introduces its own standards, technologies, repositories and ways of working. A generic capability may function correctly from a technical perspective while still being largely unusable within a specific engineering context.

This became particularly visible when teams started comparing experiences across projects. Data engineers were experimenting with skills related to testing and safely working with datasets. Infrastructure engineers focused on Kubernetes, Terraform and cloud onboarding activities. Software engineers looked at debugging, documentation and development workflows. Although all of them used similar underlying technologies, the actual requirements differed substantially. As a result, the effort was rarely spent building the capability itself. Most of the work involved adapting it to the realities of a specific project.

Why we stopped building Agents and started building Skills

After several months of experimenting with AI-assisted engineering workflows, one pattern started emerging across projects. While most industry discussions focused on increasingly capable agents that could perform complex tasks autonomously, our engineers were asking for something much simpler. They were not looking for an AI system that could replace them. Instead, they were trying to solve a collection of very practical problems that consumed time within their daily work.

One engineer was spending a significant amount of time reviewing Terraform changes before creating pull requests. Another was in the middle of a Kubernetes migration and repeatedly found herself searching for the same networking information. Others were dealing with Prometheus troubleshooting, infrastructure onboarding, documentation generation or testing activities. Although the technologies differed, the underlying challenge was remarkably similar. Engineers were spending considerable time on repetitive activities that required context and experience, but offered relatively little intellectual value. Rather than asking for larger agents, they started creating small capabilities that solved specific problems.

Although each capafunbility addressed a relatively narrow use case, together they removed a significant amount of repetitive work from the engineering process.

This distinction may seem subtle, but it has important implications. Building a large agent that attempts to solve every problem requires broad context, extensive governance and a high degree of trust. Building a focused skill that helps engineers perform a specific task is often significantly easier, both technically and organizationally. Skills can be introduced incrementally, validated against real use cases and improved over time without disrupting existing workflows.

Context matters

Perhaps the most important lesson learned throughout the experiments was that context matters far more than many people initially expect.

A language model may understand Kubernetes, Terraform, Python or C++. That does not mean it understands your environment. It does not know how your repositories are organized, which standards your team follows or why a specific architectural decision was made several years ago. It does not understand which restrictions apply to a customer environment or which exceptions have been introduced over time. Without that information, even technically impressive models often struggle to produce consistently useful results.

This challenge becomes increasingly visible as the size and complexity of a software environment grows. Many AI demonstrations involve relatively small applications where the entire codebase can be understood within a limited context window. Enterprise environments rarely look like that. Some of the teams we spoke with support codebases containing hundreds of thousands of files spread across multiple repositories and maintained by hundreds of engineers. In those situations, the challenge is no longer generating code. The challenge is understanding enough context to determine which code should be modified in the first place.

Building layers of knowledge

As teams encountered these challenges, they gradually started thinking about context in a more structured way. Rather than treating every project as an isolated environment, they explored the idea of layered knowledge.

At the highest level sit organizational standards. These include broad principles around security, compliance and engineering practices that should apply consistently across projects. Beneath that layer sits project-specific context. Teams may use particular technology stacks, coding standards, deployment approaches or architectural patterns that are relevant within a specific environment. Finally, individual repositories introduce their own rules, exceptions and implementation details.

Thinking about context in layers turned out to be useful because it mirrors how engineers themselves work. A developer joining a project does not learn every detail at once. They first understand organizational expectations, then project standards and finally the specifics of the repository they are working in. Applying the same structure to skills makes it easier to create reusable capabilities without losing the context required to make them useful.

Toward parameterized skills

One consequence of this layered approach is the possibility of parameterized skills. Rather than creating a different version of the same capability for every project, engineers can build reusable skills that adapt themselves based on project-specific information.

Early experiments have already demonstrated that this is feasible. Teams created environments in which skills could identify the repository they were operating in, load relevant configuration and adjust their behavior accordingly. The approach is not perfect yet and there are still situations where manual intervention is required, but the results are encouraging. Instead of maintaining dozens of nearly identical capabilities, organizations can gradually move toward reusable building blocks that are configured rather than rebuilt.

This is important because it shifts effort away from repeatedly solving the same problem and toward improving shared capabilities. As organizations gain experience, those capabilities become more reliable and more broadly applicable.