I’m writing a book. It is called “Architekturmuster für Enterprise-KI” — roughly, architecture patterns for enterprise AI — with the subtitle “Multi-LLM-Systeme in regulierten Branchen einsetzen”, deploying multi-LLM systems in regulated industries. It will be published in German by Carl Hanser Verlag in 2027.
What it is about
As soon as more than one language model takes part in a workflow, the result depends less on any single model than on the layer around them. Which step gets which model? When does a workflow stop? Which data leaves your own network, and what of it is recorded? That layer is what the book is about.
When such a system produces unexpected results, the cause sits on one of three axes: the model, the context or the wording. The countermeasures differ by axis, and if you mix them up, you can spend weeks working in the wrong place.
The book gives two kinds of answer and keeps them apart. An architecture pattern is a structure: building blocks, how they relate, and the price you pay for them. A best practice is a working rule with no building blocks of its own. The patterns form a catalogue with problem, structure, price and maturity, the practices sit alongside them, and both get the same weight.
The argument behind it
A regulatory requirement is a design question, not a retrofit.
While researching, I came across something I had not expected: supervisory texts from drug development, financial services and aviation independently point in the same direction: the quality of results should be monitored after acceptance as well. They ask for it with differing strictness, and one of the three is still a draft. A point where a person is accountable is something older law in all three industries already demands.
An architecture that carries both — the monitoring and the accountable person — serves several regulatory regimes at once. The next regulation then costs an adjustment rather than a new project.
Who it is for
For anyone who plans, builds or is accountable for systems with several language models in regulated industries: architects, technical leads, and the people who ultimately answer for such a system. If you want to learn how to operate a particular tool, this is the wrong book. It is about the decisions that inevitably come up when building such systems — and how to tell when you got one wrong.
A real system as the example
The patterns become concrete in a real system: Cohereny, released today. In the book it is a running example, not a product pitch.
Why a real system rather than an invented one? Invented examples always work out. They have no legacy, no wrong decision from six weeks ago, no place where two assumptions contradict each other without anyone noticing. Yet those are exactly the places the book is about.
That includes being honest about what I can measure myself. My setup is small. Where a claim needs bigger hardware, the numbers come from other people’s studies, checked against the primary source. Where the book reports a measurement of my own, the command sits next to it, so you can repeat it on your own machine.
When it comes out
The book will be published in German by Carl Hanser Verlag in 2027. As soon as there is a date and a publisher’s page, both will be here.