Post 3 of 8 in the series on rebuilding a bank’s software development factory for the agentic era.

Block’s “From Hierarchy to Intelligence” is the most interesting organisational design published this year, and roughly half of it is illegal to implement in a supervised European credit institution.

That sounds like a complaint. It is not. The half that transfers is worth more than most transformation programmes deliver, and the half that does not tells you something precise about where human judgment still sits. The useful work is sorting the two, element by element, against named requirements rather than against a general feeling that banks are cautious.

So here is the sort. Three buckets: transfers directly, transfers with modification, does not transfer. XYZ Financial Services is the running case, a European private banking and asset management group under ACPR in France and BaFin in Germany, with works councils in two jurisdictions and a portfolio accounting core in production since 1997.

The table

Element of Block’s model	Verdict	Binding constraint
Capabilities as primitives with no UI, governed by reliability and compliance targets	Transfers directly	None binding
Interfaces as delivery surfaces, not where value is created	Transfers directly	None binding, has budget consequences only
Individual contributors as deep specialists in one layer	Transfers directly	None binding
A company world model built from the org’s own artifacts	Transfers with modification	Must be manufactured, not inherited. BetrVG § 87(1)(6), AI Act Annex III 4(b), GDPR Arts. 5(1)(b) and 6
A customer world model built from transaction signal	Transfers with modification, and changes identity	GDPR Art. 5(1)(b) and Art. 22, AI Act Annex III 5(b), banking secrecy
An intelligence layer that composes capabilities	Transfers with modification	MaRisk AT 8.2, AT 4.3.1, MiFID II Arts. 16(3) and 24(2)
Proactive autonomous delivery of what it composed	Does not transfer to regulated change	MaRisk AT 8.2 requires an approved, evidenced change process
Roadmap inversion: failure signal generates the backlog	Transfers with modification	The regulatory backlog is exogenous and dated
No permanent middle management	Transfers with modification	MaRisk AT 4.3.1, DORA Art. 5, KWG § 25c
A DRI with authority to pull resources across teams	Transfers with modification	Segregation of duties, delegated authority frameworks
“Money is the most honest signal” as the model’s fuel	Does not transfer to a software factory	Purpose limitation, and the factory has a better signal
Remote-first artifact production as raw material	Does not transfer as found	The work is not machine-readable today
The company as an intelligence, the mini-AGI framing	Does not transfer	DORA Art. 5, MaRisk AT 3, AI Act Art. 14

Four of these need arguing. The rest of the table can stand on its own.

The customer world model changes identity

Block’s customer world model is a per-customer, per-merchant representation built from proprietary transaction data, and their essay is explicit that this signal fuels everything above it. They see both sides of millions of transactions. It is a genuine asset and it compounds.

A European bank cannot copy this into its software factory, and the reasons are specific. GDPR Art. 5(1)(b) limits processing to the purposes for which data was collected. Profiling clients to compose products proactively engages Art. 22 wherever the outcome has legal or similarly significant effect. Anything evaluating the creditworthiness of natural persons lands in Annex III point 5(b) of the AI Act and becomes a high-risk system with the full conformity apparatus attached. French and Luxembourgish banking secrecy sit on top of all of it.

None of that makes customer intelligence impossible for a bank’s product side. It makes it a separate, heavily governed programme with its own provider obligations and its own signatures, and it is not what a software factory builds.

The honest translation is a different object entirely: a domain world model. How the factory understands the bank it serves. Business domain maps, system topology, data lineage, the obligations register linking each regulatory requirement to the systems that discharge it, and above all the recovered semantics of the legacy core. The business rules that exist only in code written before the euro, and in the memory of people with retirement dates.

That asset compounds the way Block’s does. Every recovered rule makes every subsequent change to that area cheaper and safer, permanently, for humans and agents alike. Unlike Block’s asset it has a deadline attached, because recovery requires people who can validate what an agent extracts. Five years from now the validation cost triples.

Proactive delivery does not transfer at all

In Block’s essay a restaurant heading into a seasonal dip gets a short-term loan with an adjusted repayment schedule, composed and surfaced before the owner goes looking for financing. No product manager decided to build it. That is the sharpest illustration in the piece.

A bank’s factory does not get to ship a change to the portfolio accounting engine because a model judged the moment right.

MaRisk AT 8.2 requires a defined process for changes to material IT systems, with impact analysis, testing, and approval before productive use. The four-eyes principle running through AT 4.3.1 requires a second qualified assessment on material changes. Anything reaching clients passes product governance obligations under MiFID II Arts. 16(3) and 24(2), transposed through the AMF’s rulebook for the French entities, which assume identified humans exercised identifiable judgment.

The modification is a tiered autonomy model rather than a binary. At the low end, an agent bumping a dependency in an internal tool, with green tests and a passing policy check, merges under post-hoc human sampling. At the high end, an agent prepares everything (the diff, the test evidence, the impact analysis, the draft change record with affected obligations listed) and a named human decides, with the decision recorded against their identity.

Those tier boundaries are not a team convention. They are controls with owners, and the map assigning change classes to gates is itself a governed artifact that internal audit will ask to see. Post seven covers how it is built.

Remove the layer, keep the signature

This is the placement everyone reads first, so let me be precise about what a manager in a bank actually does.

Part of the job is information routing. Collecting status. Reconciling two teams’ divergent understanding of a dependency. Re-explaining, for the fourth time, a priority decision taken three levels up. Block is right that this half is replaceable, and a delivery world model reading the repositories, pipelines, tickets and incident record does it better, continuously, without occupying a Thursday.

The other part of the job is holding accountability. Being the named individual who approved a production change to a system in scope, the person whose identity the auditor finds at the end of the trail.

That half is a liability function, not an information function, and no world model can hold it. MaRisk AT 4.3.1 and the segregation of duties architecture behind it presuppose accountable natural persons. DORA Art. 5 places accountability for the ICT risk framework on the management body and requires the delegation beneath it to be traceable. KWG §§ 25a and 25c attach personal duties to the people running the institution.

An audit trail terminating in “the orchestration layer approved it” is a finding. In a bad year it is a finding with a fine behind it.

So the modification is exact: remove the layer, keep the signature. A bank should end up with materially fewer people whose job is knowing what is happening, and precisely the same number of named people accountable for what happened. In practice that means the accountability currently diffused across team leads and delivery managers gets reassigned explicitly into role definitions, in writing, reviewed by compliance, before any structural change is announced.

The failure I expect, and have watched in adjacent form, is an organisation that announces the removal of a management layer and discovers in month six that nobody holds approvals the control catalogue assumes exist. Write the accountability into the role definition, not into the transition plan.

The framing does not transfer, and that is not the same as rejecting the design

Block describes the goal as a company built as an intelligence, a mini-AGI. Inside a US fintech, as an engineering north star, that is a reasonable thing to say.

Inside a supervised credit institution it is an actively dangerous framing, because it licenses designs in which the system is treated as the deciding entity, and every European instrument touching this domain assumes the opposite. DORA Art. 5 makes the management body accountable for the ICT risk framework. MaRisk AT 3 makes it responsible for proper business organisation. AI Act Art. 14 requires effective oversight by natural persons for high-risk systems, and Art. 26 places specific obligations on deployers.

The supervisor’s model is stable and will not move in this cycle. Humans accountable, systems assisting, evidence connecting the two.

The correct translation is that the factory acquires an intelligence layer which humans direct and answer for. Everywhere the rest of this series reads as more conservative than Block’s essay, this is usually the reason, and I would rather state it once than apologise for it in every post.

One thing that surprised me

The company world model, the part I expected to be easiest, has the sharpest European constraint on it, and it has nothing to do with banking.

A delivery world model reads commits, pipeline runs, review comments and ticket transitions. That means it processes personal data about identifiable employees, and it can trivially be turned into individual performance surveillance. In Germany, § 87(1)(6) of the Betriebsverfassungsgesetz gives the works council co-determination over technical systems suitable for monitoring employee behaviour or performance, and this system plainly is one. In France, Article L.2312-8 of the Code du travail requires information and consultation of the CSE on new technologies affecting working conditions. And under the AI Act, Annex III point 4(b) classifies workplace performance evaluation systems as high-risk, which pulls in risk management under Art. 9, technical documentation under Art. 11, logging under Art. 12, and human oversight under Art. 14.

Building a system that answers “rank my developers” is therefore a decision to build a high-risk AI system. It should be taken deliberately or, as I would advise, not taken.

The design consequence is concrete. The delivery world model must be scoped to answer questions about flow, systems, dependencies and control posture, and must be demonstrably incapable of producing individual performance assessments. Aggregation thresholds below which it declines to answer. No per-individual output surfaces. Access control that governance and the works councils review and sign before the first index is built.

I have watched a delivery analytics programme die in month nine because this was handled as a deployment detail rather than a design constraint. Write it down first, get the signatures, then build.

Next post is the architecture itself: five layers, two world models, and the workstream that every transformation skips because it looks like documentation.