Ten Solution Archetypes for Regulated Finance

1. Introduction

Most AI requests in a financial institution arrive as a description of a problem and a preferred technology. “We want an agent for claims.” “We need a chatbot over the credit policy.” The team then designs from a blank page, and three questions get answered late and differently each time: how much control the model has over what happens next, which controls apply, and what record the system leaves behind.

This paper proposes to answer those three questions first, by classification. The firm keeps a short list of solution archetypes. A new request is fitted to the nearest one, and the archetype brings its agency class, its controls and its evidence with it. The design work that remains is the part that is specific to the use case: the corpus, the schema, the tools, the rulebook.

The paper makes two claims, and they have different standing.

The first claim is structural. Starting from an archetype fixes the agency class, the control bundle and the evidence trail before any design work. This holds by construction: each card in section 5 states all three, and a team that adopts the card adopts them.

The second claim is a design judgement. I hold that ten archetypes cover most of the generative-AI use cases a regulated financial institution will raise. That judgement rests on how the ten were derived, not on a count. They were built by taking the five agency classes described in section 2 and asking, for each class, which compositions of patterns recur in the published practitioner guidance on workflows and agents [4][5][6] and in the requests I have seen firms raise. Nobody has measured the coverage against a firm’s use-case inventory, and section 8 says so again. Read “most” as a hypothesis a firm can test on its own backlog in an afternoon.

Sections 3 to 7 are a design proposal throughout. They describe how I would build these systems, not how any particular firm has built them, and they should be read as argument. Where a section states a fact about a vendor’s guidance, a protocol or a regulation, the fact carries a citation to the source itself.

The regulatory frame is EU-first: the Digital Operational Resilience Act (DORA), the EU AI Act and the General Data Protection Regulation (GDPR), as of November 2026. UK and Swiss rules are named where they differ in a way that changes a design.

Two terms recur. An AI factory is the delivery organisation and shared platform through which a firm builds, approves and runs its AI applications. An agent wrangler is the named person who owns an agent’s behaviour: they define its scope, handle its exceptions and answer for its outcomes.

2. What the reader needs from the sibling papers

The cards are written in the vocabulary of Working Paper 01 of this series, AI Reference Architectures and Design Patterns: A Taxonomy for a Reuse-Driven AI Factory [1]. This section repeats only what the cards use.

2.1 Layers

Every component sits in one of six layers, crossed by a trust and operations plane.

2.2 Agency class and action scope

Paper 01 keeps two things apart that are often run together [1].

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.

The only conceptual line is between A2 and A3. Below it, code decides the next step. Above it, the model does. Anthropic draws the same line, between systems “orchestrated through predefined code paths” and systems in which models “dynamically direct their own processes and tool usage” [4].

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; under the control-flow test those are workflows whose stations happen to be agents, and they keep most of a workflow’s predictability. They are still A4, because the controls that come with several identities — an agent registry, authorisation between agents, a kill switch per agent — apply however the sequence is decided. This matters for Archetype 10.

The default is the lowest agency class that meets the need, which Paper 01 calls the least-agency rule. Anthropic recommends “finding the simplest solution possible, and only increasing complexity when needed” [4]. Microsoft’s guidance on agent orchestration says to “use the lowest level of complexity that reliably meets your requirements” [5]. Google Cloud’s recommends starting with a single agent [6].

Action scope is the run-time permission. It says what a design is allowed to do in production: read-only, draft (a human sends), act with approval, or act autonomously within a defined envelope. It is earned on evidence: a system starts at read-only or draft and widens only when recorded behaviour justifies it. The two attributes are independent. Archetype 9 is A4 and read-only.

2.3 Pattern-family codes used in the cards

Paper 01 groups patterns into eight families. The cards use the codes below; the full catalogue is in Paper 01 [1].

Two of these codes name protocols. The Model Context Protocol (MCP) is “an open protocol that enables seamless integration between LLM applications and external data sources and tools” [7]. The Agent2Agent (A2A) protocol is an open standard for communication between independent agent systems, in which an agent publishes an Agent Card describing its identity, capabilities and authentication requirements [8]. Neither protocol is a control. The MCP specification says of its own security principles that “MCP itself cannot enforce these security principles at the protocol level” [7], which is why the cards put a gateway in front of every tool and every agent. Working Paper 10, MCP and A2A: Interoperability Protocols for the Enterprise AI Factory, treats both protocols in full [3].

Paper 01 also records a reuse generation for each asset, which 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). Each archetype here is a candidate for G4: a pattern composition, a pre-approved control bundle and templates. Paper 01 keeps the label G5 for a capability of the factory, automation that builds and maintains assets of every generation; no asset, and no archetype, is tagged with it.

2.4 Processing lanes, data classes and the classification code

The cards name lanes and data classes. The definitions below are the ones Paper 01 uses [1].

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 public, C2 internal, C3 confidential, C4 strictly confidential, with flags for personal data and other special categories) 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) [2].

No archetype owns a lane. The data class of the request decides which lanes are open to it.

Every asset and application carries a six-field classification code, in this layout:

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. The risk tier is the institution’s own AI risk classification. An archetype fixes the pattern composition, the agency class and the starting action scope; the risk tier and the data class are set by the use case.

3. Three routes by which code reaches execution

Several archetypes run code. Before the cards, it helps to separate the three ways code gets to run in an AI system, because each needs its own control regime and they are easy to blur. This section is a design proposal.

Two rules follow.

Generated runtime code is never promoted to a scheduled or production script without going through the third route. A script that worked once in a sandbox has been neither reviewed nor tested.

Browser and computer-use actions are treated like generated runtime code: a sandboxed session, allow-listed sites, no stored credentials.

In the ten archetypes, every tool is pre-authored code. Agent-generated runtime code appears in three: the structured-data analyst (Archetype 3), the bounded task agent (Archetype 8) and the research crew (Archetype 9), always in a sandbox. The third route is how the archetypes themselves get built when coding agents help build them. No archetype uses it at run time.

4. The ten archetypes at a glance

This table and the cards in section 5 are a design proposal.

4.1 Where regulation bites on the illustrations

An archetype is a technical shape. Its regulatory treatment depends on what it is used for. Five points apply to the illustrations in the cards, all as of November 2026. They are pointers to the texts and not legal classification, which remains the firm’s own decision with its counsel.

• High-risk uses under the EU AI Act. Annex III, point 5, lists AI systems used to evaluate the creditworthiness of natural persons or establish their credit score, with an exception for fraud detection, and AI systems used for risk assessment and pricing of life and health insurance for natural persons [9]. Under Article 6(3), an Annex III system is not high-risk where it does not pose a significant risk of harm, for example because it performs “a narrow procedural task” or “a preparatory task to an assessment”; that derogation never applies where the system profiles natural persons [9]. The same archetype can therefore be high-risk in one use and not in another. A document pipeline that extracts fields from a mortgage application is a different regulatory object from one that reads supplier invoices.
• Human oversight. For high-risk systems, Article 14 requires that they can be “effectively overseen by natural persons” while in use, and Article 26 requires deployers to assign oversight to people with “the necessary competence, training and authority” and to keep automatically generated logs for at least six months [9]. The approval and evidence rows of the cards are where a firm would meet these duties; the cards do not by themselves demonstrate that it has.
• Application dates. The European Commission states that the high-risk rules for Annex III use cases apply from 2 December 2027, following an amending regulation that took effect on 27 July 2026 [10].
• Automated decisions about people. GDPR Article 22(1) gives a data subject the right not to be subject to a decision “based solely on automated processing” that has legal or similarly significant effects [11]. None of the cards puts such a decision in a model’s hands; where an illustration approaches one, such as a claim or a credit decision, the card places a human decision point in the flow. In the UK, Article 22 of the UK GDPR has been replaced by provisions inserted by the Data (Use and Access) Act 2025 [12], so a firm operating in both jurisdictions should not assume the two texts are the same.
• Disclosure of AI use. The cards treat disclosure as a house control applied to every draft. The statutory duties in Article 50 of the AI Act are narrower: they concern, among other things, systems “intended to interact directly with natural persons” and AI-generated text published to inform the public on matters of public interest, with an exception where the text has been through human review under editorial responsibility [9].

For Swiss-supervised firms, FINMA Guidance 08/2024 sets out the supervisor’s observations on governance and risk management when using AI, naming model, data, IT and cyber, third-party, legal and reputational risks [14]. It is a parallel lens on the same controls and not an additional archetype.

5. The design cards

Each card has the same rows: purpose; when to use it and when not to; agency class and action scope; data classes and lanes; key components by layer; controls; the evidence the system leaves; how it is evaluated; anti-patterns; and illustrations from banking, insurance and asset management. The illustrations are generic to their sector. None describes a particular firm’s system.

5.1 Archetype 1 — Content assistant (A0)

A content assistant transforms text the user supplies: drafting, summarising, translating, rewriting. It makes a single model call and has no access to enterprise systems. That makes it the cheapest and safest archetype to industrialise.

flowchart LR
    U["User + pasted content"] --> UI["Chat or embedded UI"]
    UI --> GW["AI gateway<br/>classify, redact, route"]
    GW --> PL["Prompt library<br/>task template"]
    PL --> M["Model"]
    M --> OG["Output guardrails"]
    OG --> UI
    GW --> TR["Trace store"]

The only enterprise data is what the user pastes, so the gateway’s classification of that input decides the lane.

Flow. (1) The user selects a task, such as “summarise for a committee”, and pastes content. (2) The gateway classifies the input, masks personal data where the task allows, and picks a lane. (3) A versioned task template wraps the content with instructions and an output format. (4) The model responds in one call. (5) Output guardrails check tone, leakage and format, and the interface labels the text as AI-generated. (6) The user edits and uses the draft. Nothing is sent automatically.

5.2 Archetype 2 — Grounded knowledge assistant (A1)

A grounded knowledge assistant answers questions from an approved corpus, cites its sources and respects each user’s entitlements. It is the workhorse archetype and usually the first blueprint a firm ships.

sequenceDiagram
    participant U as User (L5)
    participant G as AI gateway (X)
    participant O as Orchestrator (L3)
    participant R as Retrieval service (L1)
    participant M as Model (L2)
    U->>G: Question + identity
    G->>G: Input guardrails, classify
    G->>O: Sanitised request
    O->>O: Rewrite query
    O->>R: Hybrid search with user entitlements
    R-->>O: Permitted passages + source ids
    O->>O: Rerank, assemble context
    O->>M: Prompt + context
    M-->>O: Answer with citations
    O->>G: Answer
    G->>G: Groundedness + citation check
    G-->>U: Cited answer or "not found"

Retrieval runs with the user’s own entitlements, so the model never sees a passage the user could not open directly.

Flow. The diagram is the query side. The ingestion side is a separate pipeline and the half firms underestimate. It loads documents from approved sources, parses and chunks them, attaches metadata (owner, class, validity date, access groups), embeds them and writes them to an index whose classification equals the highest class it contains. A source deletion or permission change reaches the index within a stated time.

5.3 Archetype 3 — Structured-data analyst (A1–A2)

A structured-data analyst answers questions about numbers by generating governed queries against a semantic layer and, where needed, running analysis code in a sandbox. The model writes the query or the code. The data platform computes the answer.

flowchart TD
    U["User question"] --> GW["AI gateway"]
    GW --> O["Orchestrator"]
    O --> SL["Semantic layer<br/>metrics + definitions"]
    SL --> Q["Model drafts query"]
    Q --> V{"Validate query<br/>schema, row-level security, cost"}
    V -->|OK| DB["Data platform<br/>runs as user"]
    V -->|Fail| Q
    DB --> SB["Sandbox<br/>analysis + charts"]
    SB --> NA["Model writes narrative"]
    NA --> U2["Answer + query + chart"]

The user always sees the executed query or code next to the narrative, so the number can be traced and re-run.

Flow. (1) The question is mapped to defined metrics and dimensions in the semantic layer, not to raw tables. (2) The model drafts a query in the platform’s language. (3) A validator checks syntax, allowed tables, row-level security and cost limits; failures loop back with the error message, up to a small retry budget. (4) The data platform runs the query under the user’s identity. (5) Optional analysis or charting runs as agent-generated code in an ephemeral sandbox with read-only access to the result set (the second route of section 3). (6) The model explains the result, and the response includes the query, the data timestamp and the chart.

5.4 Archetype 4 — Document processing pipeline (A2)

A document processing pipeline turns volumes of unstructured documents into validated structured records through fixed steps, with people handling only the exceptions. Code controls the flow. Models do extraction and classification inside it.

flowchart LR
    IN["Inbound docs<br/>upload, mailbox, document store"] --> OCR["Parse / OCR"]
    OCR --> CLS["Classify doc type"]
    CLS --> EX["Extract fields<br/>schema per type"]
    EX --> VAL{"Validate<br/>rules + confidence"}
    VAL -->|Pass| WR["Write to<br/>target system"]
    VAL -->|Low confidence| HQ["Human review queue"]
    HQ --> WR
    WR --> AU["Audit record<br/>source span per field"]

Every extracted field keeps a pointer to the page and text span it came from, which makes review and audit fast.

Flow. (1) Documents arrive through a governed intake and are hashed and registered. (2) Parsing and optical character recognition produce text with layout. (3) A classifier, often a small model, assigns a document type. (4) A type-specific schema drives structured extraction; for critical fields, two extractions run in parallel and must agree. (5) Business rules and confidence thresholds decide between straight-through processing and human review. (6) Approved records are written through a tool with typed parameters; the pipeline never writes free text into a system of record. (7) Sampled quality assurance checks a share of straight-through items every week.

5.5 Archetype 5 — Classification and triage router (A2)

A triage router reads incoming requests, classifies intent, urgency and sensitivity, and hands each one to the right queue, team or downstream archetype. It decides where work goes, not how it is resolved.

flowchart LR
    EV["Event<br/>email, ticket, form"] --> N["Normalise + classify data"]
    N --> C["Classifier<br/>intent, urgency, language"]
    C --> CF{"Confidence ≥ threshold?"}
    CF -->|Yes| RT["Route rule table"]
    CF -->|No| HT["Human triage"]
    RT --> Q1["Team queue"]
    RT --> Q2["Archetype 2 auto-answer"]
    RT --> Q3["Archetype 8 agent"]
    RT --> ESC["Priority escalation"]

Routing destinations live in a rule table owned by the business, so changing where work goes needs no prompt change.

Flow. (1) An event arrives from a mailbox, ticketing tool or form and is normalised. (2) Sensitivity is classified first, so that the right lane is used for everything after. (3) A classifier — a small model, or a larger model with a fixed label set and structured output — assigns intent, urgency, language and entities. (4) Below the confidence threshold, the item goes to human triage, and the human’s decision is added to the reference dataset. (5) Above it, a deterministic rule table maps labels to destinations, including other archetypes. (6) Complaints and regulatory or legal keywords always trigger escalation, whatever the confidence.

5.6 Archetype 6 — Review and compliance checker (A2)

A review checker tests a draft against an explicit rulebook and returns findings with evidence. It prepares the reviewer’s decision and never approves anything itself.

flowchart TD
    D["Draft<br/>document, contract, code"] --> RB["Load rulebook<br/>versioned checks"]
    RB --> P1["Check group A"]
    RB --> P2["Check group B"]
    RB --> P3["Check group C"]
    P1 --> AGG["Aggregate findings<br/>severity + evidence"]
    P2 --> AGG
    P3 --> AGG
    AGG --> CR["Critic pass<br/>remove weak findings"]
    CR --> HR["Human reviewer<br/>accept / reject each"]
    HR --> EV["Evidence record"]

Checks run in parallel by rule group, and a critic pass filters unsupported findings before a person sees them.

Flow. (1) The draft is submitted with its context: product, audience, jurisdiction. (2) The versioned rulebook is loaded for that context. Compliance or Legal maintains it as data, not as prompt text. (3) Rule groups are checked in parallel; each finding must quote the offending passage and cite the rule. (4) Findings are merged and ranked by severity. (5) An evaluator pass removes findings without evidence and flags missing mandatory elements. (6) The reviewer accepts or rejects each finding. Decisions and rule versions are stored, and rejected findings feed evaluation.

5.7 Archetype 7 — Embedded domain copilot (A2–A3)

An embedded copilot lives inside the business application a user already works in, reads the record on screen, and looks up related data through read-only tools. It inherits the user’s identity, so it can see only what the user can see.

sequenceDiagram
    participant U as User in app (L5)
    participant CP as Copilot panel (L5)
    participant GW as AI gateway (X)
    participant A as Copilot agent (L3)
    participant T as Tool gateway (L4)
    participant S as Business system
    U->>CP: Ask about current record
    CP->>GW: Question + record id + user token
    GW->>A: Classified request
    A->>T: get_record(id) as user
    T->>S: Read with user's entitlements
    S-->>T: Record data
    T-->>A: Result
    A->>T: search_related(...) as user
    T-->>A: Related items
    A-->>GW: Answer + suggested next action
    GW-->>CP: Answer; action shown as button
    U->>S: User clicks to execute

The copilot proposes actions as buttons in the host application. The user, not the agent, executes them.

Flow. (1) The panel sends the question with the current record context and the user’s token. (2) The copilot agent chooses among a small set of read-only tools to fetch the record and related data. (3) Tool calls pass through the tool gateway under the user’s identity, so the business system enforces its own permissions. (4) The agent answers and may propose a next step, such as a prefilled form. (5) Any change is executed by the user through the host application’s normal controls.

5.8 Archetype 8 — Bounded task agent (A3)

A bounded task agent completes a multi-step task whose path cannot be scripted in advance, inside an explicit envelope of tools, budgets and approval points. It is the first archetype in which the model directs the control flow, so the envelope is the main design artefact.

flowchart TD
    TR["Trigger<br/>user or event"] --> PL["Plan<br/>reviewable steps"]
    PL --> LOOP["Act loop"]
    LOOP --> PC{"Policy check<br/>tool, scope, budget"}
    PC -->|Read| RT["Read tools"]
    PC -->|Write| HA["Human approval"]
    PC -->|Denied| ESC["Escalate to owner"]
    HA --> WT["Write tools"]
    RT --> OBS["Observe + update state"]
    WT --> OBS
    OBS --> DONE{"Goal met or<br/>budget spent?"}
    DONE -->|No| LOOP
    DONE -->|Yes| RPT["Report + evidence"]

Every tool call passes the same policy check, and any side effect waits for approval until replay testing against recorded cases justifies widening the envelope.

The operational envelope is defined by the accountable owner and stored with the agent’s registry entry. An example for a bank’s cash-reconciliation team:

Flow. (1) A user or event triggers the agent with a goal. (2) The agent drafts a plan that is logged and, for higher-risk tasks, shown to the user. (3) In the loop, it selects tools; the policy engine enforces the envelope on every call. (4) Reads execute directly, writes create an approval task, denied calls escalate. (5) Observations update the run state. (6) The run ends on success, budget exhaustion or escalation, and produces a report with evidence and the full trace.

5.9 Archetype 9 — Research and analysis crew (A4)

A research crew uses a supervisor agent to break an open question into sub-questions, sends specialist agents to research them in parallel, and assembles a sourced report that an analyst owns. It trades cost and latency for breadth.

flowchart TD
    Q["Analyst brief"] --> SUP["Supervisor agent<br/>plan + task ledger"]
    SUP --> W1["Market and sector data agent"]
    SUP --> W2["Filings and document agent"]
    SUP --> W3["News and controversy agent"]
    SUP --> W4["Quantitative analysis agent<br/>sandboxed code"]
    W1 --> SYN["Synthesis agent"]
    W2 --> SYN
    W3 --> SYN
    W4 --> SYN
    SYN --> CRT["Critic agent<br/>sources, consistency"]
    CRT -->|Gaps| SUP
    CRT -->|OK| AN["Analyst review<br/>and sign-off"]

The critic can send the work back to the supervisor, but a hard budget caps the number of rounds.

Flow. (1) The analyst gives a brief with scope, permitted sources and deadline. (2) The supervisor writes a plan and task ledger, visible to the analyst. (3) Specialist agents work in parallel, each with its own narrow tool set and context, and return findings with source references. (4) The synthesis agent writes the report; every claim links to a source. (5) A critic checks source support, contradictions and coverage, and may request another round within budget. (6) The analyst edits and signs off. The report is marked AI-assisted and the trace is retained.

The banking illustration is deliberately a corporate borrower. Research used to assess the creditworthiness of a natural person would fall to be assessed against Annex III, point 5(b), of the AI Act (section 4.1).

5.10 Archetype 10 — Agent-driven department process (A4)

An agent-driven department process runs an end-to-end business process with a team of specialised agents owned by different people, coordinated through a durable workflow and supervised by wranglers who handle exceptions and own outcomes.

flowchart LR
    EV["Business event"] --> WF["Durable workflow<br/>process state"]
    WF --> AG1["Intake agent"]
    AG1 --> AG2["Check agent"]
    AG2 --> AG3["Preparation agent"]
    AG3 --> AP{"Approval"}
    AP --> AG4["Execution agent"]
    AG4 --> CL["Close + evidence"]
    WF --> WR["Wrangler console<br/>exceptions, KPIs"]
    AG2 -.->|A2A| EXT["Agent of other dept"]

The workflow holds the process state. No single agent does. Agents can therefore be replaced, versioned and scaled independently, and every transition is logged with the identity and version of the agent that made it.

Flow. (1) A business event starts a durable workflow instance, which moves through fixed states: received, checked, prepared, approved, executed, closed, with an exception state that returns to the wrangler. (2) Each stage is handled by a specialised agent with its own envelope, identity and owner. (3) Cross-department steps call other departments’ agents through the agent gateway, never through shared credentials. (4) Exceptions, low-confidence results and policy denials land in the wrangler console. (5) Approvals are enforced by the workflow, not requested by an agent’s prompt. (6) The execution agent performs approved actions through governed tools. (7) Evidence, performance indicators and costs are collected per instance.

On the incident control. Under DORA, a financial entity must have an ICT-related incident management process (Article 17) and must report major ICT-related incidents to its competent authority (Article 19) [13]. A failure in a department process that supports a critical or important function is a candidate for that process like any other ICT failure. The card’s control is that agent and workflow failures raise incidents in the same process, with the same classification, and are not handled in a separate AI channel.

On the A4 rating. Agency class A4 is defined by ownership: a design is A4 when it contains several agents with separate owners, identities, security boundaries or release cycles, and the next step may be decided by models, code, or both (section 2.2). Archetype 10 meets that definition. Each stage has its own agent, identity, envelope and wrangler.

Its spine is sequenced by code. Between stages the durable workflow decides the next step: transitions are coded, approvals are workflow states, and MA-SEQ is a code-orchestrated pattern. Only inside a stage does an agent decide. Under the control-flow test the process is therefore a workflow whose stations are agents. It keeps most of a workflow’s predictability, and it is easier to test and to explain than Archetype 9, where a model orchestrates. Where a stage uses MA-SUPER, model orchestration is confined to that stage.

The A4 controls apply all the same. An agent registry, authorisation between agents, replay testing and a kill switch per agent are needed because there are several separately owned identities, however the sequence is decided. The vendor guidance groups patterns the same way: Microsoft describes sequential orchestration, which chains agents “in a predefined, linear order”, among its multi-agent orchestration patterns [5], and Google Cloud lists a sequential pattern that runs agents “in a predefined, linear order” under multi-agent systems [6].

A reviewer should therefore read the card as A4 for its control bundle and as a workflow for its predictability and test effort.

One rule matters more than the rating. Assemble this archetype only after its stages already run stably as lower archetypes. A department process whose intake has never run as a document pipeline and whose check stage has never run as a review checker is ten unproven components in series.

6. How to choose an archetype

This section is a design proposal. Choosing takes two passes: find the agency class, then pick the archetype in that class.

6.1 Find the agency class

Five questions fix the agency class, and the default answer at each is the least agentic option that meets the need. They are the first five questions of Paper 01’s decision sequence [1].

flowchart TD
    Q1{"1. Is AI needed?<br/>rules or analytics enough?"} -->|No| Z["Use conventional software"]
    Q1 -->|Yes| Q2{"2. Prediction or generation?"}
    Q2 -->|Prediction| P["Classical machine learning"]
    Q2 -->|Generation| Q3{"3. Needs enterprise facts?"}
    Q3 -->|"No, and one call suffices"| A0["A0: Archetype 1"]
    Q3 -->|"Yes, or more than one step"| Q4{"4. Steps known in advance?"}
    Q4 -->|"One step over retrieved facts"| A1["A1: Archetypes 2, 3"]
    Q4 -->|"Several known steps"| A2["A2: Archetypes 3–7"]
    Q4 -->|No| Q5{"5. One coherent responsibility?"}
    Q5 -->|Yes| A3["A3: Archetypes 7, 8"]
    Q5 -->|No| A4["A4: Archetypes 9, 10"]

The first two questions remove more requests than people expect. A request that rules or a report would satisfy does not need an archetype. A request to predict a number or a class, such as a default probability, a fraud score or a lapse rate, is a classical machine-learning problem with its own model-risk regime, and none of the ten cards applies to it.

Each step up a class needs a reason, written down.

6.2 Choose between neighbours

Most real fitting decisions are between two adjacent archetypes. The rule is the same each time: take the simpler one unless the stated condition holds.

When a room cannot agree, I would not settle it by argument. Take the simpler archetype, ship it, and let its evaluation results show whether the harder one was needed.

6.3 Three requests, fitted

Three illustrative requests show the method. The firms are composites: each stands for a type of institution and none represents a real one.

At Insurer I, a composite life and non-life insurer, the claims function asks for “an agent that handles motor claims”. Taken apart, the request is four things: sorting the notification inbox (Archetype 5), extracting data from forms and estimates (Archetype 4), helping handlers find cover terms (Archetype 2 or 7), and, eventually, an end-to-end process (Archetype 10). The fit is to start with 5 and 4, which are both A2, and to treat 10 as something earned once those two run stably.

At Bank B, a composite retail and commercial bank, the credit function asks for “AI that writes credit memoranda”. The fit depends on which part. Gathering public information on a corporate borrower is Archetype 9. Checking a finished memorandum against the credit policy is Archetype 6. Drafting prose from the analyst’s own notes is Archetype 1. None of the three makes or recommends the credit decision, and the fitting exercise is what makes that visible.

At Asset Manager X, a composite multi-product asset manager, client reporting asks for “a chatbot on our fund data”. If the questions are about what the prospectus says, it is Archetype 2. If they are about flows and performance figures, it is Archetype 3, and the first task is to check that the metrics are defined.

In all three, the request named a technology and the fitting produced a smaller first step, in a lower agency class, than the requester had in mind.

7. When a use case fits none

A request that fits no archetype is not a failure of the request. It is information about the list. I would handle it in four steps. This is a design proposal.

First, check for a composition. Many requests that seem new are two archetypes in sequence. A router (5) that hands some items to a grounded assistant (2) and others to a bounded agent (8) is three cards, each applied to its own part, with the stricter controls governing the joins.

Second, check that it is a generative-AI problem at all. The first two questions in section 6.1 send some requests to conventional software or to classical machine learning. Those have their own design disciplines.

Third, design from the patterns and record the decision. If the request is genuinely outside the ten, design it from the pattern families of Paper 01 [1] using the same decision sequence, and write an architecture decision record that states: the problem and business owner; the classification code; the agency class chosen and every lower class rejected, with reasons; the patterns used per layer; the data class and lane; the control bundle and residual risks; the evaluation plan and acceptance thresholds; the accountable person; and the exit or fallback. A one-off design gets more review than an archetype instance, because nothing about it has been pre-approved.

Fourth, treat recurrence as a signal. When the same composition has been built a third time, that opens a decision on whether it should become a card of its own. Paper 01 is explicit that promotion is a judgement by the people who will own the result and not an automatic rule [1], and I follow it here. That decision is how the list of ten should become eleven: on evidence from the firm’s own portfolio.

I can name shapes the ten do not carry well, as my own judgement. The cards assume the user is an employee; a client-facing conversational channel adds conduct, disclosure and complaint-handling obligations that no card here sets out. No card uses a browser or computer-use agent as its main mechanism. No card covers fine-tuning a model. And no card is designed for decisions taken at machine speed with no human decision point, because every card that acts puts a person at the point of approval.

8. Limitations

Coverage has not been measured. The statement that ten archetypes cover most use cases is my design claim. It has not been tested against any institution’s use-case inventory, and I do not know what share of a real backlog fits. A firm should test it on its own.

The cards are a proposal, not a record of practice. Sections 3 to 7 describe a design. They are not drawn from a survey, and they are not evidence that any firm runs these archetypes as written. The control and evaluation rows have not been validated in production as a set.

A4 covers two kinds of design. Agency class A4 is defined by ownership, so it contains both model-orchestrated designs (Archetype 9) and code-sequenced ones (Archetype 10). The class alone does not tell a reader how predictable a design is. Section 5.10 states which kind Archetype 10 is; a reader comparing the two A4 cards should not assume they carry the same test effort.

The illustrations are generic. They were chosen to show each archetype in banking, insurance and asset management. They are not case studies, and the composites in section 6.3 are illustrative firms.

Regulatory statements are pointers. Section 4.1 cites the texts as of November 2026. It does not classify any system, and it is not legal advice. The AI Act’s application dates were amended in 2026 and may be amended again. The AI Act articles were read in the consolidated text published by the European Commission’s AI Act Service Desk, and GDPR Article 22 in the adopted text republished at legislation.gov.uk, not in the Official Journal itself. The DORA articles cited in section 5.10 were read in the Official Journal text on EUR-Lex.

Verification. Source checking for this paper was carried out with AI assistance on 10 November 2026. It is not peer review.

Dependencies on sibling papers. The codes and levels in section 2 are taken from Working Paper 01, and the data classes and lanes from Working Paper 09. If either paper changes a definition, the cards here change with it.

References

1. DEIXEI Research Series, Working Paper 01. AI Reference Architectures and Design Patterns: A Taxonomy for a Reuse-Driven AI Factory. November 2026.
2. DEIXEI Research Series, Working Paper 09. Data Classes, Processing Lanes and Controller/Processor Roles for AI. November 2026.
3. DEIXEI Research Series, Working Paper 10. MCP and A2A: Interoperability Protocols for the Enterprise AI Factory. November 2026.
4. Anthropic. “Building effective agents.” 19 December 2024. https://www.anthropic.com/engineering/building-effective-agents (accessed 10 November 2026).
5. Microsoft Learn, Azure Architecture Center. “AI agent orchestration patterns.” Page dated 12 February 2026. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns (accessed 10 November 2026).
6. Google Cloud, Cloud Architecture Center. “Choose a design pattern for your agentic AI system.” https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system (accessed 10 November 2026).
7. Model Context Protocol. “Specification”, version 2026-07-28. https://modelcontextprotocol.io/specification/latest (accessed 10 November 2026).
8. Agent2Agent (A2A) Protocol. “Specification”, version 1.0.0. https://a2a-protocol.org/latest/specification/ (accessed 10 November 2026).
9. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), OJ L, 2024/1689, 12.7.2024: Article 6(3), Article 14(1), Article 26(2) and (6), Article 50(1) and (4), Annex III point 5(b) and (c). Consulted in the consolidated text published by the European Commission, AI Act Service Desk, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6, /article-14, /article-26, /article-50 and /annex-3 (accessed 10 November 2026).
10. European Commission. “AI Act” (policy page, Shaping Europe’s digital future). https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (accessed 10 November 2026).
11. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), OJ L 119, 4.5.2016, p. 1: Article 22(1). Consulted in the text as adopted by the EU, https://www.legislation.gov.uk/eur/2016/679/article/22/adopted (accessed 10 November 2026).
12. legislation.gov.uk. Regulation (EU) 2016/679 (United Kingdom General Data Protection Regulation), Article 22, latest revised version, with the editorial note recording its substitution by the Data (Use and Access) Act 2025. https://www.legislation.gov.uk/eur/2016/679/article/22 (accessed 10 November 2026).
13. 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: Article 17 (ICT-related incident management process) and Article 19 (Reporting of major ICT-related incidents). https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng Read in the Official Journal text on EUR-Lex, 10 November 2026.
14. FINMA. “FINMA Guidance 08/2024: Governance and risk management when using artificial intelligence.” 18 December 2024. https://www.finma.ch/en/news/2024/12/20241218-mm-finma-am-08-24/ (accessed 10 November 2026).