Eight configuration mechanisms exist for agentic coding tools. A team of researchers went looking for them in 2,853 GitHub repositories, and what came back is one mechanism carrying almost all the weight.
The paper is Harness Engineering for Agentic AI Coding Tools: An Exploratory Study. It builds on work published in AIware 2026. The stated method: identify eight configuration mechanisms spanning from static context to executable and external integrations, then examine whether and how they are adopted across those 2,853 repositories, with a detailed analysis of Context Files, Skills and Subagents.
Two findings carry the paper.
First: Context Files dominate the configuration landscape and are often the sole mechanism in a repository, with AGENTS.md emerging as an interoperable standard across tools.
Second: few repositories adopt advanced mechanisms such as Skills and Subagents. Skills predominantly rely on static instructions rather than executable scripts.
Read those two sentences next to any vendor keynote from the last twelve months and you will notice the gap.
What “sole mechanism” means when you are the one maintaining the repo
The phrase doing the most work in that first finding is often the sole mechanism. Read it literally: configuration begins and ends there. A repository that has configured its coding agent has, in a large share of cases, written one markdown file and stopped.
If you use a coding agent daily on an enterprise Java codebase, that result is either deflating or vindicating depending on what you have been told to feel bad about. The narrative you have been sold says the sophisticated shop graduates from a context file to skills, then to subagents, then to a fleet of them coordinating. The observed behavior says the sophisticated shop writes a good markdown file and gets back to work.
There is a version of this finding that is just “adoption takes time, the advanced stuff is new.” That reading is available and probably partly right. But it does not survive the second half of the second finding: Skills predominantly rely on static instructions rather than executable scripts.
The mechanism people adopted, minus the part that made it a mechanism
Skills, as a category, exist to hold something a context file cannot: procedure that runs. A skill can carry a script the agent executes: a deterministic step, a verification, a generator, something with an exit code. Executable scripts are optional in a skill (only the SKILL.md file is required), which is exactly why a skill can collapse into a longer paragraph of AGENTS.md with a folder around it.
The finding says the repositories that adopted Skills largely did not adopt that part. They used the skill container to hold more static instructions. So the file structure changed and the mechanism count went up. The configuration surface stayed exactly where it was: text that shapes what the model reads, with nothing that constrains what the system does.
That is a much more specific result than “advanced features have low adoption.” It says people reached for the advanced mechanism, and then used it as if it were the basic one.
Three explanations, and the one you can test
The paper reports what it observed. Why executable configuration did not take is where the argument is, and from here I am reasoning past the data. Three explanations fit the shape of the finding:
Maintenance cost. An executable skill is code. It has dependencies and an owner. It breaks when the repo moves, and it needs updating every time the toolchain changes. A markdown file has none of those properties. It degrades silently where code fails loudly, which is worse in principle and much cheaper in practice. Anyone who has maintained a Makefile that only three people on the team can modify already knows this tradeoff and made the same call.
No visible return. When you improve AGENTS.md, the next agent run reflects it immediately and legibly: you read the output and see your instruction landed. When you add an executable skill, the benefit is conditional on the agent choosing to invoke it, in a situation that matches, on a run you may not observe. Static context pays you back in the same session. Developers optimize what they can see move.
No good way to test it. This is the explanation I would put money on, and it is the one with a concrete fix. We have decades of practice testing application code and roughly none testing agent configuration. What is the assertion for “this skill fires under the right conditions,” and what does an error look like? A team with a mature CI pipeline can tell you in minutes whether a change broke the build. That same team cannot tell you whether last week’s edit to their agent config made the agent better or worse, and they know it. Executable configuration without a test harness is a component you ship untested into a nondeterministic runtime. Java teams built an entire testing culture around not doing that.
The three are not exclusive. But notice which one you can act on: cost and visibility are properties of the ecosystem, and testability is a thing a team can build.
Claude Code users reach for more mechanisms than anyone else
One result deserves separate treatment: users of Claude Code employ the widest range of mechanisms among the tools studied.
In other words: a particular tool attracts more sophisticated practitioners. Read it as a fact about surfaces and you get something more useful. A mechanism that a tool does not expose cannot show up in a repository, no matter how sophisticated the person typing. If adoption breadth tracks the tool and not the team, what the study measures is the ceiling each tool sets.
What to actually do with this
The paper suggests AGENTS.md as a natural starting point, and the empirical result gives that suggestion teeth: it is the interoperable standard across tools, so the effort transfers when you switch. For most repositories it is also, apparently, where the work ends. Given the state of the tooling, that is a defensible place to stop.
The move that follows from the data has no glamour at all. Write the context file, make it genuinely good, and treat every step beyond it as a claim you have to justify. Before adding an executable skill, answer the question those 2,853 repositories answer with silence: how will you know it works, and how will you know when it stops working? If you have an answer, build it. If you do not, you would be adding a component to your build that apparently nobody will verify, which is the situation the static markdown file quietly avoids.
The market is selling multi-agent orchestration. The configuration files of thousands of repositories describe something plainer: one file, written carefully, doing most of the work. With a gap that wide between the pitch and the practice, the question worth asking is what the executable mechanisms still need before teams reach for them. Testability is the first item on that list.