Research

AI Reference Architectures and Design Patterns

A Taxonomy for a Reuse-Driven AI Factory

No single published AI reference architecture is sufficient for a regulated financial institution that wants to deliver AI applications repeatedly instead of one project at a time. Hyperscalers describe lifecycle and quality, practitioners describe composition, academics describe trade-offs, standards bodies describe interfaces, and regulators describe obligations. This paper reads those sources side by side and consolidates them into one taxonomy with three axes: the **layer** a component lives in, the **pattern family** a capability is built from, and the **reuse generation** an asset has reached. Five descriptive attributes, of which the design-time **agency class** is the most consequential, complete a compact classification code that search, policy-as-code and architecture review can all read. The paper then gives the selection framework that goes with the taxonomy: an eight-question decision sequence, escalation criteria that require evidence for every step up in agency, a trade-off matrix, the fields of a design record, and a consequence check. The survey of sources is evidence. The taxonomy, the codes and the decision framework are the author's design proposal, written for banks, insurers and asset managers in the EU, the UK and Switzerland.

November 2026 Version 1.0 54 min read

Ten Solution Archetypes for Regulated Finance

This paper proposes ten solution archetypes as the starting points for AI applications in a regulated financial institution: a bank, an insurer or an asset manager in the EU, the UK or Switzerland. An archetype is a named composition of design patterns with a fixed agency class, a control bundle, an evidence trail and an evaluation method. The ten run from a content assistant that makes one model call on text the user supplies, to a department process run by several separately owned agents on a durable workflow. Each is given as a design card with the same rows, illustrated with use cases from banking, insurance and asset management. The paper's claim is that a request which starts from an archetype has its agency class, controls and evidence settled before design work begins, and that a small set of archetypes covers most requests. The first half of that claim follows from how the cards are built. The second half is my design judgement and has not been measured. It sets out the three routes by which code reaches execution in an AI system, how to choose between neighbouring archetypes, and what to do when a use case fits none.

November 2026 Version 1.0 47 min read

Securing Claude Code in the Enterprise

Claude Code is an agentic coding tool that reads files, runs shell commands, edits code and calls external tools for a developer or a pipeline. That makes it a different security object from a chat assistant. This paper gives a regulated financial institution a control baseline for it across a reference estate: Microsoft-managed Windows endpoints and virtual desktops, Linux developer environments, a CI/CD service and an OpenTelemetry backend. The controls sit in five layers: identity and tenancy, centrally managed policy, runtime isolation, network and data protection, and monitoring. Every settings key, path, flag and product claim was checked against the vendors' documentation on 10 November 2026 and is cited to it; several widely repeated claims proved out of date, and the paper says which. Three points carry the argument. The permission engine is configuration inside the process it constrains, so it needs an operating-system and network boundary behind it. Managed policy sources do not merge by default, so a firm must choose one. And an agentic pipeline stage should hold no privilege: it produces artefacts, and a separate non-agentic stage is gated. The settings will date; the paper ends with a way to re-check them.

November 2026 Version 1.0 46 min read

Technology Management and Agent Readiness

Why the Production Line Runs at the Speed of Its Least-Ready Shared Station

Technology management — the technology radar and lifecycle, version discipline, platform standardisation, deprecation and golden paths — has long been funded as hygiene. This paper argues that it now decides how much of a regulated financial institution's estate AI coding agents can work on. Agent readiness is treated as a property of a codebase, platform and toolchain, not of a model, and is decomposed into four properties: describability, verifiability, reversibility and observability. Because change in a large estate crosses many systems, delivery pace is set by the least-ready station on each change's path, and shared legacy systems sit on most paths; average readiness says little. The paper reviews the published evidence (the DORA research programme, METR, GitClear, public benchmarks, vendor readiness products), separates it from the argument built on it, and proposes instruments: readiness recorded as checkable facts that route work, a third axis on the radar, deprecation reviewed with agent economics on both sides, golden paths that are unpublished until their agent-readable form ships, a duty to keep legacy systems agent-recoverable, and outcome measures in place of scores. Regulatory claims are stated narrowly and as of November 2026.

November 2026 Version 1.0 32 min read

Mission and Values of the AI Factory

What Changes When the Values Document Is Executed

Mission and values statements were written for people, who interpret them, discount them and, when the statement contradicts the incentive, follow the incentive. In a delivery organisation where AI agents do much of the work, the same statements are also read by machines: they are compiled into system prompts, reusable skills, policy rules, criteria for granting autonomy and stop conditions. This paper argues that this changes what a mission has to be for a regulated financial institution's AI factory. The mission must be derived from the parties the factory serves and answers to, the values must be few and ordered, and the whole must be versioned like any other machinery. The central proposal is a test: a value is real when it has an owner, a policy, a metric and a veto. From it follow a "control budget" modelled on the site-reliability error budget, a way of reading the firm's revealed values from the vetoes fired and waivers granted in its audit record, a two-compiler test, and a six-step method. The paper separates published evidence from argument, states where its main precedent is weaker than it first appears, and says plainly that measuring the control budget is unsolved.

November 2026 Version 1.0 32 min read

The AI Factory versus the Software Factory

What Nearly Sixty Years of Factory Ambition Teach About Product Development at Agent Speed

The software factory is an idea from 1968 that has been attempted in every decade since: at System Development Corporation, in the Japanese factories Michael Cusumano documented, in CASE and model-driven development, in Microsoft's Software Factories, in software product lines and in platform engineering. This paper reads that record as a catalogue of failures and argues one thesis from it. Every earlier wave industrialised the work around construction while the engineer who did the construction stayed scarce. Coding agents are the first construction labour whose capacity follows a budget line, so the constraint on delivery moves to verification and to discovery, and each historical failure has a live descendant: the separation of design from construction that undid the first factory returns as a specification department feeding an agent pool, and the cost of building domain-specific languages returns as specification bureaucracy. The historical half of the paper is evidence, checked against the sources and corrected where the common account is wrong. The agent-era half is argument, supported by a small amount of 2024–2026 evidence, and its section on product management is conjecture. The paper closes with what a CIO in a regulated financial institution would do differently.

November 2026 Version 1.0 30 min read

Build, Configure or Consume

Sourcing Decisions When Agents Make Code Cheap

AI coding agents have made code cheap to produce, and a common inference follows: build everything as code. This paper tests that inference against the evidence published in 2025 and 2026 and finds that it does not hold as a general rule. The measured wins for agent-written code sit in one category, the rewrite and migration of existing systems. Everywhere, agent-written code carries structural costs: human review, rework, a delivery-stability penalty and a maintenance liability. And the choice between building and configuring is dissolving, because low-code platforms are becoming governance hosts for agent-written code. The paper is written for a regulated financial institution in the EU, the UK or Switzerland. It separates the evidence from the argument, discloses that the first verification pass was done by panels of AI agents, and reports a second check of every retained figure on 10 November 2026, including a table of claims that failed. It ends in a proposed four-gate framework (differentiation, agent-operability, ceilings and exit, honest return on investment) and applies the same logic to model sourcing, where renting is an economics question and owning is a control question.

November 2026 Version 1.0 34 min read

Reusability and the Compounding Factory

The business case for an AI factory in a regulated financial institution rests less on agents writing code faster than on a few shared assets whose value grows with every product team that consumes them. I argue that a shared asset compounds only when three loops run on it — amortisation, quality and evidence — and that the loops run only when five conditions hold: the asset is discoverable at the moment of need, trusted by evidence, versioned with a governed upgrade path, owned and funded as a product, and fed back by its consumers. AI coding agents move both ends of the reuse trade: producing an asset fit for reuse becomes cheaper, and copying becomes free. Which effect wins is decided by the governance of what goes into an agent's context, because an agent does not browse a catalogue. The paper ranks asset classes by how strongly they compound, derives a build order (schema and policy first, then services, then templates, code libraries last), prices the concentration risk that compounding creates, and states the regulatory position under Regulation (EU) 2022/2554 as of November 2026. The mechanism is argument; no published measurement of reuse in agent-driven estates was found.

November 2026 Version 1.0 28 min read

Data Classes, Processing Lanes and Controller/Processor Roles for AI

A language model has to see data to work on it, and it often sees that data on somebody else's infrastructure. For a regulated financial institution this turns two governance questions into design-time questions: how confidential is the information in this request, and where and by whom may it be processed. This paper proposes an answer in three parts. Four **data classes** (C1 to C4) with five category flags describe the information. Three **processing lanes** (A, B and C) describe the route to a model by who operates the inference and who can see the data. A **permission matrix** joins the two and is enforced per request, with four inheritance rules that stop derived artefacts — embeddings, traces, memory, fine-tuned adapters — from escaping the class of their sources. The paper then maps each party in an AI system to its role under data-protection law and under the EU AI Act, lists the vendor terms that decide which lane a model belongs to, and gives a short regulatory map for the EU, the UK and Switzerland. The classes, lanes and matrix are the author's design proposal. The regulatory statements are cited to the primary texts and are not legal advice.

November 2026 Version 1.0 45 min read

MCP and A2A

Interoperability Protocols for the Enterprise AI Factory

Two open protocols now carry most of the interoperability work in enterprise agentic AI. The Model Context Protocol (MCP) standardises how an AI application reaches tools and data. The Agent2Agent Protocol (A2A) standardises how one agent delegates work to another without seeing inside it. This paper summarises both as they stood on 10 November 2026 (MCP specification revision 2026-07-28, A2A specification version 1.0.0) and then argues that neither is a control layer: the MCP specification says so itself, and independent analysis reaches the same conclusion. The larger part of the paper is a design proposal for a regulated financial institution. It gives a heuristic for deciding whether a capability is a tool or an agent, four platform products that make the protocols governable (an MCP server catalogue, an MCP gateway, an A2A agent registry and an A2A gateway), three reuse rules of which "wrap once" is the first, a threat model that treats token passthrough in detail, and a four-phase adoption sequence. The protocol summary is evidence and is cited. The platform design is the author's proposal and has not been tested in a controlled way.

November 2026 Version 1.0 30 min read