Agent Skills Turn Engineer Judgment Into Files That Need an Owner

Agent skills turn a senior engineer’s judgment into a file that an AI agent reads and follows, which means a team now has to own, review, and retest that judgment like any other production asset. Bill Doerrfeld describes how Meta did this in a recent article, and this piece takes one claim from it further.

Agent skills at Meta keep stable tools apart from changing expertise

Doerrfeld reports on Meta’s Capacity Efficiency Program, which uses AI agents to find and fix performance regressions. In his account, Meta built narrow tools on the Model Context Protocol for observing and acting on its systems, and put the reasoning of senior engineers into separate skills. He reports that diagnosis time fell from about 10 hours to about 30 minutes and that the program is recovering hundreds of megawatts of power, citing Meta’s engineering blog for the figures.

Tommy Tran, the Meta engineer who is the article’s main source, says the split lets "the plumbing stay stable while expertise evolves independently." Doerrfeld also reports that a human engineer stays in the loop for anything that changes production, and he frames the result as expert judgment becoming a reusable skill.

Meta’s own post shows the skill layer carries all of the judgment

The Meta engineering post that Doerrfeld cites, Capacity Efficiency at Meta: How Unified AI Agents Optimize Performance at Hyperscale by Tommy Tran and Michael Zetune, published on 16 April 2026, makes the division of labor concrete. Tools are standardized interfaces that each do one narrow job, such as querying profiling data or retrieving configuration history. A skill tells the model which tools to use and how to interpret what they return. The post says the same tools serve both finding optimizations and catching regressions, and that only the skills differ.

That detail matters for governance. If the tools are identical across both jobs, every difference in behavior between them lives in the skill text. The part of the system that decides what counts as a problem, what to check next, and what a result means is a document written by people, and it is the part most likely to change.

The post also sets a limit on what we can conclude. It describes review of the generated fixes: for regressions, a fix-forward pull request goes to the author of the change that caused the regression, and for optimizations, engineers review and deploy the generated code. It does not report an acceptance rate or a failure rate for those fixes, and its figures come from Meta’s own engineering team. The 10 hours to 30 minutes comparison is a statement about diagnosis time and says nothing about how often the diagnosis is right.

Reviewing each pull request does not review the agent skills behind it

Output review catches a bad fix. It does not tell a team whether the skill that produced the fix has drifted, because the reviewer sees one pull request at a time and a skill is applied every time its task comes up. A flaw in a skill repeats until someone notices the pattern. The reviewer of a single change is not placed to notice it.

Anthropic’s engineering post Equipping agents for the real world with Agent Skills describes a skill as a folder holding a SKILL.md file plus optional scripts and resources, which the agent loads when the task seems relevant. It recommends watching how the agent uses a skill and refining the skill when behavior goes astray. It also warns that malicious skills can introduce vulnerabilities or direct an agent to exfiltrate data, and it advises relying on trusted sources and reviewing bundled files before use. Both points treat a skill as something that is maintained and audited, and neither describes it as a one-time write-up.

From these sources I draw a practical standard, and it is my own proposal. Each skill gets a named owner who is a senior engineer in that domain. Each skill sits in version control, with changes reviewed the way code changes are. Each skill is replayed against a set of past cases, including ones where the earlier behavior was wrong, before a change goes live. And each skill records why it says what it says, because a file cannot be questioned the way the engineer who wrote it can.

Agent skills need less ceremony on small teams and more on shared platforms

This standard has a cost, and it does not fit every team. On a team of five, a skill may be one page of notes that the author edits when it fails, and a formal owner, version history, and replay set would cost more than they save. The balance changes when many teams share a platform, when skills come from outside the organization, or when a skill touches production. A shared skill is closer to a shared library than to a personal note, and it deserves the controls a shared library gets.

There is also a counter-case in favor of keeping skills loose. Codifying judgment can freeze it. A skill that captured good practice two years ago can quietly encode a practice the team has since moved on from. Ownership and replay testing address this, and an unreviewed file does not.

Why This Matters for Engineering Leadership

When an agent follows a skill and makes a poor call, the accountable party is a person. The useful governance question is which person. Leaders can ask four things about any skill an agent uses: who owns it, when it last changed and who approved the change, which past cases it was last tested against, and where it came from if it was not written in house. A team that cannot answer them has delegated decisions to a document that nobody is responsible for.

Doerrfeld’s article shows the upside, in which a few engineers’ expertise reaches many more tasks. The same property is the risk. A skill spreads one engineer’s judgment widely, so it is worth giving that judgment the review, history, and ownership it would get if it were code.

FAQ