Portable Intelligence: What Plugins Are and How Marketing Teams Can Use Them

Marketing teams can share an agent workflow only when they can share more than its instructions. A reporting skill may depend on a particular tool schema, account permissions, a server process, local software, and a review step before anything is sent to a client. Packaging helps teams distribute these parts together, but it does not make them interchangeable across platforms or keep every installation on the same version.

That distinction is the point of this guide. A plugin is a host-specific package for capabilities such as skills, tools, and hooks. Some of the knowledge inside it can travel; the package, connections, and operating rules still need adaptation and testing on each host.

The practical aim of this guide is to move a useful experiment into a supported team capability: keep the workflow understandable, grant only the access it needs, make changes reviewable, and give people a clear way to update or remove it. This builds on the series’ guides to skills, agent architecture, tools and MCP, agent maintenance, and the enterprise adoption framework.

Start with the workflow, not the package

Package the series’ weekly-performance-review workflow: approved client accounts, completed-week comparison, reviewed metric definitions, evidence-linked findings, and a checked private draft. The skill carries the common procedure. A host package supplies discovery and connections; each installation binds its own permitted account scope and destination. A practitioner approves external client delivery under this workflow’s policy.

Those are separate responsibilities. The skill carries the procedure and reporting standard. An MCP server or other tool connection supplies data access. Credentials and account permissions determine which data the user can see. A hook can run a deterministic step at a supported point in the host’s lifecycle. The plugin packages some of those components and helps distribute them. It does not supply the team’s credentials, guarantee that a connection is authorized, validate every conclusion, or make an external action safe by default.

This is why “install it and it works on your machine” is too strong. The package can be shared, while each installation still depends on its host version, operating system, network, data source, permissions, and local dependencies. The benefit is a repeatable starting point and a managed update path, not identical execution in every environment.

What the package contains

At its simplest, a plugin is a directory with a manifest and optional components arranged for a particular host. A manifest identifies the package; skills provide instructions; MCP configuration describes connections; hooks run actions at host-defined lifecycle events. Some formats also support agents, interface metadata, assets, or other integrations. The contents matter because plugins can include executable code, not just prose.

The current layouts differ. Claude Code’s manifest is .claude-plugin/plugin.json, with component directories such as skills/, agents/, and hooks/, plus .mcp.json for MCP servers. OpenAI’s current Agent Plugins package uses a root plugin.json, skills/, and mcp.json; it can include OpenAI-specific extension metadata, and .codex-plugin/plugin.json remains a compatibility option. These names are similar enough to invite assumptions and different enough that you should follow the host’s own packaging guide. Claude Code’s plugin layout and OpenAI’s package guide document their respective structures.

Component	Claude Code plugin	OpenAI Agent Plugin	What can travel
Manifest	.claude-plugin/plugin.json	Root plugin.json; .codex-plugin/plugin.json is supported for compatibility	Package identity and version are conceptually portable; manifest fields and discovery rules are host-specific.
Skill	skills/<name>/SKILL.md	skills/<name>/SKILL.md	Instructions and reference material can often be reused. Frontmatter, available tools, invocation, and dependencies still need host checks.
MCP connection	.mcp.json	mcp.json	MCP is a shared protocol. Configuration shape, authentication, server runtime, and available tools still need validation.
Hooks	hooks/hooks.json with host lifecycle events	Hook support is surface-dependent; Codex requires local scripts and user trust, and hook-containing plugins are ineligible for its public directory	Event names, command execution, deduplication, and permission behavior are not portable assumptions.
Agents and integrations	Supports host-specific components such as agents and LSP servers	Package capabilities are defined by the current plugin format and surface	Do not assume a Claude agent, Codex subagent, app mapping, or UI element has a one-to-one equivalent.

The table reflects documentation checked on 21 October 2026, not tests against named client builds. The package version in a manifest is also not the host application version. A compatibility record for a real team release should name both, along with the platform surface, operating system, tested components, and test date. OpenAI’s plugin architecture describes how one package can include skills, tools, and surface-dependent behavior; its skill guide explains the role of skill instructions and supporting files.

Portability has layers

The most reusable part of a plugin is often its domain knowledge: the KPI definitions, audit checklist, brand rules, output format, or decision procedure in a skill. Markdown can move easily. Whether it works well after moving depends on assumptions hidden in the instructions. A skill that names a tool only available on one host, expects a particular account structure, or relies on a local script is not portable just because the file is Markdown.

MCP gives teams a common protocol for exposing tools and data, but a shared protocol does not make the whole connection identical. The server must exist, the host must support the relevant transport, authentication must be configured, and the server’s tools must match the skill’s expectations. A plugin can declare or package connection details; it cannot safely carry a user’s secret credentials as reusable team configuration.

Hooks and executable components need even more care. They are tied to host events and local execution rules. In Claude Code, hooks and MCP server processes can run with the user’s privileges, and plugin instructions enter the model’s context. The installed package therefore has both code and instruction risks. Review the source and permissions before installation, including the commands a hook starts and the servers an MCP configuration points to. Anthropic’s security guidance describes these execution paths and the review steps.

For a reporting workflow, begin with read-only access to a test account or synthetic data. Let the skill produce a draft. For this pilot, keep external client delivery behind practitioner approval and leave budget and campaign changes unavailable. The checked draft can return to its configured private destination; other workflows need their own explicit approval policies. If an approved hook sends a message, make it idempotent: retries or overlapping events should not send duplicates. Record what was sent, where, by whom, and from which package version. A hook firing is an event, not proof that the complete workflow ran exactly once.

From experiment to team capability

Keep a workflow as standalone files while one person or one project is exploring it. Standalone files can be committed to version control and shared; they do not need a plugin to be versioned. Package the workflow when teammates need a clearer installation path, a discoverable catalogue entry, or a coordinated release. Claude Code’s documentation makes this distinction directly: standalone skills, agents, hooks, and MCP configuration remain useful, while a plugin groups them for sharing, multi-project use, or versioned releases.

The Enterprise AI Adoption Framework supplies the organisational route: sandbox, promotion, catalogue, and education. Packaging adds a specific release job within that route: name dependencies, test each supported host, and document installation, invocation, updates, and removal. Approval of the capability still belongs to the organisation’s review process.

A catalogue is not a safety boundary by itself. Review and managed settings determine what is allowed. A package owner must still respond to broken dependencies, security findings, and data-source changes. Users may not update at the same time, so a release does not guarantee that every person is running the same version. State the supported version, publish changes, set an update expectation, and provide a way to revoke or disable a release. Claude Code documents managed controls for marketplace sources and required or blocked plugins; OpenAI documents its own installation and distribution surfaces. Their governance mechanisms should be checked separately in the current host documentation.

One reporting workflow, two host packages

Use the same reference skill and the retrieval contract on both hosts. The package wrapper and local bindings change; the evidence requirements and client-delivery policy do not.

For Claude Code, the package outline starts with .claude-plugin/plugin.json, skills/weekly-performance-review/SKILL.md, and .mcp.json. Add hooks/hooks.json only if a deterministic lifecycle action is necessary and tested. For OpenAI’s Agent Plugin format, use a root plugin.json, the same skill directory, and mcp.json; add only the OpenAI-specific metadata or components required by the target surface. This is a pair of packaging outlines, not two tested implementations.

For each host, record the plugin package version and the exact host client/version you tested. Test installation and removal, skill discovery, missing or malformed inputs, permissions, authentication expiry, empty and partial datasets, tool failure, retries, hook duplication, and the approval boundary. Confirm that recommendations retain source evidence, the private draft uses its permitted destination, and no external client delivery occurs before practitioner approval. Re-run these checks after changing the skill, tool schema, server, host version, or marketplace source. A JSON file that parses is not evidence that the workflow works.

Use the shared evaluation method for analysis quality and consistency; this compatibility record adds host-specific installation, invocation, authentication, and delivery evidence.

This test record also prevents a common update problem. Bumping the package version tells users that a release changed; it does not force every installation to update or prove that the new version behaves the same across hosts. Keep release notes concise, pin or record server dependencies where possible, and retain a rollback path.

Marketing workflows that fit the pattern

The reporting workflow is only one candidate. The same packaging model can support several kinds of repeatable work, provided the team keeps the boundaries visible:

• Campaign audits: check UTM conventions, event tracking, bid settings, and creative requirements against an agreed checklist. Return evidence and proposed fixes for review; do not change live campaigns automatically.
• Technical SEO and page speed: gather diagnostics, inspect schema, and prepare a prioritized engineering ticket. Treat recommendations as proposals and validate them in the site’s normal release process.
• Content repurposing: turn an approved source into channel-specific drafts using the team’s tone and format rules. Keep publishing permission separate from drafting.
• Competitive intelligence: organize public ad-library and search observations into a dated comparison or battlecard. Distinguish observed material from interpretation and avoid inferring private targeting data.
• Ad creative development: generate variants from a brief, check required lengths and brand rules, and compare them with approved performance data. Require human review before upload or launch.

These examples show why packaging can be valuable without implying that the plugin itself guarantees quality. The reusable asset is a well-defined workflow with clear inputs, evidence, and review points. The plugin is one way to distribute and maintain that asset.

A practical first release

Choose one workflow that at least two people need and whose outcome can be checked. Write down its input, expected output, data sources, permissions, prerequisites, failure cases, and prohibited actions. Prototype it with the smallest useful skill and read-only tools. Keep outputs as drafts until people have checked them against known cases.

Then create one host package, validate the manifest using the host’s tools, install it in a clean environment, and ask a colleague to follow the documentation without help. Record the exact client version and what passed. Add only the second host after the first version has a reliable workflow and test cases; adapt the manifest, connection file, hooks, and authentication for that host instead of copying the directory and assuming compatibility.

Before the catalogue entry is approved, give the package an owner, version, change log, support contact, permissions summary, update path, and removal procedure. Keep the package focused. A bundle of unrelated skills and tools makes review harder and gives users more surface area than the workflow needs.

The point of portable intelligence

Plugins make team workflows easier to package, discover, install, and update. They do not erase the differences between agent hosts, supply authorization, or ensure that each installation behaves identically. Treat portability as a set of tested boundaries: preserve the domain knowledge where it transfers, adapt the wrapper and connections, and verify every host-specific behavior that can affect data or external actions.

For marketing teams, that is enough to make plugins useful. A proven reporting procedure, audit standard, or creative review process can move from one practitioner’s experiment into a maintained team capability. The path runs through a sandbox, a reviewed release, a catalogue, and ongoing support. The package carries the workflow; the organization remains responsible for the permissions, evidence, and judgment around it. The final article, The Deterministic Core, is a technical companion to consult when implementing its search, ranking, scheduling, and memory operations.

Further reading

• Claude Code plugins: create and test a package
• Claude Code plugin security and trust
• OpenAI Agent Plugins: package a plugin
• OpenAI Agent Plugins: architecture
• OpenAI Agent Plugins: build skills