Governing Skills in the Enterprise

How to protect your knowledge and IP without drowning in hosting and governance overhead.

Most AI rollouts still look the same. You buy licenses, point people at a chat window, and hope for the best. Every prompt starts from zero, and every output gets reviewed by hand, forever.

Most people are prompting and calling that AI usage. But usage alone doesn’t compound: for a repeatable task, that improvement only comes from turning the prompt into a skill, one governed by IT the same way any other enterprise system is, not left sitting in someone’s chat history.

Core principle: slope beats y-intercept

Most people size up an AI system by its first draft: is this answer good enough to ship? That’s a y-intercept question, and it’s the wrong one. What actually determines the return is the slope: does the tenth run need less correction than the first, and does the hundredth need almost none?

We mapped the mechanics in “The Future of Work.” Skip codifying each stage into a skill, and you pay the same correction cost on run 100 as run 1, no matter how many people are prompting.

Skill Management 101

A skill file by itself is just better documentation. What actually keeps quality climbing and review time dropping are three plumbing problems that have nothing to do with any single skill’s content, and every firm running AI at real scale needs all three solved the same way.

Human feedback channels. Every edit a reviewer makes has to land back inside the skill, not just in that day’s output. That correction is the raw material the whole loop runs on.
Evals. Structured tests that check a skill’s output against a standard, run before a person ever sees the draft. Evals are also what let a team have an honest conversation about which model a task actually needs: whether a cheaper model already clears the bar for routine work, or whether one specific step still needs the frontier model.
Cost and frequency, tracked and reported up. Someone at the firm needs a real number for leadership: what a given skill costs to run, how often it runs, and what outcome it’s tied to. Without that, AI spending reads as a vague IT line item instead of a process with a return.

Skill runs

Produces a draft against the current version of the skill.

Reviewer edits or approves

A human makes the correction the skill didn't yet know to make.

Edit + eval data feed back in

The correction and its eval result get incorporated into the skill itself.

Next run starts closer to correct

The plumbing underneath every skill, regardless of what the skill itself does.

Democratizing tacit knowledge (but not too much)

The most common objection to partnering with a technology vendor on any of this is fair: “I don’t want to hand over my playbook, the standard operating procedures that took years to refine, to whoever’s running the model underneath.”

That worry has gotten louder, not quieter. Microsoft CEO Satya Nadella raised it directly in a widely shared essay this past June:

“The last thing any of us want is a world where every company across every sector is ceding value to a few models that eat everything they see.”
“A small number of AI systems capturing all the economic returns, while entire industries find their knowledge commoditized right out from underneath them.”
— Satya Nadella, Microsoft CEO (source)

His fix is two kinds of capital working together: human judgment, and what he calls “token capital,” the AI capability a firm builds and owns. That token capital is just the human-feedback-and-eval loop covered above, encoded so an entire firm, not just your best few people, can execute your standards, keep improving, and run at LLM cost instead of headcount cost, all without resetting when you swap models.

Sinusoidal’s philosophy: govern what’s common, protect what’s yours

Governing skills well means splitting common infrastructure, covered separately in “Managing Execution Environments and Data Connectors,” from what should never leave your walls: the skill itself. That has to stay written in plain English, not code, so the domain expert who owns the process, not just an engineer, can read it and maintain it directly.

/rfi-follow-up

Step 1: Pull open RFIs from the tracker each morning.

Step 2: Match each RFI to its assigned discipline lead.

Step 3: Flag any RFI missing a response after 5 business days.

Step 4: Post a summary to the #rfi-tracking channel.

Reviewed by: J. Alvarez

Vibe-Coded Automation

import { Pool } from "@internal/db-client";

const pool = new Pool(DB_CONFIG);

async function checkStaleRfis() {

  const { rows } = await pool.query(`

    SELECT r.id FROM tbl_x27_rfiq r

    JOIN cfg_bizcal c ON c.id = r.cal_id

    WHERE DATEDIFF_BIZ(r.last_resp, NOW()) > 5

    AND r.flag_stat NOT IN (2, 7, 9)

`);

  if (!rows.length) return [];

  return rows.map(normalizeRfiRow);

}

A skill that reads like an instruction sheet, not code, is one a domain expert can actually maintain.

That plain-English layer keeps your proprietary IP, your SOPs, checklists, and proposal voice, from dissolving into a vendor’s shared model weights. See what runs underneath to keep it that way, versioned and yours.

If your firm is thinking through what that looks like, we’d welcome the conversation.

Talk to Sinusoidal