Claude for Financial Services: ten agents, two runtimes

Every skill exists twice, and a script keeps the copies honest

The table at the end of the project page explains the design better than any single agent does. Skills are the domain expertise, conventions and step-by-step methods Claude draws on automatically, and they are authored once in the verticals under `plugins/vertical-plugins/<vertical>/skills/`. Each agent then bundles a synced copy of the ones it needs under `plugins/agent-plugins/<slug>/skills/`. That is why every agent plugin is described as self-contained: installing the agent is all you are supposed to need. The cost is a second copy of everything you tune. A skill you edit in the vertical does not change what the agent sees until `scripts/sync-agent-skills.py` has run, and the repository ships no hook that runs it for you. A firm that rewrites a prompt inside a vertical and then reports that the agent still behaves the old way has a sync step missing, not a model problem.

Cowork installs by pasting a URL or dropping a zip

The Cowork route has two doors and both are manual. Open Settings, then Plugins, then Add plugin. From there you can paste the repository URL, `https://github.com/anthropics/financial-services`, and pick agents and verticals from the marketplace list, or upload a zip of any single directory under `plugins/`, for example `plugins/agent-plugins/pitch-agent/`. The zip route is the one worth understanding. Installing a plugin copies files in, so there is no dependency graph, no lockfile and no version recorded alongside what landed in the session. The same is true of the marketplace route, which resolves to the repository's default branch. Updating means doing the operation again, and there is nothing in the repository that tells your team which copy is in the session six months later. The `.claude-plugin/` directory at the top level is what makes the paste-URL route work, and it is the only piece of install machinery in the tree.

The Claude Code route is one marketplace add and one install per plugin

For Claude Code the whole install is a marketplace entry followed by one command per plugin you want:

claude plugin marketplace add anthropics/financial-services
claude plugin install financial-analysis@claude-for-financial-services
claude plugin install pitch-agent@claude-for-financial-services
claude plugin install gl-reconciler@claude-for-financial-services
claude plugin install market-researcher@claude-for-financial-services

Two things about that sequence are deliberate and easy to get wrong. The `@claude-for-financial-services` suffix is the namespace from the marketplace add, and every install needs it. And the repository's own annotated version of this snippet marks the financial-analysis install as the one to do first, because that is the bundle carrying the core skills and the MCP connectors, while the agent installs after it pull in what they need. Once installed, skills fire on their own when relevant and the slash commands are available in the session, among them `/comps`, `/dcf`, `/earnings` and `/ic-memo`. The commands come from `plugins/vertical-plugins/<vertical>/commands/`, which is why the vertical matters even when you only want agents.

The Managed Agents route POSTs an orchestrator to /v1/agents

The second runtime is the one that puts you in charge of the loop. It needs a key in the environment and one script:

export ANTHROPIC_API_KEY=sk-ant-...
scripts/deploy-managed-agent.sh gl-reconciler

What that script does is spelled out in the project text: it resolves file references, uploads the skills, creates the leaf-worker subagents, and POSTs the orchestrator to `/v1/agents`. Every template under `managed-agent-cookbooks/` references the same system prompt and the same skills as its plugin counterpart, which is the promise behind the two-routes-one-source claim. The part nobody else runs is between agents. `scripts/orchestrate.py` is described as a reference event loop that routes `handoff_request` events between agents, and the phrase to hold is through your own orchestration layer. You are writing and running that layer, keeping it alive, deciding what a handoff means and what happens when one fails. The reference loop is a starting point, not something the repository hosts for you.

callable_agents is a Research Preview, and the guidance is per agent

The multi-agent path carries an explicit warning. Subagent delegation, named `callable_agents`, is labelled a Research Preview, and the project points you to the per-agent READMEs for security and handoff guidance rather than giving one document that covers the set. Read that as a boundary rather than a footnote. The orchestrator and its leaf workers are a delegation graph you build, and preview status means the shape of that graph is the part most likely to change under you. For anyone in a regulated environment the more immediate issue is where the guidance lives: it is distributed, one README per agent, so reviewing the whole collection means opening ten files and knowing which of them your installation actually pulled. The tree carries no single threat model and no central checklist, and the connectors make that concrete, since the MCP configuration that wires Claude to terminals, research platforms and document stores sits in the plugin at `plugins/vertical-plugins/financial-analysis/.mcp.json`.

The agents draft, and a qualified professional signs

The most important paragraph in the repository is the one that says what these agents will not do. Nothing in it constitutes investment, legal, tax or accounting advice. The agents draft analyst work product, models, memos, research notes and reconciliations, for review by a qualified professional. They do not make investment recommendations, execute transactions, bind risk, post to a ledger, or approve onboarding, and every output is staged for human sign-off. Read the agent list against that boundary and each one lands in the same place. The GL Reconciler finds breaks, traces root cause and routes for sign-off, it does not post the entry. The KYC Screener parses onboarding documents, runs the rules engine and flags gaps, it does not approve the customer. The Statement Auditor audits LP statements before distribution. Adopting this does not remove a person from the process, it moves where that person's attention goes, and a team expecting a headcount reduction is reading it wrong.

plugins/partner-built/ sits in the same tree as the first-party work

The repository layout has four directories under `plugins/` and one of them is not written by Anthropic. Alongside `agent-plugins/` and `vertical-plugins/` there is `partner-built/`, holding partner-authored plugins from LSEG and S&P Global. There is also `claude-for-msft-365-install/`, which is admin tooling for provisioning the Claude Microsoft 365 add-in, a deployment concern rather than a workflow one. So a review of what an installation contains has to distinguish first-party from partner code, and the README does not draw that line inside the tree. On maintenance, the project is Apache-2.0 with a LICENSE at the root, the last push to the main branch was on 2026-09-21, and there are no GitHub releases at all. Combined with a marketplace add that resolves to the default branch, that means an installed plugin is whatever main held on the day you installed it, and nothing in the repository records a version for you to point an auditor at.

Editorial conclusion

This fits a financial services team that already knows the workflow it wants automated and can name a person who signs the output, since every agent here is built to stop before the decision. It does not fit anyone looking for a library to import, and the subagent delegation that would make multi-agent flows work is a Research Preview. Before you install anything, read the per-agent README for the plugin you want, because that is where the security and handoff guidance lives, and note that the repository publishes no releases, so an install tracks the default branch.

Frequently asked questions

Official sources

1. Official README
2. Project repository