AI Reference Architectures and Design Patterns

1. Scope, method and sources

This paper covers software and solution architecture for generative and agentic AI applications, together with the platform and governance services they depend on. Classical machine learning appears only where it shares platform components. Hardware design is out of scope except as a hosting option.

The subject is a regulated financial institution: a bank, an insurer or an asset manager supervised in the EU, the UK or Switzerland. I use the term AI factory for the organisational and technical capability that delivers AI applications repeatedly from shared, governed parts, as opposed to project-by-project delivery. Nothing in the paper depends on a particular size of firm or a particular cloud.

Method. I reviewed publicly available reference architectures and pattern catalogues, identified the components and decisions that recur, grouped them into dimensions, and tested the dimensions against the solution types a financial institution builds. That is how taxonomies are usually built, and it has the usual weakness: the result is a reasoned synthesis, not an empirical finding. Section 3 is evidence, in the sense that every statement about a source can be checked against that source. Sections 4 to 8 and the appendix are a design proposal and are labelled as such.

Verification. The sources in the reference list were re-opened on 10 November 2026 by an AI research agent working under my direction, and each statement attributed to a source was compared with the page as it stood that day. This is machine-assisted verification, not peer review. Three sources that the fetch tool could not open (the DORA text on EUR-Lex and two McKinsey articles) were read in a browser on the same date.

Vendor documents are written to sell a platform, so I have normalised component names to vendor-neutral terms. Microsoft Azure is the platform I know best and the one I cite most; where its guidance is imprecise I say so.

2. Why an AI factory needs a taxonomy

A factory outperforms project-by-project delivery only if the second, tenth and hundredth application reuse what the first one built. A shared taxonomy is the precondition for that reuse. It gives every asset an address, every design choice a name, and every control a place to attach.

Three failure modes show what happens without one. I have seen each of them more than once; this is experience, not survey evidence.

• Pattern sprawl. Each delivery team picks its own framework, vector store and prompt conventions. Assets cannot be found or composed, so reuse stays accidental.
• Governance by exception. Controls are negotiated per use case with risk and compliance, which makes time to production depend on meetings.
• Agency creep. Teams reach for agents, then for groups of agents, because that is what the conference slide showed. Each step adds cost, latency, attack surface and test burden, and none of it is written down as a decision.

The regulated context raises the bar. The obligations below are the reason a financial institution cannot leave classification to each team. They are stated as of November 2026, and this is architectural orientation, not legal advice.

• EU AI Act. Regulation (EU) 2024/1689 was amended by Regulation (EU) 2026/1744, the Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force three days later [1]. Under Article 113 as amended, the requirements for high-risk systems apply from 2 December 2027 for systems classified under Article 6(2) and Annex III, and from 2 August 2028 for systems classified under Article 6(1) and Annex I. A new Article 111(4) gives providers of generative systems already on the market before 2 August 2026 until 2 December 2026 to meet the marking obligation in Article 50(2). Article 4 was replaced: providers and deployers “shall take measures to support the development of AI literacy of their staff” [1]. Whether a given use is high-risk is decided per use case, so the institution needs an inventory that records what each system does.
• DORA. Regulation (EU) 2022/2554 requires financial entities to keep a register of information on their contractual arrangements with ICT third-party providers (Article 28(3)) and to have exit strategies for ICT services that support critical or important functions (Article 28(8)); it has applied since 17 January 2025 [2]. Model providers and AI platforms are ICT third parties for this purpose, which is why Section 5.1 treats multi-provider routing as a resilience control and not only a cost control.
• Switzerland. FINMA Guidance 08/2024, published on 18 December 2024, expects supervised institutions to identify, assess, manage and monitor the risks of their AI use, and names robustness, correctness, explainability, bias and growing third-party dependencies among them [3].
• United Kingdom. For banks with internal model approval, the PRA’s Supervisory Statement SS1/23 starts from model identification and model risk classification (Principle 1) [4]. An AI inventory with a consistent classification is the same instrument seen from the prudential side.

A taxonomy makes the inventory and the risk classification systematic. It also gives the institution one place to map each obligation onto a technical component, which is the subject of a sibling paper, Data Classes, Processing Lanes and Controller/Processor Roles for AI (Working Paper 09).

3. The landscape of published reference architectures

The published sources fall into five families, and none alone covers a factory. Hyperscalers describe lifecycle and quality. Practitioners describe composition. Academics describe forces and trade-offs. Standards bodies describe interfaces. Regulators and industry bodies describe obligations and controls.

Convergence. Read side by side, these sources describe the same logical stack: a data and knowledge layer, a model layer, an orchestration layer where workflows and agents live, an integration layer of tools and protocols, an experience layer, and a cross-cutting plane for security, evaluation, observability and governance. They differ mainly in vocabulary and in which layer the vendor sells. Section 4.1 formalises the stack. The convergence is the reason I can present the layer model as a reading of the field and not as an invention.

Divergence that matters. The sources disagree on two points.

The first is where agency starts. Anthropic separates workflows, “systems where LLMs and tools are orchestrated through predefined code paths”, from agents, “systems where LLMs dynamically direct their own processes and tool usage” [11]. Google Cloud lists sequential, parallel and loop patterns among its multi-agent patterns while describing them as running on predefined workflow logic, without a model orchestrating the sub-agents [9]. Both descriptions are accurate. They become a problem only when a team reads “multi-agent” as “more autonomous” and attaches the wrong controls.

The second is where governance sits. The hyperscaler frameworks treat it mainly as a set of review questions. FINOS and the security literature treat it as controls that must exist at run time [18][19].

This paper takes the stricter reading in both cases. The line between a workflow and an agent is drawn by one test — who decides the next step, code or the model — whatever a vendor’s diagram calls the pattern. And governance is a platform layer that executes, not a checklist that is read.

What the standards do not yet give you. MCP and A2A are the main lever for reuse because they turn one-off integrations into catalogue assets. They are not a control layer. Kang and Diponegoro tested the specifications of five agent interoperability protocols, including MCP and A2A, against six governance capabilities: membership, deliberation, voting, dissent preservation, human escalation, and audit and replay. They found that no protocol covers the full set and conclude that governance “constitutes a missing architectural layer above current interoperability standards” [17]. Their subject is the governance of agent communities, which is narrower than enterprise control, but the practical consequence is the same: the institution wraps the protocols with its own policy layer. A sibling paper, MCP and A2A: Interoperability Protocols for the Enterprise AI Factory (Working Paper 10), covers the protocols in detail.

Sidebar — five tests for vendor and consulting material

Much of what vendors and consultancies publish mixes durable guidance with product placement. I keep an element only if it passes at least three of five tests:

1. It states a principle that survives a change of vendor.
2. It names trade-offs or failure modes, not only benefits.
3. It maps to a component or control that someone can build or audit.
4. Any numbers come with a method.
5. It is consistent with independent sources such as the academic catalogues and OWASP.

Brand names, unqualified impact percentages and product lists fail. No consulting productivity or uplift figure is used anywhere in this paper, because none I reviewed came with a published method.

4. The taxonomy

This section is a design proposal. Every AI asset and every AI application is classified on three primary axes — layer, pattern family and reuse generation — plus five descriptive attributes that drive governance and design choices.

4.1 Axis 1: layers — where a component lives

Six layers (L0–L5) are crossed by a trust and operations plane (X). Controls attach to layers and to the plane, so an application composed from catalogued components inherits them.

flowchart TD
    L5["L5 Experience & channels"] --> L4["L4 Integration & interoperability"]
    L4 --> L3["L3 Reasoning & orchestration"]
    L3 --> L2["L2 Models"]
    L3 --> L1["L1 Data & knowledge"]
    L2 --> L0["L0 Infrastructure & hosting"]
    L1 --> L0
    X["X Trust & operations plane<br/>identity · guardrails · evaluation · observability · cost · evidence"] -.-> L5
    X -.-> L3
    X -.-> L2
    X -.-> L1

The dotted lines show the plane governing every layer. L4 also sits beside L3, because agents call tools and tools can call agents. The plane is not a seventh layer and should not be drawn as one: it is where controls live, and it touches everything.

4.2 Axis 2: pattern families — how a capability is built

There are eight families, and each is a question. The named patterns inside each family are in Appendix A.

The order of the first three families is also an order of preference: try model-interaction patterns first, then knowledge and grounding, then adaptation. Changing model weights is the exception and needs its own business case. Integration and interoperability is both a layer and a family. That is deliberate: the layer says where a component lives, the family says how the capability is built, and the classification code keeps them in separate fields.

4.3 Axis 3: reuse generations — how shareable an asset is

Reuse is recorded per asset. Each catalogue entry carries a generation that says what the next consumer has to do: rebuild it (G0, ad hoc), import it (G1, shared code), call it (G2, platform service), bind to it (G3, composable capability), or fill in parameters and run a pipeline (G4, governed blueprint). Section 6 defines each generation, its entry criteria and the portfolio metrics.

4.4 Descriptive attributes

Agency class is a design-time property. It describes the shape of a design and answers one question: who decides the next step. It is fixed when the design is chosen.

Three clarifications prevent the usual confusions.

The only conceptual line is between A2 and A3. Below it, code decides the next step and the unit of testing is an output. Above it, the model decides and the unit of testing becomes a trajectory: the path of tool calls the agent took, in order, with its cost. A0, A1 and A2 differ in how much is composed around the model, not in how much the model controls. A1 is listed as a class because grounding changes the attack surface and the test effort enough to deserve its own control bundle. It is a design shape, not a degree of autonomy.

A4 is defined by ownership, not by more model control. A design is A4 when it contains several agents that have separate owners, identities, security boundaries or release cycles. Some A4 patterns are orchestrated by code: a sequential pipeline of agents, a concurrent fan-out, a generator–critic loop. Under the control-flow test those are workflows whose stations happen to be agents, and they keep most of the predictability of a workflow. They are still A4, because the control burden that comes with several identities — an agent registry, authorisation between agents, a kill switch per agent — applies however the sequence is decided. Appendix A.6 records, for every multi-agent pattern, who decides the next step.

Agency class is not run-time autonomy. What a design is permitted to do in production is the action scope, and it is earned on evidence: a system starts at read-only or draft and widens only when recorded behaviour justifies it. An institution that keeps the two apart can say something useful that one which conflates them cannot: this is an A3 design currently operating at draft scope.

Lanes and data classes in two sentences. A processing lane is the route a request takes to a model, defined by who operates the infrastructure and who can see the data: Lane A is a vendor’s API under an enterprise contract, Lane B is a vendor model consumed through the institution’s own cloud tenancy, and Lane C is a model on infrastructure the institution controls. The data class (C1 to C4, with flags) decides which lanes a request may use; both scales, the permission matrix between them and the controller and processor roles are defined in Data Classes, Processing Lanes and Controller/Processor Roles for AI (Working Paper 09).

4.5 The classification code

Each asset and each application carries a compact code in its repository manifest and its catalogue entry:

layer / pattern | agency class | action scope | risk tier | data class | reuse generation

A routing step in a claims-intake pipeline might read L3/WF-ROUTE | A2 | Draft | Tier-2 | C3 | G3. An application lists the code of every component it composes, which follows Weber’s view of an application as a combination of LLM components [13].

The code is small on purpose. Search reads it, so a platform engineer can ask which applications depend on permission-aware retrieval before changing it. Policy-as-code reads it, so the right control bundle attaches without a meeting. The catalogue reads it, so reuse becomes countable. The reviewer reads it, so a design is compared with its siblings.

One addition sits beside the code and not inside it. Grau et al. make the human a dimension of the architecture in its own right — people supervise actions, verify outputs, and improve the system through feedback and annotation [14]. Those are staffing commitments, not interface features. I therefore record the human roles a solution requires (supervisor, annotator, feedback provider) as a list in the same manifest. They are kept out of the six-field code because they are read by a resourcing process, not by the policy engine.

5. Five patterns that carry the factory

This section mixes evidence and proposal: the vendor guidance is cited, the factory rules are mine. Most patterns need only the table row they get in Appendix A. Five need more, because each is the place where reuse and control are actually implemented.

5.1 The AI gateway

Every model call passes through the gateway, which makes it the most reused component by construction. It also becomes a compliance-scoped, availability-critical system, so it has to be engineered as a product with its own service-level objectives, security review and data classification.

flowchart LR
    C["Apps, orchestrators,<br/>agents"] --> AU["Federated authentication<br/>per-client identity"]
    AU --> CL["Classify + redact"]
    CL --> RL["Quotas, token limits,<br/>priority"]
    RL --> RT["Router<br/>model + version header"]
    RT --> LB["Load balance +<br/>circuit breaker"]
    RT --> Q["Queue for<br/>low-priority batch"]
    LB --> M1["Lane A models"]
    LB --> M2["Lane B models"]
    LB --> M3["Lane C models"]
    RT --> MON["Token metrics, cost,<br/>prompt/response logs"]

The gateway authenticates each caller, classifies and routes by data class and pinned model version, and emits the telemetry that cost allocation and audit rely on.

Microsoft’s gateway guidance lists the capabilities a gateway adds: federated authentication, rate limiting, cross-model monitoring, routing (including sending low-priority requests to a queue), health-based load balancing with circuit breaking, and caching [8]. The guidance is written for Azure but the rationale is vendor-neutral, and it is one of the few vendor documents that states its own trade-offs.

Trade-offs to design for.

• Single point of failure. Microsoft’s own advice is to include the gateway in the workload’s failure-mode analysis and not to implement one “if it jeopardizes your workload’s ability to meet agreed-upon service-level objectives” [8].
• Compliance scope. The gateway sees raw prompts and responses, so it is classified at the highest data class it handles and its logs follow the retention rules for that class.
• Attack surface. It becomes the entry point to private model endpoints and needs its own hardening and identity management.
• Latency and protocol support. Streaming needs long-lived connections, and stateful model APIs need session affinity [8].
• Where inference runs. This is the point most often misread. Microsoft’s deployment-type documentation states that data at rest stays in the designated Azure geography for every deployment type, but inference differs: Global deployments may process prompts in any Azure region, Data Zone deployments process them only within the Microsoft-specified zone (US, EU or Asia Pacific), and Standard and Regional Provisioned deployments process them within the chosen geography [22]. The EU data zone follows Microsoft’s EU Data Boundary, which the same page says can include EFTA countries such as Norway and Switzerland, and Microsoft may add regions to a zone without prior notice [22]. The gateway guide itself is looser, saying that with Global or Data Zone deployments data “might be transmitted and processed for inferencing in any Foundry model location” [8]. I rely on the more specific page and would like Microsoft to align the two. For lane assignment the consequence is plain: a Global deployment is cross-border processing without a fixed destination, a Data Zone deployment is cross-border processing within a named zone, and only a geography-bound deployment keeps inference in one jurisdiction. Each has to be checked against the institution’s own location commitments to supervisors and clients.

I have verified this level of detail only for Azure. The same questions — which identity calls the model, where inference physically runs, what the provider may change without notice — have to be put to any provider, and the gateway is where the answers are enforced.

5.2 Translocation between agentic and procedural forms

A design’s shape is not permanent. Once an agentic flow proves stable, its common path should move into cheaper, deterministic code. In the other direction, the exceptions a procedural system cannot handle can be delegated to an agent. The idea of moving workloads in both directions comes from QuantumBlack’s description of its agent-estate architecture [27].

The downward move is the one that pays: lower cost, higher predictability, a smaller test surface. Its trigger is evidence, not taste. The trajectory data in the trace store is what makes codification a finding. The upward move is how a legacy system joins the estate without being rewritten: a policy-administration or payments platform keeps its logic and gains an agent on its exception queue.

5.3 Model lifecycle and release pinning

The unit of release in an AI application is not the code. It is a pinned combination of model version, model configuration, prompt, orchestration logic and retrieval configuration. Changing any one of them is a release that must pass evaluation.

Microsoft’s lifecycle guidance treats foundation models as versioned dependencies. For hosted models, a deprecated version cannot be newly deployed, and existing deployments of a retired version return HTTP errors [24]. The same page distinguishes update scopes, which I group as follows.

A model change can reach six places: the model, its configuration, the prompt, the orchestration logic, the grounding data or its retrieval, and for self-hosted models the hardware [24].

flowchart LR
    APP["Application"] --> RT["Router<br/>blue/green, A/B"]
    RT --> O1["Orchestrator release 1<br/>prompt v1 + config v1"]
    RT --> O2["Orchestrator release 2<br/>prompt v2 + config v2"]
    O1 -->|header: model-x v1| GW["AI gateway"]
    O2 -->|header: model-x v1.1| GW
    GW --> M1["model-x v1"]
    GW --> M2["model-x v1.1"]

The router splits traffic between tested releases and the gateway honours each release’s pinned model version, so users never meet an untested prompt–model combination. Microsoft’s recommendation is that tested combinations be “pinned together” in production, and that platform features which upgrade production models automatically be avoided [24].

Factory rules (proposal).

• Every AI application ships a release manifest listing model and version, parameters, prompt version, orchestration version, retrieval and index version, tool versions and evaluation results.
• Automatic model upgrades are disabled in production; upgrades go through the evaluation pipeline.
• Prompts and configuration live in an external, versioned store and are always deployed with the model version they were tested on.
• Traces record every version in the manifest so that a regression can be attributed.
• The model catalogue tracks deprecation and retirement dates and triggers re-evaluation well before retirement.

5.4 The AI asset registry and golden records

The AI asset registry keeps the institution’s AI know-how — prompts, agent configurations, tool definitions and verified examples — outside any vendor platform, so that it can be governed, reused and moved.

A golden record is a human-verified example of a correct output. QuantumBlack argues that golden records may become an organisation’s most valuable AI intellectual property, and that assets should graduate from experimental environments to the registry before production use [27]. I agree with the first claim for a reason of my own. Prompts are rewritten with every model generation and frameworks are replaced every few years, but a verified set of “this input, this correct output” for a claims decision or a suitability check survives all of that. In the factory, golden records carry the data class of their content, have a business owner, and are the shared basis for few-shot prompting, regression evaluation and trajectory testing.

The registry also answers a portability question that DORA makes concrete. An exit strategy for an AI platform [2] is credible only if the assets that encode the institution’s behaviour are held somewhere the platform’s vendor does not control.

5.5 Lifecycle controls and controls that execute

Controls are fastest when they are designed in at the start of each use case, inherited from the platform, and enforced by machinery at the moment of change. A review committee at the end is the slowest and weakest control.

Operations first. Microsoft’s guidance on generative AI operations makes a point worth keeping: an organisation with MLOps in place does not start over, but it has to extend its operations to three things classical MLOps never governed — the orchestrator, the prompts, and the grounding-data pipelines with their indexes [25]. Indexes must be kept fresh, rebuilt when they cannot be updated in place, and must honour deletion requests; and the maturity of generative AI operations should be assessed separately from MLOps maturity, because the two can differ widely [25]. Microsoft’s design guide for retrieval-augmented generation splits the work into preparation, chunking, chunk enrichment, embedding, information retrieval and end-to-end evaluation, with agentic retrieval as an extension [23]. The factory treats each of those phases as a versioned, testable step, and versions each phase’s configuration together with the index it produced.

Lifecycle and gates (proposal). The lifecycle below has five stages and three approval gates. The structure is adapted from McKinsey’s 2026 work on AI controls in the public sector [28]. The controls and evidence in the table are my mapping to a financial institution.

flowchart LR
    D["Design<br/>AI at all? which agency class?"] --> G1{"Gate 1<br/>approve to build"}
    G1 --> DA["Get data<br/>lawful, classified, test prompts"]
    DA --> BE["Build + evaluate<br/>evaluations, red team"]
    BE --> G2{"Gate 2<br/>approve to implement"}
    G2 --> IN["Industrialise<br/>pin versions, limits, kill switch"]
    IN --> G3{"Gate 3<br/>approve go-live"}
    G3 --> MO["Monitor<br/>alerts, cost, re-test, re-justify"]
    MO -.->|roll back or redesign| D

Where accountability sits. The leader of the affected business service owns the AI system and its risk. The central AI function provides the platform, the standards, shared testing and the approved patterns. Accountability attaches to the person who defines an agent’s scope, and the factory enables that person instead of approving each use case on their behalf. The governed platform — identity and tool access, testing, guardrails, logging, and registries for models and agents — is what lets each new use case inherit the controls of the previous ones.

Controls that execute. An operating model names who is accountable. It does not stop anything. Valmis, writing for a vendor of enforcement tooling, puts it in one sentence that is correct whatever its commercial motive: “nothing in an operating model executes at generation time” [29]. A specification that an agent merely reads can be ignored. A constraint that the change is checked against cannot. The factory therefore turns its key decisions into machine-checked rules.

Written policies remain necessary. Executable controls are what make them hold when changes arrive at the speed agents produce them. Anything the institution must be able to evidence to a supervisor belongs in this deterministic layer.

6. Reuse generations and portfolio metrics

This section is a design proposal. Reuse is managed per asset, not per organisation. Each catalogue entry carries a generation, and the portfolio aim is to move the most-used assets to G3 and the most-used solution shapes to G4.

The solution shapes that are candidates for G4 are described in Ten Solution Archetypes for Regulated Finance (Working Paper 02).

A sixth step that is not a generation. Some formulations of this scale add a G5 in which agents assemble, test and operate G3 and G4 assets under human-defined scope. I no longer treat that as a value an asset can carry. It is a capability of the factory — automation that builds and maintains assets of every generation — and an institution either has it or does not. It depends on mature evaluations, replay testing, policy as code and gated contribution by agents. I keep the label G5 for that capability because it is in circulation, but no catalogue entry should be tagged with it.

Portfolio metrics.

These definitions are mine and have not been benchmarked. The 90-day window in the orphan rate is a starting value to be tuned. A sibling paper, Reusability and the Compounding Factory (Working Paper 08), develops the economics.

Promotion is a judgement, not a rule. It is tempting to write “promote on the second consumer; mint a blueprint on the third recurrence”. I do not recommend it. A second consumer of a G1 asset, or the third time the same composition appears, is a telemetry signal that opens a decision by the people who will have to own the result: an operating cost, a service level, an on-call rota. Automatic promotion produces platform services nobody agreed to run. Retirement works the same way in reverse: an asset that falls below usage or evaluation-freshness thresholds is flagged, a successor is named in the catalogue, and an owner decides.

7. The design decision framework

This section is a design proposal. Design decisions follow a fixed sequence of eight questions. The default answer at every step is the least agentic, least bespoke option that meets the need. I call this the least-agency rule: choose the lowest agency class that works, and justify every step up, with evidence, in an ADR that names the classes rejected.

The rule rests on a consensus in the guidance and on one judgement of mine. The consensus: Anthropic advises “finding the simplest solution possible, and only increasing complexity when needed” [11]; Microsoft advises the lowest level of complexity that reliably meets requirements [6]; Google Cloud recommends starting with a single agent [9]. The judgement, for which I can offer experience but no published dataset: in financial institutions today, more of the realised value comes from workflows with model steps inside them than from autonomous agents.

7.1 The decision sequence

flowchart TD
    Q1{"1. Is AI needed?<br/>would rules or analytics do?"} -->|No| Z["Conventional software"]
    Q1 -->|Yes| Q2{"2. Prediction or generation?"}
    Q2 -->|Prediction| P["Classical ML (AD-CLASSIC)"]
    Q2 -->|Generation| Q3{"3. Needs enterprise facts?"}
    Q3 -->|"No, and one call suffices"| A0["A0: prompt patterns"]
    Q3 -->|"Yes, or more than one step"| Q4{"4. Steps known in advance?"}
    Q4 -->|"One step over retrieved facts"| A1["A1: grounded answer"]
    Q4 -->|"Several known steps"| A2["A2: workflow"]
    Q4 -->|No| Q5{"5. One coherent responsibility?"}
    Q5 -->|Yes| A3["A3: bounded agent"]
    Q5 -->|No| A4["A4: multi-agent"]

Question 3 decides whether knowledge and grounding patterns are part of the composition. It ends the sequence at A0 only when the task also fits in a single call. A task that needs no enterprise facts but has several steps — drafting, checking against a style rule, reformatting — continues to question 4 and lands on A2, and one whose steps cannot be known in advance continues to question 5. Without that qualification a workflow or an agent that works only on user-supplied content would have no path through the diagram.

After the agency class, three further questions complete the design: (6) which catalogue assets already cover each layer; (7) which control bundle the risk tier, action scope and data class require; and (8) which processing lane and model class the data class and cost profile allow. Questions 1 to 5 produce the agency class. Questions 6 to 8 produce everything else.

Question 1 deserves more respect than it gets. In my experience it ends more requests than the other seven together, and each of those is a system the institution does not have to evaluate, monitor or explain.

7.2 Escalation criteria

The least-agency rule needs evidence requirements to have any force. A design may step up a class, but it brings something.

The A3 → A4 row is the one that gets argued. It does not accept as evidence that the process has four steps, that four teams are involved, or that a vendor’s diagram has four circles in it. Several agents are justified by ownership boundaries and by demonstrated degradation of a single agent, which is also what Google Cloud’s guidance says [9].

7.3 Trade-off matrix by agency class

The ratings are qualitative and are my assessment. The A4 row describes model-orchestrated designs; an A4 design whose sequence is fixed in code sits closer to A2 on predictability and test effort while keeping A4’s identity and registry controls. The test-effort column is the one that ruins plans, because between A2 and A3 the thing being tested changes from an output to a trajectory.

7.4 Other selection dimensions

For model class, the institution’s own evaluations are the only acceptable basis. Published model rankings date within months.

7.5 The design record

Each AI application has one ADR with a fixed field list:

1. Problem and business owner.
2. Classification code (Section 4.5).
3. Chosen agency class, and every lower class rejected, with the reason.
4. Patterns used per layer.
5. Catalogue assets reused, and new assets proposed for contribution.
6. Model class and processing lane, with the data-class reason.
7. Control bundle and residual risks.
8. Evaluation plan and acceptance thresholds.
9. The named person accountable for the system’s operational scope.
10. Exit or fallback strategy.

Field 3 is the one that changes behaviour. A record that states only the chosen class is a receipt. One that states the rejected classes and why is a decision, and eighteen months later it is the two-line answer to “why is this pipeline not an agent?“.

7.6 The consequence check

Agency class describes mechanics. It says nothing about whether the institution should let the system act. That is set per decision, by two questions: how much harm a wrong decision causes, and how complex the decision is.

The principle that the degree of human involvement should follow the consequence of a wrong decision and the complexity of the decision is taken from McKinsey’s 2026 public-sector work, which sets it out as a matrix [28]. Setting it against sign-off by use-case category is my own contrast. It is worth keeping because the alternative — “all HR use cases need sign-off, all operations use cases do not” — is over- and under-inclusive on its first day. The matrix below is my proposal for applying it.

In a regulated financial institution, any decision with a legal or similarly significant effect on a person, a client or the institution’s regulatory position sits in the high-consequence row by default: a credit decision, a claims denial, a suitability assessment, a regulatory filing.

The consequence matrix sets the ceiling on action scope. The escalation criteria in Section 7.2 decide whether a given design may approach it. A high-consequence decision caps the action scope whatever the agency class of the design.

8. Adoption horizons

This section is the author’s proposal. The durations are planning assumptions, not findings.

Where an institution has systems that will be high-risk under Annex III of the EU AI Act, H2 has a fixed outer date: the requirements apply from 2 December 2027 [1].

The taxonomy needs one named owner who publishes versions, reviews it at least annually and accepts change requests from delivery teams. Taxonomies attract committees; one accountable architect is enough.

Appendix A. The pattern catalogue

The codes are a proposed internal vocabulary. Pattern names across vendors are not standardised. Each entry gives the context in which the pattern applies and its main cost. The full record in a factory’s catalogue should follow the context–forces–solution–consequences format of the CSIRO Data61 catalogue [12], because a pattern entry that lists only benefits is marketing.

A.1 Model interaction (MI)

A.2 Knowledge and grounding (KN)

A.3 Model adaptation (AD)

A.4 Workflow patterns (WF) — agency class A2

The first five follow Anthropic’s vocabulary [11].

A.5 Single-agent patterns (AG) — agency class A3

A.6 Multi-agent patterns (MA) — agency class A4

A4 is assigned because the design contains several separately owned agents (Section 4.4). The third column is the one a reviewer should read first: the first three patterns are code-orchestrated and keep most of a workflow’s predictability. Names follow Microsoft’s and Google Cloud’s guides [6][9].

Dynamic selection matters to a factory. Microsoft describes selecting relevant agents from a pool that can grow to hundreds, using vector similarity over stored sample utterances for each agent to produce a shortlist before a model chooses [26]. It works only if agents are catalogued with the metadata of Section 4.

A.7 Integration and interoperability (IN)

Integration patterns are where reuse compounds: a governed MCP server written once can serve every later application, while a hand-coded connector serves one.

A.8 Trust, governance and operations (TR)

Security and safety. The right-hand column maps each pattern to the entry it chiefly mitigates in the OWASP Top 10 for Agentic Applications for 2026, published on 9 December 2025 [19]. Entry names are as given in OWASP’s announcement of that date [20]. The mapping is my reading, not OWASP’s.

Two entries are mitigated by patterns in other families: ASI07 Insecure Inter-Agent Communication by the agent gateway (IN-A2AGW), and ASI10 Rogue Agents additionally by the rule that unregistered agents obtain no credentials (TR-EXEC-REG).

Governance, evaluation and operations.

The FINOS AI Governance Framework is a reasonable seed for the control bundles: version 2.0 added an agentic risk catalogue and is cross-referenced to OWASP, MITRE and the EU AI Act among other frameworks [18].

Limitations

• The taxonomy is a proposal, not a finding. The layers, families, classes, codes and metrics are a synthesis by one author. They have not been validated by an independent study, and the trade-off ratings in Section 7.3 are qualitative judgements.
• The decision sequence has not been tested for coverage. Section 7.1 repairs one known gap (designs that need no enterprise facts but more than one step). There may be others.
• The EU AI Act is cited only through the amending regulation. The dates and articles quoted were read in Regulation (EU) 2026/1744 [1]. The consolidated text of Regulation (EU) 2024/1689 was not opened.
• OWASP’s version label was not confirmed. The document is cited by its published title and date; the pages opened do not state a version number.
• Vendor guidance is Azure-heavy. The gateway, lifecycle and operations guidance cited in detail is Microsoft’s. The patterns are vendor-neutral, but the equivalent AWS and Google Cloud service behaviour, including where inference runs, was not verified for this paper.
• Evidence on multi-agent systems in production is thin. I found no published, method-backed evidence on the reliability of model-orchestrated multi-agent systems in regulated finance. That absence is why the framework keeps A4 behind the strictest escalation criteria, and it is also a reason to treat the framework’s caution as provisional.
• Protocols and dates move. Protocol status, vendor page content and regulatory dates were correct on 10 November 2026 and should be re-checked at each review of the taxonomy.
• Not legal advice. Regulatory statements are architectural orientation. Legal and compliance functions own the interpretation.

References

All web sources were accessed on 10 November 2026 unless stated otherwise.

1. Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). OJ L, 2026/1744, 24.7.2026. Article 1, points (5), (39) and (40), amending Articles 4, 111 and 113 of Regulation (EU) 2024/1689; Article 4 of the amending regulation (entry into force). https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202601744
2. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA). OJ L 333, 27.12.2022, p. 1. Articles 28(3), 28(8) and 64. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng Read in the Official Journal text on EUR-Lex, 10 November 2026.
3. FINMA. “FINMA guidance on governance and risk management when using artificial intelligence” (FINMA Guidance 08/2024), 18 December 2024. https://www.finma.ch/en/news/2024/12/20241218-mm-finma-am-08-24/
4. Prudential Regulation Authority. “SS1/23 – Model risk management principles for banks”. Supervisory Statement, first published 17 May 2023; the version current on the access date is dated 23 April 2026. https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss
5. Amazon Web Services. “Generative AI Lens – AWS Well-Architected Framework”. Publication date 19 November 2025. https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/generative-ai-lens.html
6. Microsoft Learn. “AI agent orchestration patterns”, Azure Architecture Center. Page dated 12 February 2026. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
7. Microsoft Learn. “Baseline Microsoft Foundry chat reference architecture”, Azure Architecture Center. Page dated 17 June 2026. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/baseline-microsoft-foundry-chat
8. Microsoft Learn. “Access Foundry Models and other language models through a gateway”, Azure Architecture Center. Page dated 30 April 2026. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/generative-ai-gateway
9. Google Cloud. “Choose a design pattern for your agentic AI system”, Cloud Architecture Center. https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system
10. Sabhlok, S. “Powering AI Factories with NVIDIA Enterprise Reference Architectures”. NVIDIA Developer Blog, 29 April 2026. https://developer.nvidia.com/blog/powering-ai-factories-with-nvidia-enterprise-reference-architectures/
11. Anthropic. “Building effective agents”, 19 December 2024. https://www.anthropic.com/engineering/building-effective-agents
12. Liu, Y., Lo, S. K., Lu, Q., Zhu, L., Zhao, D., Xu, X., Harrer, S. and Whittle, J. “Agent Design Pattern Catalogue: A Collection of Architectural Patterns for Foundation Model based Agents”. arXiv:2405.10467v4, 6 November 2024. https://arxiv.org/abs/2405.10467
13. Weber, I. “Large Language Models as Software Components: A Taxonomy for LLM-Integrated Applications”. arXiv:2406.10300, 13 June 2024. https://arxiv.org/abs/2406.10300
14. Grau, M., Reinhard, P., Bauer-Hänsel, I. and Blohm, I. “Rethinking AI Design Practices: A Reference Architecture for Generative AI Systems”. European Conference on Information Systems (ECIS) 2025, Amman, Jordan. https://alexandria.unisg.ch/server/api/core/bitstreams/b0d0cc58-d939-4f8d-a14a-2475853949c8/content
15. Linux Foundation. “Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)”. Press release, 9 December 2025. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
16. Linux Foundation. “A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year”. Press release, 9 April 2026. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
17. Kang, R. and Diponegoro, Y. “Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express”. arXiv:2606.31498v1, 30 June 2026. https://arxiv.org/abs/2606.31498
18. FINOS. “FINOS AI Governance Framework v2.0 – Addressing Agentic AI Risks in a Rapidly Evolving Landscape”, 12 November 2025. https://www.finos.org/blog/finos-ai-governance-framework-v2.0-addressing-agentic-ai-risks-in-a-rapidly-evolving-landscape
19. OWASP GenAI Security Project. “OWASP Top 10 for Agentic Applications for 2026”, 9 December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
20. OWASP GenAI Security Project. “OWASP Top 10 for Agentic Applications – The Benchmark for Agentic Security in the Age of Autonomous AI”. Announcement, 9 December 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
21. OpenTelemetry. “Generative AI semantic conventions” (index page, marked as moved to the OpenTelemetry GenAI repository). https://opentelemetry.io/docs/specs/semconv/gen-ai/
22. Microsoft Learn. “Understanding deployment types in Microsoft Foundry Models”. Page dated 6 August 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types
23. Microsoft Learn. “Design and develop a RAG solution on Azure”, Azure Architecture Center. Page dated 17 December 2025. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-solution-design-and-evaluation-guide
24. Microsoft Learn. “Design to support foundation model life cycles”, Azure Architecture Center. Page dated 13 May 2025. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/manage-foundation-models-lifecycle
25. Microsoft Learn. “Generative AI operations for organizations with MLOps investments”, Azure Architecture Center. Page dated 16 September 2025. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/genaiops-for-mlops
26. Microsoft Learn. “Dynamic AI agents at scale pattern”, Azure Architecture Center (solution idea). Page dated 20 May 2026. https://learn.microsoft.com/en-us/azure/architecture/solution-ideas/articles/ai-agents-at-scale
27. QuantumBlack, AI by McKinsey. “How we enabled Agents at Scale in the Enterprise with the Agentic AI Mesh”. Medium, 12 June 2025. https://medium.com/quantumblack/how-we-enabled-agents-at-scale-in-the-enterprise-with-the-agentic-ai-mesh-architecture-baf4290daf48
28. Vuppala, H., Ward, T., Roberts, R. and Fountaine, T. “How can the public sector meet the AI moment?”. McKinsey & Company, 18 August 2026. https://www.mckinsey.com/industries/public-sector/our-insights/rewiring-public-sector
29. Valmis, T. “McKinsey Rewired Software Delivery for the Agentic Era. The Enforcement Layer Isn’t in the Org Chart.” Mneme HQ, June 2026 (vendor blog). https://mnemehq.com/insights/mckinsey-agentic-software-delivery-governance/
30. A2A Project. “A New Chapter for A2A: Joining the Agentic AI Foundation”. Blog, 27 August 2026. https://a2a-protocol.org/latest/blog/2026/08/27/a-new-chapter-for-a2a-joining-the-agentic-ai-foundation/