Plugins and Agents: Packaging AI Your Finance Firm Can Deploy

A brilliant skill on one laptop is worth almost nothing. This is where most firms stall, and the reason is not technical. A skill on one person's machine has all the properties of a spreadsheet macro written by someone who has since left. Nobody else knows it exists, there is no version so two people run different things, and when it breaks the person who wrote it is on holiday.

What packaging changes

A plugin is a folder that bundles the skills, the slash commands, the connector configuration and the manifest that names and versions the lot. Install it and everything arrives together, configured the same way, at a known version. That is the difference between a clever colleague and a capability the firm owns. Packaging changes five things:

• Discovery. A catalogue people can browse, rather than folklore.
• Versioning. Two runs are the same run because they are the same version.
• Configuration. Connectors ship with the skills that need them.
• Review. A change is a diff, and a diff can be approved.
• Withdrawal. You can pull a bad version. You cannot pull a habit.

Everything in a plugin is markdown and JSON. There is no compilation step, which means your compliance team can read the artefact you are shipping. No credentials sit in the artefact, and one version is what a rollback rolls back to.

The anatomy of a plugin

A plugin is five directories and one manifest. The plugin.json carries identity and version in four fields: name, version, description, author. That is what makes it installable and a rollback possible. The skills/ directory holds the workflows from capturing a process that runs the same way every time, which Claude loads when a task matches the description in the frontmatter. The commands/ directory holds explicit slash actions. The .mcp.json ships the connectors from connecting AI to the systems you already govern alongside the skills that depend on them. And hooks/ holds shell commands run at fixed lifecycle points.

Commands are deliberately thin. A command is a doorbell: all the method lives in the skill, so the skill can be improved without touching the command, and other skills can call the same method. Keep commands boring. If you find logic creeping into one, it belongs in a skill.

Distribution is a marketplace: one JSON file placed at a known path in a repository your team can reach, private or public. One install, not five setup steps that three people get slightly wrong.

Two kinds of plugin

The distinction is whether you are handing someone a toolkit or handing them a colleague. A vertical plugin is skills and commands for a discipline: you reach for what you want, invoking the memo, the returns analysis or the checklist. It is best when the work varies and the person running it knows what comes next, and most firms start here. An agent plugin is a named worker owning a workflow end to end: give it a brief and it runs the sequence, invoking whichever skills it needs.

The honest sequencing is to start with a vertical bundle, then move to an agent once twelve clean cycles say the sequence is fixed. If you cannot write down the sequence, it is not an agent yet.

The anatomy of an agent

An agent definition is a markdown file with frontmatter carrying a name, a description that says precisely when to use it and when not to, and a tools line listing what it is permitted to touch. Write the scope as named artefacts, not "help with pitching". Write the workflow as numbered steps naming which skill each one invokes, so it reads as an auditable procedure. Write the guardrails as absolutes, not preferences.

The guardrail section is where regulated firms should spend their time. State constraints as facts, not wishes. The wish is that the agent should not send anything externally. The fact is that the agent holds no messaging or email tool. The test: delete the sentence, and ask whether the constraint is still true. An agent that cannot send anything cannot send to a client by accident.

Default deny, in practice

The clearest expression of the principle is a real manifest in the reference library. The gl-reconciler orchestrator sets its toolset default to enabled: false, then grants three capabilities by name: read, grep, glob. No write, no shell. An orchestrator that cannot execute cannot be talked into executing. Its connectors are read-only servers, and their URLs come from the environment rather than the artefact. The orchestrator never reads counterparty documents directly: the reading is delegated to a subagent that holds no MCP servers at all.

The question to ask of any agent before it runs unattended is not whether it has been told not to do the dangerous thing. It is which line in which file makes the dangerous thing impossible, and who reviews that line.

Hooks: the only part that enforces

Everything else in a plugin asks the model to behave. A hook is a shell command the runtime executes at a fixed lifecycle point, whatever the model intended. For a regulated firm it is the most important directory in the folder, and it is empty in most reference plugins, which is why it gets skipped. A PreToolUse hook that blocks writes outside an approved path is a control, not an instruction: it runs whether or not the model was persuaded. A PostToolUse hook writes every call to your log. A UserPromptSubmit hook injects the current valuation date so nobody must remember to.

The distinction this whole subject turns on is that a prompt asks the model not to do the thing and usually works, a tools line means the model cannot do the thing at all, and a hook runs your code before it happens and can refuse with a reason. Use all three. They fail differently, which is the point. Note that hooks run as arbitrary code with your user's permissions, so review them as you would any dependency, and remember PostToolUse cannot undo: by the time it fires the file is written.

Govern it like software

The moment a plugin is installed by somebody who did not write it, you have a supply chain. It is small and internal, and it is a supply chain nonetheless. This is a problem your engineering organisation already solved: version control with branch protection, a named reviewer who is not the author, a version bump on every functional change, testing against synthetic data before production data, and a documented rollback tried at least once.

The one thing worth adding is that some changes to a plugin are changes to a control. Editing a template is not. Editing CHECKS.md, widening a tools line or adding a write-capable connector is, and those should route to whoever signs off control changes today. Where this leads next is the substrate underneath, covered in defensible prompting and the infrastructure under finance AI, part of the AI field guide for regulated finance.

To go deeper, download the five-part finance series or send us a workflow, and we will show you what a first internal plugin looks like.