A procurement analyst develops an AI-assisted way to prepare a supplier renewal review. It finds the current agreement, reconciles spending, checks the renewal date, and assembles a briefing. Getting it right has involved experiments, corrections, and decisions about which sources to trust. A colleague wants to use it. If the handover consists of a long prompt, several attachments, and instructions for moving results between applications, much of that development work remains locked inside the analyst’s personal routine.
I think sharing tested capabilities is the best way to make corporate AI investment useful across the workforce. A successful experiment should become something colleagues can use and improve without reconstructing its creator’s process. Skills, plugins, connected tools, and shared agents give us several ways to achieve that. Cowork-style environments provide the place where those capabilities can come together around an employee’s task. I see this becoming the normal way people work with enterprise software, across business functions and levels of technical expertise.
The distinction matters because distributing access to a model leaves a considerable amount of work unfinished. People still need the right information, a workable method, and some means of producing a result. Training everyone to become better at prompting helps, but requiring every employee to rediscover an effective workflow is an expensive approach to organizational learning.
Prompt libraries, shared conversations, and notebooks are useful starting points. They make experiments inspectable and help colleagues understand how a result was produced. Source repositories go further by preserving changes and supporting joint development. Their weakness as the final delivery mechanism is the work they leave to the recipient. A purchasing manager should be able to use a tested renewal review without installing a development environment or learning which notebook cells to run.
A skill captures more of that method. The open Agent Skills format organizes instructions and supporting material around a SKILL.md file, with optional scripts, references, and templates. For the supplier review, a skill could explain how to identify the governing agreement, which spending periods to compare, and what the briefing must contain. Examples can show how to handle an amendment that changes the renewal terms. The assistant receives a reusable procedure at the point of work, and the analyst’s refinements become available to the next person.
Shared knowledge serves a different purpose. A searchable policy collection or retrieval service can supply current purchasing rules and approved supplier information. The skill explains how to use that evidence. Both matter: knowing the policy does not establish the sequence for a renewal review, while a well-written procedure becomes unreliable if it relies on an obsolete agreement. Organizations should maintain authoritative information separately from the reusable methods that consume it.
Model Context Protocol, or MCP, addresses access to capabilities. An MCP server can expose executable tools, information resources, and reusable prompts to compatible AI applications. A procurement service might offer operations for retrieving an agreement or calculating spending for a supplier. Once available through an approved connection, those operations can support several skills and assistants. The integration effort can therefore benefit many workflows rather than being repeated inside each one.
Ordinary APIs and shared code libraries remain valuable here. An API can provide the underlying purchasing operation; a library can implement a tested calculation. MCP gives compatible AI clients a standard way to discover and invoke exposed capabilities. Choosing it does not require rebuilding the business service, and a deterministic calculation should remain deterministic when an assistant calls it.
A dedicated agent shares a larger unit of work. A supplier-risk team might operate an agent that gathers evidence, applies its assessment process, requests missing information, and returns a documented review. That team can maintain the service centrally, including its tools and operating procedures. Colleagues receive access to the specialist capability without having to install its implementation. This is especially useful when a task needs sustained execution, specialized resources, or a clearly accountable service owner.
Agent2Agent, or A2A, supplies a protocol for communicating with such agents. It describes capabilities through an Agent Card and supports messages, stateful tasks, status updates, and returned artifacts. An employee’s assistant could commission the supplier-risk review and incorporate its result into the renewal briefing. The specialist agent’s internal implementation can remain private. This is a different handoff from calling a spending calculation: the receiving agent takes on a task and manages its own execution. A2A provides the communication structure; the organization still defines what a satisfactory review contains.
Plugins make related capabilities easier to distribute. A procurement plugin could package renewal-review skills, document templates, and connections to purchasing tools. The user installs or receives a useful set of capabilities for their role. A plugin is a distribution unit, while a dedicated agent is an executing service; a plugin can help an assistant reach that service. These options reinforce one another.
The product direction is already visible. Microsoft documents plugins for Copilot Cowork that contain skills, connectors, or both, including administrative deployment. Anthropic’s Claude plugins can bundle skills, connectors, and sub-agents, with organizational sharing controls. OpenAI’s skills and plugins similarly combine reusable methods with connected tools. These are practical mechanisms for distributing what a team has learned about doing useful work with AI.
There is a strong architectural reason to preserve a common source for that work. I would keep the core instructions, templates, and tests under version control, then produce and validate packages for the environments employees actually use. Shared formats make reuse easier, but each host still needs the appropriate packaging, tool mappings, and execution tests. A skill that depends on a particular script runtime or connector needs those dependencies available in its destination. Maintaining one source and testing its supported targets is a better investment than allowing several manually copied versions to drift apart.
In the supplier example, the employee could ask for a renewal briefing and receive a reviewable document. A skill would guide the analysis, connected services would provide current records, and a specialist agent could perform the risk assessment. A conventional workflow could then route the approved recommendation through the purchasing process. Durable workflow engines remain the right home for transaction state and mandatory approvals. The cowork environment coordinates preparation and handles the conversation around exceptions.
This also explains why sharing the testing work matters so much. The creator’s most useful discoveries often concern what goes wrong: an unsigned agreement mistaken for the current contract, spending assigned to the wrong subsidiary, or a missing renewal date presented as a confident answer. I would turn those discoveries into reusable test cases alongside the capability, using synthetic or appropriately deidentified material. Another team should inherit the lessons as well as the instructions.
Anthropic’s guidance on agent evaluations distinguishes the agent’s account of its actions from the outcome actually achieved, and describes combining automated checks with model-based and human assessment. For our review, the tests should establish that the correct agreement was selected, amounts reconcile, and missing evidence remains visible. A procurement specialist can judge the usefulness of the recommendation. Those checks should be repeated when the instructions, model, tools, or runtime change.
Distributors of shared prompts and skills must monitor results in use and rerun evaluations regularly as models and supporting tools evolve. Each release needs an owner, version, and a way to update or withdraw deteriorating capabilities and notify users. An internal catalog should make the capability discoverable in the tools people use, with a working example and a clear route for feedback. A directory full of abandoned experiments simply creates another search problem.
Access controls belong in this design from the beginning. Sharing a review skill need not expose every supplier contract, and distributing a plugin should not confer the author’s credentials. The services accepting requests must enforce the user’s or explicitly assigned service identity’s authority. Approval rules should also be enforced where transactions occur. That makes broad distribution compatible with restricted information and responsibilities, instead of making personal access to a particular expert the unofficial control mechanism.
The economics are compelling. Development and testing have costs; manual handovers make every recipient pay part of those costs again. A maintained capability allows subsequent users to benefit from the original investment, while their feedback improves the same asset. Specialists still handle difficult cases, but routine preparation no longer depends on their availability. Useful measures include the effort required for a second team to adopt the capability and the employee time needed to produce an acceptable result, including review and correction.
Cowork-style tools provide the working environment this approach needs. Copilot Cowork carries out tasks across Microsoft 365. ChatGPT Work uses files, plugins, and approved tools to produce reviewable results while the user follows progress and redirects the work. Claude Cowork provides another environment for using the shared capabilities described above. My conclusion from this direction is that the task will increasingly organize the employee’s experience of software.
That has consequences well beyond IT. Finance staff need reconciled explanations of variances. HR teams need current policy applied to particular circumstances. Sales teams need account material assembled into a credible proposal. A supervisor on a shop floor may need a shift handover drawn from maintenance records and production events, accessed through a phone or voice interface. Each role needs different capabilities, but none should require the employee to become the integration layer between its systems.
People will still use spreadsheets, specialist applications, and well-designed forms where those are the most effective interfaces. Their expertise will remain essential to defining the task and judging the result. Cowork tools should make that judgment easier by bringing the relevant material together and performing the preparation. This is why I regard them as a future working environment for every worker, with capabilities adapted to the work each person actually does.
I would make distribution part of the completion criteria for a successful AI pilot. Before declaring success, put the capability in the hands of a second team, supply its tested release, and observe whether they can produce useful work without the original developer guiding every step. Fund the ownership and maintenance needed to keep it usable. An organization begins to capture the value of its experimentation when what one person has learned becomes something other people can reliably put to work.
