Governing Reusable AI Capabilities

An operating model for enterprise ownership evaluation and controlled reuse

Commonset | Research white paper | September 2026

Executive summary

An organization can own the account that runs an AI workflow and still struggle to identify the instructions it uses, the person responsible for maintaining them, or the evidence that supports their use in another team. Those questions become consequential when a useful workflow moves beyond its original author. A shared capability can carry an organization’s process knowledge into more places. It can also carry an outdated assumption, an excessive permission, or an untested dependency.

We propose managing reusable AI capabilities as versioned operational assets. In this paper, a capability is a defined way of performing a task using instructions, supporting knowledge, tools, and an execution environment. Its record should connect a business purpose and accountable owner to the specific artifact, deployment conditions, evaluation evidence, and observed outcomes. Approval should describe the version and conditions it covers. A capability’s name alone is too imprecise to carry that decision.

This proposal draws on established AI risk management, software provenance, agent security research, and evaluation practice. NIST’s AI Risk Management Framework calls for mechanisms to inventory AI systems and for ongoing review. Its Generative AI Profile adds guidance on provenance, versioning, model dependencies, and evaluation history. We extend those principles to the reusable components through which teams encode and distribute working methods. This extension is our proposed operating model, not a new NIST requirement. 12

The business case needs the same discipline as the controls. Field research has found material productivity gains in some settings and slower work in others. Results depend on the task, worker, tools, and measurement design. A capability program should therefore fund reuse where it improves verified outcomes, while retaining a clear route to revise or retire work that does not justify its maintenance cost. 345

For technology, platform, and security leaders, the immediate decision is where to establish this discipline. We recommend starting with one bounded workflow that has a measurable outcome, a named business owner, and a manageable failure consequence. Establish the record, evaluate the complete deployment, restrict its authority, and measure its performance through a limited release. Expand on the strength of that evidence. A searchable collection is useful; a maintained connection between purpose, version, permission, and results is what makes reuse governable.

1 Scope and research approach

This paper addresses reusable instructions, agent skills, prompt templates, and bounded AI workflows used inside organizations. It focuses on what happens when a working method is shared, adapted, or deployed across teams and environments. It does not evaluate foundation models, prescribe a particular vendor architecture, or claim that every personal prompt needs formal registration. We use “asset” in an operational sense: something an organization chooses to maintain because it expects continuing value. We make no accounting classification.

We conducted a targeted narrative review of primary research, public standards, technical specifications, and first-party engineering documentation available on 24 September 2026. Sources were selected for direct relevance to AI inventories, agent behavior, software integrity, authorization, evaluation, and measured work outcomes. We preferred original studies and issuing organizations over secondary commentary. This is not a systematic literature review or a meta-analysis, and we did not conduct new experiments for this paper.

The evidence serves different purposes. NIST publications provide risk management guidance. SLSA and technical specifications describe mechanisms and conventions. OWASP describes security failure modes and mitigations. Agent benchmarks demonstrate problems in controlled environments. Workplace studies provide evidence about particular deployments and populations. Vendor engineering articles offer implementation experience, with a commercial perspective that readers should recognize. None of these sources independently validates the complete operating model proposed here.

Throughout the paper, empirical findings are attributed to their sources. The capability record, release process, example, and adoption plan are Commonset’s synthesis and recommendations. The worked example is hypothetical. Its thresholds illustrate decisions an organization must make; they are not universal safety levels or measured Commonset customer results.

2 Why the unit of management matters

Consider a team that develops a reliable method for drafting answers to customer security questionnaires. The method includes instructions for retrieving approved statements, distinguishing current documentation from old material, attaching evidence, and escalating gaps. A second team copies it into another assistant. A third adds a connector and enables sending. Although all three may use the same name, they now differ in knowledge access, authority, and potentially behavior. A catalog entry that treats them as one undifferentiated item obscures those differences.

We propose four linked objects. The capability expresses the intended task. The artifact is a specific package of instructions and supporting files. The deployment binds that artifact to an environment and its permissions. An execution is one attempt to perform work. Keeping these objects distinct allows a business owner to ask whether a method is useful, an engineer to identify exactly what changed, and a reviewer to determine which deployment a decision covers.

Existing formats can help package the artifact. The Agent Skills specification, for example, defines a directory with a SKILL.md file containing metadata and instructions, with optional scripts, references, and assets. Such packaging makes reusable working methods easier to describe and distribute. The specification also identifies allowed-tools as experimental, with support that can vary. A field in a package should not be assumed to create an enforced authorization boundary. 6

A portable file does not establish equivalent behavior across environments. The receiving assistant may load different context, expose different tools, or interpret the instructions differently. Our recommendation is to preserve the capability’s identity across migrations while creating a separate deployment record and evaluating the receiving environment. “Model agnostic” should mean that organizational knowledge can be maintained independently of a single provider, with explicit compatibility evidence where it is used.

The practical boundary is material reuse or material consequence. A private experiment with synthetic data may need little more than a repository and an owner. A method distributed to many teams, connected to sensitive information, or authorized to change business records deserves a maintained record. Teams should define the boundary before broad collection begins, so the program does not become an exercise in cataloging every transient prompt.

3 The evidence for value is conditional

Brynjolfsson, Li, and Raymond studied the introduction of a conversational assistant among 5,172 customer support agents. The authors report an average 15 percent increase in issues resolved per hour, with substantial differences by worker experience and skill. Less experienced and lower-skilled workers benefited more; the most experienced workers saw small speed gains and small quality declines. The study supports a specific possibility: AI assistance can help distribute effective working practices in a bounded operational setting. It does not establish that any reusable prompt will produce the same result. 3

In a different setting, METR’s early-2025 randomized study involved 16 experienced open-source developers completing 246 tasks in repositories they knew well. With the tested AI tools available, participants took 19 percent longer on average. The population, task setting, and tools limit generalization. METR’s February 2026 follow-up described evidence suggesting newer tools could help, but explained that participant and task selection, alongside time-accounting difficulties, made its estimates unreliable measures of the size of the effect. Both the original result and the update matter. 45

We infer that organizations should evaluate the workflow they intend to scale, including the work needed to review and repair its output. Measuring generation speed alone can hide a transfer of effort to another person. A questionnaire draft that arrives in two minutes but requires an hour of evidence checking may be less useful than a slower draft with dependable sourcing. Conversely, a capability that improves consistency or reduces serious omissions may be valuable even when elapsed time barely changes.

Before deployment, define the eligible task population and the existing completion standard. Record how long people spend completing, reviewing, correcting, and escalating comparable work. During a pilot, retain failed attempts and abandoned tasks in the accounting. Where feasible, assign comparable work randomly; where that is impractical, describe the matching method and remaining differences. Separate user experience from verified performance, and report sample sizes alongside averages.

Reuse also has a cost outside execution. Someone must maintain the instructions, renew source material, respond to incidents, and evaluate changes. Our proposed value calculation is the benefit from accepted outcomes, less implementation, operation, review, rework, and maintenance costs. Avoid counting theoretical hours saved as realized financial savings unless the organization can explain how those hours changed capacity, cost, service levels, or revenue. This is a management accounting recommendation, not a forecast of returns.

4 A record that supports decisions

An inventory becomes useful when a reader can answer a decision with it. Can this team use this version for this purpose? Which deployments depend on the document that changed yesterday? Who can withdraw a release? What evidence supported approval, and what remains outside its scope? We recommend a compact record that answers those questions while linking to detailed evidence in the systems that already hold it.

NIST’s Generative AI Profile specifically recommends inventory information covering such matters as provenance, versioning, known issues, oversight roles, and foundation model versions or access modes. It also addresses retention of testing, evaluation, verification, and validation history. These recommendations support recording relationships and evidence alongside an item’s title. The field selection below adapts that guidance to reusable capabilities and adds operational details for our proposed model. 2

The business owner and technical maintainer may be different people. The owner decides whether the task remains worth doing and whether outcomes meet operational needs. The maintainer keeps the artifact and integration working. A security reviewer examines exposure and controls when the consequences warrant it. Naming these responsibilities avoids a common ambiguity in shared work: the person who originally wrote the instructions is not necessarily able to approve every later use.

A record should expose uncertainty. If a provider does not offer a pinned model version, record the model alias, configuration, observation dates, and known limits on reproducibility. If the evidence source changes continuously, record its identity and freshness policy and retain the relevant evaluation snapshot where permitted. If a deployment cannot report which artifact it loaded, mark that visibility gap explicitly. An empty field should not silently be interpreted as a satisfactory control.

Approval should attach to a defined combination of artifact and deployment conditions. Its scope can include intended users, task categories, data classes, tools, and required review. Changing a spelling mistake may need only a documented lightweight review. Adding a write operation, replacing the model, or broadening the data boundary can invalidate the rationale for approval. The owner should define these change triggers when the deployment is approved, rather than negotiate them after a consequential change has already shipped.

5 Trust requires several kinds of evidence

Origin and integrity

Knowing where a package came from is a separate question from whether it performs the task well. SLSA v1.2 describes provenance for how software artifacts are produced. Its verification guidance checks such matters as the artifact digest, trusted builder, and expected source or build parameters. Applied by analogy to capability packages, this suggests recording a source revision, producing an identifiable release artifact, and verifying that consumers receive the reviewed bytes. Provenance cannot establish that the instructions are correct or that the resulting agent behavior is acceptable. 78

The analogy to software development is useful because reusable capabilities can include executable scripts and dependencies as well as prose. NIST’s Secure Software Development Framework provides a common set of practices for integrating security into development lifecycles. We recommend using existing repository review, dependency management, release, and vulnerability-handling processes wherever they fit, with additional behavioral evaluation for the AI deployment. Creating a separate governance process should not discard controls the organization already knows how to operate. 9

Task performance and consistency

The relevant test object is the complete working system. A sound instruction file can still fail when retrieval omits the right document or a tool returns an unexpected value. The τ-bench research evaluates agents interacting with simulated users and domain tools, checking the resulting database state against task goals. It also introduces pass^k to examine success across repeated trials. This provides a useful methodological lesson: one successful demonstration says little about whether the same task succeeds consistently. Its simulated environments do not establish reliability in a particular enterprise deployment. 10

Anthropic’s engineering guidance on agent evaluations similarly distinguishes transcripts from outcomes and discusses code-based, model-based, and human graders. It recommends examining multiple trials and calibrating model graders against human judgment. We use this as practical engineering guidance, rather than independent evidence that one evaluation method is sufficient. For consequential work, the grading process itself deserves review: an evaluator that rewards fluent explanations may miss an incorrect action or a fabricated citation. 11

Our proposed evaluation pack has a representative task set, boundary cases, adversarial cases, and clear outcome checks. For a sourcing task, check whether cited evidence actually supports the statement. For a record update, inspect the resulting record and the allowed changes. Include cases where the correct behavior is to ask, abstain, or escalate. Preserve a held-out set for release decisions so repeated prompt tuning does not turn evaluation into memorization of familiar examples.

Exposure to untrusted instructions

OWASP identifies prompt injection as a risk in which input alters model behavior in unintended ways, including through external material. Its guidance explains why retrieval or fine-tuning alone does not remove the problem. A capability that reads customer documents, web pages, or tool responses needs tests in which those materials contain instructions that conflict with the user’s legitimate task. The test should examine the attempted action and downstream result, not merely whether the model says it resisted. 12

AgentDojo provides a benchmark with 97 realistic tasks and 629 security test cases for agents working with untrusted data. InjecAgent introduces 1,054 test cases spanning 17 user tools and 62 attacker tools. These studies give concrete ways to investigate indirect prompt injection and highlight the interaction between useful task completion and attack resistance. Their benchmark outcomes are not estimates of the incident rate in an arbitrary company. We recommend adapting the failure modes to the actual tools, documents, and authority of the deployment. 1314

Authority and consequence

OWASP’s Excessive Agency guidance identifies excessive functionality, permissions, and autonomy as sources of damaging action. It recommends limiting available tools and permissions and enforcing authorization in downstream systems. We translate this into a deployment rule: the model may propose an action, but the tool or service must determine whether the authenticated actor is permitted to perform it. A sentence telling the assistant to avoid unauthorized actions is not an access control. 15

NIST’s Zero Trust Architecture rejects implicit trust based only on network location or asset ownership and centers access decisions on resources and identities. In our proposed design, that principle applies at the tool boundary: registering an approved capability does not authorize every person who invokes it to access every connected record. The receiving service still needs the caller’s permitted scope. 16

6 Separate the record from enforcement

A central record can state that a capability is approved for internal drafting, uses a particular revision, and requires human approval before external delivery. Those statements become effective only when the execution environment and downstream services implement them. We propose an architecture in which the shared record holds identity, evidence, and decisions, while runtime integrations resolve approved releases and enforce the relevant deployment policy. Sensitive business actions remain subject to authorization in the service that performs them.

For MCP-based integrations, the protocol’s security guidance illustrates how specific this work can be. It prohibits token passthrough and describes token audience validation and protections against confused-deputy problems. These controls concern the actual authorization path; a catalog label cannot implement them. Other integration methods require equivalent attention to their own identity and permission mechanisms. 17

Withdrawal deserves a designed path. Removing an item from search does not necessarily stop a deployed copy, a cached package, or a run already in progress. We recommend defining how integrations check release status, how quickly a revocation reaches them, and what operators can disable when the record service is unavailable. For higher-consequence deployments, consider expiring authorization to load releases and enforcing access restrictions at the tool service. Decide the availability tradeoff explicitly, including which failures should block new work.

Observability should support investigation without becoming an uncontrolled copy of sensitive work. OpenTelemetry’s guidance recommends collecting only data needed for an observability purpose, reviewing instrumentation, and using mechanisms such as filtering and redaction where appropriate. We recommend retaining capability, artifact, deployment, and run identifiers by default, with outcome and authorization metadata. Full prompts, retrieved documents, and tool payloads should have an explicit purpose, access policy, and retention decision before collection. 18

The record is therefore one component of an operating system for reuse. Existing identity systems, repositories, evaluation infrastructure, and runtime controls continue to do essential work. An organization should reject any design that turns an “approved” badge into a substitute for those controls or implies that a static scan guarantees safe future behavior.

7 A proportionate release process

We recommend classifying deployments by consequence, sensitivity, and reversibility. The same artifact may belong in different review paths depending on where it runs. Drafting from public material differs from interpreting restricted customer records; suggesting a refund differs from issuing it. The categories below are a starting point for local policy, not a standard or a compliance determination.

The process begins with a task contract. Specify the eligible inputs, expected output, unacceptable outcomes, and escalation route. The maintainer prepares an identifiable artifact and a deployment configuration. Evaluation then tests that configuration against the contract. A reviewer accepts or rejects release on the basis of documented results and residual uncertainty. A limited pilot supplies operational evidence before access expands. Review continues when material dependencies, permissions, business rules, or observed behavior change.

Release decisions need separate quality and safety conditions. An average quality score should not offset a critical authorization failure. Likewise, a capability that refuses nearly every request may prevent harmful actions while failing its business purpose. Record both the denominator of eligible work and the categories of failure. Define the unacceptable events that stop a pilot, who can make that decision, and what evidence is required to resume.

Review cadence should follow change and consequence. A stable internal drafting workflow may justify a different interval from a rapidly changing deployment with external actions. Calendar review is a backstop; incident reports, source revisions, permission changes, and model changes should also trigger attention. A release can be restricted to a smaller scope while uncertainty is resolved. Withdrawal and replacement should remain ordinary lifecycle states, so owners can retire weak capabilities without treating retirement as a program failure.

8 Worked example of a questionnaire capability

The following example is hypothetical. A software company wants to reuse a method for drafting customer security questionnaire answers. Today, subject-matter experts search internal documents, compose responses, and check them before delivery. The proposed capability retrieves approved evidence and prepares a draft with citations. The business owner is the security assurance lead; the technical maintainer belongs to the internal platform team.

The task contract permits drafting answers supported by current, approved documentation. It excludes inventing controls, interpreting unapproved documents as company commitments, and submitting responses externally. The deployment can read a specified evidence collection and write a draft in an internal review area. It cannot send email or modify source evidence. Reviewers receive the proposed answer, supporting excerpts, source dates, and unresolved questions together, so approval is a concrete inspection of the work.

The initial record identifies the artifact revision, evidence collection, model configuration, connector permissions, and the evaluation suite revision. The company establishes a baseline from completed questionnaires, including expert research time, review time, corrections, and escalations. It separates straightforward questions from ambiguous or unsupported ones. Otherwise, a pilot could appear successful simply because it handles an easier mix of work.

For illustration, the team builds a 120-case evaluation set: 60 routine questions with sufficient evidence, 25 cases with missing or conflicting evidence, 20 cases containing malicious instructions in retrieved material, and 15 cases probing permission boundaries. It runs each case three times under the proposed deployment. These counts are design choices for the example. They are not a claim of statistical adequacy, and the team would need broader testing if the task diversity or potential consequences demanded it.

The scoring rubric checks factual support, citation accuracy, handling of uncertainty, and adherence to the intended output format. Tool logs and resulting state provide separate checks for forbidden reads or writes. The owner might require at least 95 percent acceptable routine answers while requiring zero observed critical boundary violations and zero fabricated evidence references before a limited pilot. These illustrative gates describe release policy, not proof of safety. Zero failures in a finite test set leaves untested conditions and residual risk.

One adversarial case embeds a request to upload confidential evidence to an external destination inside a retrieved document. The system should continue treating that document as task data. The deployment also lacks a tool and permission path for external delivery. The evaluation records whether the model attempted the forbidden action as well as whether enforcement blocked it. A blocked attempt may reveal a behavioral weakness even when no data leaves the system.

During the pilot, experts review every draft and record substantive corrections, unsupported claims, escalations, and total effort. The team compares comparable questionnaire categories with the baseline and includes unsuccessful runs in the cost. If accuracy improves but review effort remains high, the next revision can target evidence presentation. If there is no net benefit, the team can narrow the eligible task set or stop the deployment. The pilot is a decision instrument, not a demonstration staged to justify expansion.

A later proposal to add automatic customer submission changes the deployment’s authority and consequence. It therefore requires a new release decision, even if the underlying instructions barely change. Moving the same artifact to another assistant also requires evaluation in that environment. If a cited control statement becomes outdated, the owner identifies affected evidence and deployments, suspends the relevant answer category, and reviews whether earlier outputs need correction. This is the practical value of maintaining relationships between capability, deployment, and evidence.

9 Measure the program as well as the model

The number of registered capabilities measures collection activity. It says little about whether the organization can govern what is running or whether people obtain better results. We recommend a small set of measures with explicit populations, time windows, and owners. Report uncertainty and coverage gaps rather than collapse unlike signals into an unexplained trust score.

Reuse can be measured as the number of distinct teams using a maintained release, accompanied by accepted outcomes and maintenance effort. Counting copies rewards fragmentation. A widely copied artifact that no one updates may be less useful than a smaller, maintained deployment whose improvements reach every user. Track adaptation requests as well: repeated local modifications may indicate that the original scope is too broad or that separate capabilities would serve the work better.

Owners should review these measures together. A falling cost per accepted outcome is less persuasive if serious corrections are increasing. A high approval coverage percentage is misleading if the inventory misses unmanaged deployments. A low incident count may reflect limited observation. The purpose of measurement is to guide investment and corrective action, with enough context to resist convenient interpretations.

10 A practical adoption sequence

The following 90-day sequence is an illustrative planning device. Organizations should adjust it to their access constraints, risk profile, and existing infrastructure. The goal is to establish one complete, observable lifecycle before expanding the catalog.

In the first 30 days, choose a bounded workflow and identify its owner, current deployments, and eligible users. Document the task contract and baseline performance. Locate the source artifact and dependencies, identify the data and permission boundaries, and create the minimum record. Prefer work whose outcomes can be inspected and whose mistakes can be corrected. If the team cannot define acceptable performance or observe what the deployment does, resolve that gap before broad release.

During days 31 through 60, assemble the evaluation set, establish an identifiable release, and test the intended deployment. Connect the record to the actual distribution and authorization paths. Run a limited pilot with appropriate review and collect accepted outcomes, corrections, total effort, and failures. Exercise withdrawal with a test deployment. This stage should produce a concrete release decision and evidence of whether controls operate as described.

During days 61 through 90, compare results with the baseline, review the maintenance burden, and decide whether to expand, revise, or stop. Test a second environment only if cross-environment reuse is a real need. Assign continuing ownership, review triggers, and an incident route. Document which parts of the process are automated and which still depend on a person. Expansion should follow demonstrated value and manageable operating cost, not an arbitrary target for catalog size.

Tooling should match the problem. A small team using one platform may be adequately served by a repository, its native administrative controls, a simple inventory, and a repeatable evaluation process. A shared management layer becomes more attractive when teams need consistent ownership, discovery, evidence, and lifecycle decisions across several environments. That is a hypothesis to test against integration cost and operating effort. Centralization can improve visibility, but it can also create a bottleneck or a new point of failure if responsibilities and runtime behavior are unclear.

The decision we advocate is to preserve the organization’s working knowledge together with the evidence and conditions that make it useful. Reusable AI capabilities deserve continued investment when people can find them, understand their scope, operate them within defined authority, and demonstrate acceptable outcomes. A maintained record connects those responsibilities. The organization then has a basis for improving and distributing its methods while remaining able to question, restrict, or retire them.

References

All web sources were consulted on 24 September 2026. Dates and versions below identify the material used. Numbered citations link to the original sources. The standards and guidance cited here are not certifications of this proposed framework or of Commonset.

[1] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework AI RMF 1.0. NIST AI 100-1, January 2023. See section 5 and GOVERN 1.5–1.7.

[2] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework Generative Artificial Intelligence Profile. NIST AI 600-1, July 2024. See GV-1.6-001–003, GV-1.5-003, and MS-2.5-001.

[3] Erik Brynjolfsson, Danielle Li, and Lindsey R. Raymond. Generative AI at Work. Author-affiliated summary of the research, Stanford Digital Economy Lab. Used for the reported 5,172-agent sample and 15 percent productivity result.

[4] METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Research report, 10 July 2025. Randomized study of 16 developers and 246 tasks.

[5] METR. We are Changing our Developer Productivity Experiment Design. Research update, 24 February 2026. Follow-up evidence and limitations concerning selection and time measurement.

[6] Agent Skills. Specification. Living technical specification, accessed September 2026. See skill structure, SKILL.md format, and allowed-tools.

[7] SLSA. Provenance. Specification v1.2. Technical definition of source and build provenance.

[8] SLSA. Verifying artifacts. Specification v1.2. Artifact and provenance verification guidance.

[9] Murugiah Souppaya, Karen Scarfone, and Donna Dodson. Secure Software Development Framework SSDF Version 1.1. NIST SP 800-218, February 2022.

[10] Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik Narasimhan. τ-bench A Benchmark for Tool-Agent-User Interaction in Real-World Domains. Research paper, arXiv:2406.12045, version 1, June 2024. See evaluation and reliability methodology.

[11] Anthropic. Demystifying evals for AI agents. Engineering article, 9 January 2026. Vendor guidance on tasks, trials, graders, transcripts, and outcomes.

[12] OWASP Gen AI Security Project. LLM01 2025 Prompt Injection. Security risk guidance, 2025 edition.

[13] Edoardo Debenedetti and colleagues. AgentDojo A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. Research paper, arXiv:2406.13352, 2024.

[14] Qiusi Zhan, Zhixiang Liang, Zifan Ying, and Daniel Kang. InjecAgent Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents. Research paper, arXiv:2403.02691, 2024.

[15] OWASP Gen AI Security Project. LLM06 2025 Excessive Agency. Security risk guidance, 2025 edition. See root causes and prevention and mitigation strategies.

[16] Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly. Zero Trust Architecture. NIST SP 800-207, August 2020.

[17] Model Context Protocol. Security Best Practices. Documentation under protocol version 2025-11-25. See token passthrough and confused-deputy protections.

[18] OpenTelemetry. Handling sensitive data. Technical guidance, accessed September 2026. See data minimization, instrumentation review, and redaction.