Vendors now ship the procedure. Oracle and Databricks turn expert know-how into skills you have to version

For most of enterprise software’s history, a vendor shipped the product and someone else shipped the know-how. The product came with documentation; the knowledge of how to configure it for a real company lived in consultants, in implementation playbooks and in the heads of people who had done it before. That split is starting to close, and it changes what an enterprise has to control.

Two releases this week show it from different directions.

On October 26, Oracle announced the Fusion Setup and Configuration Registry, which it describes as a public Git repository that makes the setup and configuration of Fusion Applications machine-readable and executable by AI agents. Oracle builds and maintains it. Agents, including coding agents from OpenAI and others, can turn requirements, process documents and existing configurations into implementation runbooks, then plan, execute, test and validate the setup. Expert reviewers examine the result and approve it for deployment. Systems integrators, with Accenture, Deloitte, PwC and Grant Thornton quoted in the release, can extend it with their own methods and industry solutions.

On October 27, Databricks released Vital Skills, open-source agent skills that give its Genie Code agent healthcare and life sciences method: pause and ask the analyst to choose a clinical threshold instead of assuming one, use vetted tools for sensitive steps instead of improvising, and require checks such as pinned dependencies and a smoke test before deploying a model. In Databricks’ own tests, a deployment task met 27 of 27 required checks with the skill and 19 of 27 without it. That is the vendor’s evaluation, three runs per task graded by an LLM judge, on a small set of in-scope tasks.

And in the same week, Google and Oracle made more than 135 prebuilt Oracle skills available inside Gemini.

The procedure now has a release cycle

We have argued that an agent skill is a procedure, and in regulated work it belongs under document control. That argument assumed your own experts wrote the skills. What follows is a refinement, and it is our view rather than a fact: when the vendor writes and maintains the procedure, the procedure gets the vendor’s release cycle, and your control has to meet it there.

Three consequences follow.

An update to a skill is a change to how your work is done. If Oracle improves the runbook for configuring a ledger, every agent using the registry configures ledgers differently from that day. That is the point of a maintained registry, and it is also a change your configuration management never saw. Pin the version your agents use, read the diff before moving, and record in each run which version applied.

The procedure has layers, and each layer has an owner. The vendor’s baseline, the integrator’s extension, your company’s overrides. When a configuration is wrong, someone will ask which layer encoded the mistake. Keep your overrides in your own repository, separate from the vendor’s, so the question has an answer. The MCP skills extension makes skills portable only if your repository remains the source.

Skills need tests that travel with them. Vital Skills ships a skill-evaluation skill; Oracle’s registry includes testing and validation. Insist on that. A skill without a test is a document an agent will follow literally, and literal is not the same as correct for your policy.

What it means for implementations

The economics move, too. If configuration knowledge is maintained software, the labor of applying it gets cheaper and the value of integrators shifts toward industry extensions, validation and the business decisions no registry can make. That is not a forecast that consultants disappear; Oracle’s own design keeps expert reviewers as the approval step.

In validated environments, such as a pharmaceutical company’s ERP or a bank’s core finance configuration, one more thing changes. When an agent executes a vendor runbook, the configuration it produces still needs validation evidence, and the runbook version becomes part of that evidence. Ask your quality team now how they would document a configuration that an agent applied from a vendor-maintained repository. It is much easier to decide before the first implementation than during the audit of it.

The same pattern is appearing inside development teams, where GitHub’s new Dreaming feature proposes changes to skills and instructions by pull request. Whoever writes the procedure, the enterprise’s job is the same: decide which version is effective, and be able to say which one was used.