The Architecture: One Workflow, Two Surfaces, Several Trust Boundaries
The central architectural question in anthropics/financial-services is how one financial workflow can remain recognizable when it moves from an interactive plugin into a headless service. The answer is not a single monolithic agent. It is a set of layers with different owners: vertical plugins supply reusable domain capabilities, named agents own end-to-end work, and Managed Agent cookbooks translate those workflows into a runtime with explicit tools, connectors, workers, and artifact rules. Understanding those interfaces lets a reader judge what is genuinely portable and what still has to be configured or rebuilt by a firm.
Vertical plugins own reusable capabilities
The lowest useful layer is organized by financial function rather than by model behavior. The financial-analysis vertical provides modeling, valuation, spreadsheet auditing, and related commands. Investment banking adds deal materials and execution workflows. Equity research adds earnings, initiation, sector, and thesis work. Private equity, fund administration, and operations add their own methods. Partner-built plugins connect specialized data or analytics to particular use cases.
Within a vertical, a skill is a method that the agent can use when the task calls for it. A DCF skill specifies how to structure projections, WACC, terminal value, and sensitivity analysis. A comparable-company skill defines source priorities, operating metrics, multiples, statistics, and comparability checks. A reconciliation skill defines how two extracts should be normalized and matched. A KYC rules skill defines how a parsed record is evaluated against a trusted rules grid. These are not interchangeable descriptions of “analyze this.” Each carries assumptions about inputs, transformations, evidence, and failure conditions.
A command is different. It is an explicit action a user invokes, such as a comparable-company analysis or an earnings workflow. The command is a visible entry point, while the skill is the reusable knowledge that supports the work. A connector is different again: it gives a runtime access to a provider or internal system through MCP. It does not decide how the retrieved information should be interpreted. The skill remains responsible for source priority, definitions, units, and checks.
That division protects against a common design error: assuming that access to data is equivalent to expertise. A financial data provider may return a number, but the workflow still needs to know whether it is an LTM or quarterly value, whether the numerator and denominator share a period, whether a market cap or enterprise value belongs in a multiple, or whether the number is appropriate for the question. The connector supplies a possible evidence stream; the skill supplies the method for using it.
Named agents own the work, not just the vocabulary
A named agent sits above those capabilities and turns them into a bounded workflow. Its prompt defines a role, the input shape, the artifacts it should produce, the sequence in which skills are used, and the points where a professional reviews the result. That is why a named agent is more than a convenient bundle of skills.
Model Builder illustrates the difference. Its scope is to build a DCF, LBO, three-statement, or comparable-company model from a ticker, model type, and assumptions. It pulls inputs, invokes the relevant modeling skill, audits the workbook, builds sensitivities, and stops after the model is ready for review. The model is not simply “a spreadsheet produced by a capable language model.” Its workflow includes formula conventions, source labels, an audit step, and a review boundary.
GL Reconciler has a different domain method and a different output contract. It pulls balances for a trade date and asset classes, isolates variances, traces transaction evidence, asks a critic to re-verify the reported breaks, and then hands the verified set to a resolver for an exception report. KYC Screener likewise has a specific chain: extract entity fields, run rules, screen named parties, and package gaps or hits for compliance sign-off. The agents are related by architecture but not interchangeable in meaning. A reconciliation break is not a KYC hit, and the appropriate evidence, tolerance, reviewer, and consequence differ.
The named agent also defines what the workflow refuses to do. The prompt can say that a particular agent does not post a ledger, publish a note, make a risk decision, or send an external communication. That negative space is part of the interface. Without it, a firm cannot tell whether a generated file is a draft, an approval recommendation, or an action request.
The important relationship in this diagram is ownership. The vertical layer owns reusable domain methods. The named agent owns the sequence and work product. The cookbook owns the headless deployment description. The runtime owns the actual tools and endpoints available during execution. A firm can customize several seams, but changing one layer does not automatically change the others.
The interfaces run in both directions. A named agent depends upward on the method definitions beneath it, but its own guardrails also determine which parts of those methods are reachable. A skill may describe a spreadsheet audit, for example, while the runtime withholds write access from the auditor. A connector may expose market data, while the agent prompt requires that every number be cited and that unsourced figures be flagged. The surrounding layer therefore does not merely transport content; it constrains how that content can become action.
This is also why a component catalogue is a poor substitute for an operating model. Knowing that the repository contains a skill, a connector, and an agent does not tell a reviewer whether they share a source hierarchy, whether the connector is read-only, or whether a generated file can trigger the next step. Those facts live at the interfaces. A useful architecture explanation must therefore ask what crosses each boundary and who owns the consequence.
One source of truth still has a synchronization cost
The repository describes the vertical skill as the source of truth, while agent plugins carry bundled copies of the skills they use. That arrangement solves a practical packaging problem: an agent plugin can be installed as a self-contained unit. It also creates a lifecycle problem: a change to a vertical skill must reach every agent that bundles it.
The repository addresses this with a synchronization script that copies each vertical skill into the corresponding agent bundles, and a structural checker that can detect drift between the source and its bundled copies. This is a sensible compromise between reuse and self-contained installation. It is not the same as eliminating duplication. A firm still needs a release habit: edit the canonical skill, synchronize the bundles, validate references, and decide which deployed versions should change.
The distinction matters when a method changes in a financially meaningful way. Suppose a modeling skill changes a required source comment, a sensitivity-table rule, or a balance check. The change is not only a text edit. It can alter the review expectations for every named agent that uses that skill. If one bundle is updated and another is not, two agents with similar names may follow different controls. The repository exposes this risk rather than pretending that file-based composition makes it disappear.
The risk is not limited to obvious defects. A synchronized skill may still be inappropriate for every consumer. A source-priority rule that suits a market-research workflow may need different treatment in an internal reconciliation, and a workbook-writing convention may not belong in a document-only agent. Shared source makes updates easier to distribute, but it does not remove the need to decide which agents should receive a change and how their outputs should be re-reviewed.
The same principle applies to firm context. A firm may add terminology, internal formatting standards, a branded template, a connector, or a narrower scope. But local additions should remain distinguishable from the reusable method. Otherwise, it becomes difficult to tell whether a behavior came from the shared financial discipline, a firm-specific policy, a provider adapter, or an accidental prompt change.
The two runtime surfaces share intent, not every execution detail
The interactive Cowork surface and the Managed Agent surface refer to the same system prompt and skills, but they do not have the same execution semantics. In an interactive session, a professional may work with a live workbook or ask for an intermediate explanation. In a headless session, the cookbook appends instructions not to assume an open Office document and instead stages files under an output directory. The shared prompt preserves the role and workflow; the cookbook supplies the conditions under which that role runs without a person continuously present.
The headless manifest must therefore declare more than the agent's name. It specifies which toolsets are enabled, which MCP servers are available, which environment variables supply their URLs, which skills are uploaded, and which leaf workers can be called. A Model Builder cookbook can give the orchestrator read and search tools plus read-only data connectors, then separate data retrieval, workbook construction, and auditing into workers. The builder may be the only worker with Write. That topology does not follow automatically from the interactive prompt; it is an explicit runtime decision.
The Managed Agent cookbook also limits delegation. The repository describes callable-agent delegation as a depth-one preview capability: an orchestrator can call workers, but workers do not call further subagents. This makes the topology easier to reason about, but it also limits how deeply a firm can decompose a workflow without moving more orchestration into its own event engine.
That limitation has a useful side effect. A shallow topology makes it easier to explain why a worker exists and what information it receives. It is easier to review a data-puller, builder, and auditor than a chain in which each worker can create more workers with inherited or expanded authority. The trade-off is that complex business processes cannot be decomposed indefinitely inside the cookbook. The firm must either keep the workflow within the documented shape or take responsibility for more orchestration outside it.
Deployment adds another seam. The human-readable manifest uses relative references such as a system-prompt file, a plugin-wide skill bundle, or a subagent manifest. The deployment helper resolves those references, uploads skill directories, inlines the prompt, creates leaf agents, replaces manifest references with API IDs, and posts the resulting JSON. In other words, the cookbook is an intermediate representation. The API receives a compiled object with different shapes and dependencies.
That compilation step is where portability becomes operational. A missing path, an unavailable model or beta endpoint, a malformed environment value, a provider authentication failure, or a skill upload mismatch can break deployment even if the workflow description is conceptually sound. A firm should therefore treat the repository layer as source code for a deployment pipeline, not as the deployment itself.
Where firm context belongs
The architecture leaves several legitimate customization points. A firm can swap or add connectors, add terminology and process rules to a skill, teach a branded presentation template, narrow an agent's scope, or copy the structure for a workflow not included in the reference set. These changes should answer a concrete local need: a different approval threshold, a different data provider, a different workbook convention, or a different ownership boundary.
The dangerous alternative is to customize by widening authority. Adding a connector that exposes a system of record, giving a document reader write access, or allowing a generated report to trigger distribution changes the workflow's risk profile. The repository's architecture is most useful when it makes such changes visible. A firm can ask, for each extension: which layer changed, what new data can cross the interface, who owns the resulting artifact, and what independent check or approval must be added?
The architecture therefore has a practical conclusion. It is modular, but not frictionless. Vertical plugins make methods reusable. Named agents make workflows legible. Cookbooks make headless deployment expressible. Connectors make evidence accessible. Synchronization and manifest compilation make the package movable. Yet each seam is also a place where configuration, version drift, or authority can diverge. The next question is what the reusable skills actually contain—the formulas, rules, evidence priorities, and checks that keep this architecture from becoming an empty set of labels.