Die sicherste Art ein Vorhaben in den Sand zu setzen ist es an den falschen Stellen zu verkomplizieren und es gleichzeitig an den falschen Stellen zu vereinfachen.

Seit ich ein Teenager bin arbeite ich. Ich bin jetzt 48 Jahre alt. Es gibt nichts, was ich nicht gesehen habe, wenn es um Software, Data, Projekte, Politik und Menschen geht.

Nun mit KI ist es wieder das Gleiche.

Und dann gibt es die Gegenbeispiele, die es richtig gut hinbekommen.

Ich will jetzt gar nicht alle Negativbeispiele aufzählen, Du kennst sie eh alle aus Deinem eigenen Berufsleben.

Ich will auch nicht stundenlang analyiseren woran es liegt.

Ich will heute nur beschreiben und zum Nachdenken anregen.

Stellen wir uns ein Unternehmen vor, das eine KI Transformation durchführen will.

Was hilft und was erschwert?

Stellen wir uns einen neuen Kundenprozess vor, der erst duch KI überhaupt möglich wird.

Stell Dir nun vor wie ein Projekt ins Leben gerufen wird, ein Projektleiter oder Product Owner wird ernannt, der bekommt dann jemanden für die Anforderungsanalyse. Dieser Business Analyst arbeitet bei einer Unternehmensberatung, die nach Länge des Vorhabens bezahlt wird. Dann werden drei Engineers geholt, alle extern. Natürlich müssten Facharchitekten, Systemarchitekten, Tech Leads und KI Berater mit ins Boot geholt werden. Zusätzlich gibt es einen Programmleiter, Heads und VPs of alles mögliche, viele Stakeholder, viele Business Leads, eine richtig große Truppe kommt da zusammen. Natürlich noch die Teamleiter, Coaches und Psychologen.

Jeder steht unter Druck und Strom, keiner weiß wie es richtig geht, denn wir ehrlich zueinander sind, ist die Entwicklung von KI so rasend schnell, dass es unmöglich ist zu wissen wie es geht. Kaum hat man was gebaut, ist es schon veraltet.

Stell Dir diese Gemengenlage vor. Hast Du dabei ein gutes Gefühl?

Mit Sicherheit nicht.

Je mehr Menschen, je mehr Verwirrung. Je mehr Interessen, desto größer die Politik.

Jeder wird sein Bestes geben. Jeder hat gute Beweggründe. Alle sind gut in ihrem Fach. Daran liegt es nicht.

Die wichtigeren Personen in diesem Spiel werden das Vorhaben zu sehr vereinfachen. Man ist zu weit weg von der Technik. Man will Optimismus ausstrahlen. Man hat gar nicht die Zeit sich tief hinzuarbeiten. Es ist auch nicht deren Job.

Es werden Pläne gemacht, es werden Folien gemalt. Es klingt alles toll. Es ist auch nicht falsch, was gesagt wird. Es ist aber nicht genau und nicht spezifisch genug. Im Zweifelsfall steht dann sowas wie “Engineering Team” drauf, oder “Tech Lead” oder “Architect xyz” als Ersatz für Genauigkeit.

Die externen Experten hängen sich mächtig ins Zeug. Da wird geklotzt und nicht gekleckert. Die Anforderungen sind minutiös aufgeschrieben, alle Trillionnen Stakeholder wurden befragt, es wurde keiner ausgelassen.

Parallel wurden zig Workshops abgehalten mit zig Leuten und alle sind sich total einig.

Hunderte Tickets sind erstellt, das Backlog gefüllt, die Pläne gemacht, jetzt muss das Engineering Team nur noch liefern.

Und dann gehen die Probleme los. Ich erspare Euch die Details. Ihr kennt das eh alle.

Nehmen wir mal diese Stichwörter:

• Angst

• Innovation

• Macht

• Anerkennung

• Spiel

• Geselligkeit

• Silos

• Gruppenzwang

• Neugier

• Technologie

• Unwissenheit

• Geld

• Zeit

• Konkurrenz

• Unsicherheit

• Transzendenz

• Konflikte

• Erfolg

• Markt

• Kunden

• Systeme

• Tools

• Hürden

• Daten

• Chaos

• Wachstum

• Spaß

• Ausdehnung

• Verwirrung

• Verschwendung

• Irrtum

• Chancen

• Erkentnisse

• Fehler

• Zufälle

• Überraschungen

• Wartung

• Strukturen

• Abhängigkeiten

• Ideen

• Unübersichtlichkeit

• …

Wie willst Du durch einen Plan all dies in den Griff kriegen?

Die Antwort ist völlig eindeutig: GAR NICHT.

Es geht nicht.

Kannst Du all das durch Führung von Menschen in den Griff kriegen?

Die Antwort lautet ganz klar: NEIN.

Es ist irrsinnig zu glauben, dass man Herr der Lage wird durch Motivation allein.

Wie geht es dann?

Die schlechte Nachricht: Du musst alles GLEICHZEITIG beherrschen.

Die gute Nachricht: Es gibt Methoden, die helfen.

Wie kann man es schaffen nicht an den falschen Stellen zu vereinfachen?

Indem man identifiziert, was wichtig ist. Und zwar präzise.

Im Idealfall ist es ein Satz, in dem das Wort Kunde drin vorkommt. Vielleicht brauchst Du auch mal 2-3 Sätze. Wenn Du 20 Sätze brauchst, um zu erklären, wie dieses KI Vorhaben dem Kunden was bringt, dann brich sofort ab.

Lass es.

Setze komplett neu an. An anderer Stelle.

Wenn Du identifiziert hast, was wichtig ist, dann lege fest, wie Du es messen willst. Es muss messbar sein. Und es ist nicht immer ROI. Es kann auch etwas ganz anderes sein. Ich widerspreche allen, die behaupten, es geht immer nur um Return on Invest.

Wenn es nur um Geld gehen würde im Business, wären automatisch alle illegalen Geschäfte, denen es nur ums Geld geht, akzeptabel. Und da ist Humbug.

Es geht um WERT. Werte. Darum geht es. Es kann verschiedene Arten von Business Value geben. Der Business Value muss am Ende irgendwie was mit dem Kunden zu tun haben. Sonst ist es kein gesundes werthaltiges Geschäftsmodell.

Ok Du weißt nun was der Wert ist, der erzeugt werden soll durch KI und wie Du diesen misst. Es können auch mehrere Werte sein.

Nun brauchst Du Leute, die das verstehen, bauen, liefern, veranworten und kontinuierlich verbessern können, was diesen Wert liefert.

Du brauchst nicht: Leute, die das koordinieren. Leute, die eine Meinung haben. Leute, die Interessen haben. Leute, die andere Leute steuern wollen. Leute, die sich nur für eine bestimmte Sache verantwortlich fühlen.

Vereinrache radikal das ganze menschliche und organisatorische Setup.

Verstehe bis in die Tiefe die Komplexität der technologischen Herausforderung, der Menschen, deren Gefühle, der Kundenprobleme, des Marktes, die Komplexität der eigenen Prozesse und Daten und vor allem wie aus all dieser Gemengenlage sich Systeme bilden und welche Dynamiken daraus entstehen.

Reduziere die Komplexität der Organisation maximal an allen Stellen, wo Du es tun kannst. Und betrachte die Komplexität des Vorhabens genau.

Die Personen, die daran arbeiten, müssen sich detailliert in die Thematik einarbeiten können und gleichzeitig Zug zum Tor haben. Das ist die große Kunst.

Verstehen wie die neue Technologie mit KI funktioniert und gleichzeitig zügig etwas wethaltiges stabiles liefern.

Das wird niemals sofort klappen! Never ever!

Das wird ein kontinuierlicher Lern- und Verbesserungsprozess.

Zug zum Tor. Darum geht es.

Der Kunde muss zufrieden sein. Der Wert muss erzeugt werden. Und zwar in kurzen, regelmäßigen Abständen, nachweisbar gemessen.

Um das zu schaffen, muss ganz viel anderes vollständig von der Tagesordnung gestrichen werden.

Zig Anforderungen müssen ersatzlos gestrichen werden. Nicht zurück ins Backlog. LÖSCHEN! Wenn es keinen Wert erzeugt - und zwar der, der vereinbart wurde, muss es WEG!

Oh, es fühlt sich eine Person dadurch auf den Schlips getreten? Dann erkennst Du, dass Dein Setup noch nicht gut genug war. Wieso hast Du Personen im Setup, deren Meinung nicht auf den vereinbarten Wert einzahlt? Zurück zu den Hausaufgaben.

Zig Versuche müssen gekillt werden. Sofort stoppen und streichen, wenn es nicht zum Ziel führt.

Oh, es steht aber auf dem Plan und wir haben es zig Leuten auf zig Folien gezeigt? Tja, Pech, in diesen sauren Apfel musst Du beißen. Wenn der Versuch keine Wert erzeugt hat, muss er gestrichen werden. Ich hab Dir ja gesagt Du sollst nicht planen.

Zig Dinge, die niemand vorher bedacht hatte, müssen auf einmal beachtet werden. Genau! Willkommen in der Realität! Schau Dir die Liste von vorher nochmal an. Kein Mensch kann all das im Voraus planen. Dein Setup muss so aufgebaut sein, dass Du SOFORT auf all die Unwägbarkeiten eingehen und sie in einen Erfolg verwandeln kannst.

Oh hoppla, Du schaffst es nicht sofort zu agieren, weil erst zig Leute vorher ein Wörtchen mitreden wollen? Genau, Du lernst es langsam. Zu viele Leute.

Zig Fragen, die noch kein Engineer vorher gehört hat, geschweige denn beantworten kann. Richtig. KI ist neu. Alles, was wir hier tun ist Neuland. Jeder lernt jeden Tag etwas Neues. Vieles ist noch gar nicht erfunden.

Und damit sind wir am Kern angelangt: Erkenne das an.

Erkenne an, dass es keine sofortigen Antworten gibt, gar nicht geben kann.

Der Komplexität muss ins Auge gesehen werden, aber ohnmächtig werden muss man auch nicht.

Ein kleines Team, das alle Skills vereint, fachlich wie technisch, kann gemeinsam Schritt für Schritt Lösungen finden.

Der Kunde, der Markt, der Prozess wie man zum messbaren Wert gelangt, die Technologie, die das ermöglichen soll, die Systeme, in das das hineingebettet werden soll, die Daten, die man hierfür braucht, all das muss erst gründlich verstanden und dann stetig vereinfacht werden. Der messbare Wert ist der Nordstern.

Das erfordert die notwendigen Skills dafür gemeinsam in einem Team und das erfordert Ruhe, Konzentration, Unterstützung, Hilfe und Verantwortung.

Alles, was dies stören und keinen Wert erzeugen würde, muss weg.

Erst wenn Du das im kleinen hinbekommen hast, erst wenn das mal produktiv stabil läuft und weiterhin messbaren Wert erzeugt, erst dann bist Du bereit es zu skalieren. Vorher nicht.

Wenn Du es im kleinen nicht schaffst, schaffst Du es auch nicht im Großen. Binsenweisheit.

Du kannst es Dir vielleicht schon ein wenig vorstellen. Und Du spürst es vielleicht: es erfordert sehr viel Mut das durchzuziehen.

In manchen Organisation würde das alles auf den Kopf stellen.

Aber ich sehe es als Chance.

Du hast durch KI die Chance neu zu denken. Nicht nur neue Geschäftsmodelle, auch neue Arbeitsweisen, Organisationen, eine neue Art zu denken. Dies kann auch eine Chance für alle sein. Es muss niemand auf der Strecke bleiben. Es kann sich für alle zum Besseren wenden, wenn man es nur will.

Ergreife die Chance.

Fange jetzt schon an tiefer einzutauchen, da wo die Komplexität verstanden werden muss um Wert zu erzeugen. Und fange jetzt schon an radikal zu vereinfachen und zwar da, wo nicht nur kein Wert erzeugt wird, sondern Wert gemindert wird.

Es kann ein befreiender Neuanfang sein. Sei mutig und tu es.

The surest way to burn time and money is to overcomplicate it in the wrong places while oversimplifying it in the wrong places.

I have been working since I was a teenager. I am now 48 years old. There is nothing I have not seen when it comes to software, data, projects, politics and people.

Now with AI it is the same thing all over again.

And then there are the good examples that get it really right.

I will not list all the negative examples now, you know them all from your own professional life.

I also do not want to spend hours analyzing why things go wrong.

I just want to describe and provoke some thinking today.

Let us imagine a company that wants to carry out an AI transformation.

What helps and what gets in the way?

Let us imagine a new customer process that only becomes possible through AI.

Now imagine how a project is launched, a project manager or product owner is appointed, they get someone for requirements analysis. This business analyst works for a consulting firm that is paid by the length of the engagement. Then three engineers are onboarded, all external. Of course, domain architects, system architects, tech leads and AI consultants need to be brought on board. On top of that there is a program manager, heads and VPs of all sorts of things, many stakeholders, many business leads, you end up with a small army. And of course the team leads, coaches and psychologists.

Everyone is under pressure and stress, nobody knows how to do it right, because if we are honest with each other, AI is evolving so rapidly that it is impossible to know how to do it right. By the time you have built something, it is already outdated.

Imagine this situation. Does it give you a good feeling?

Certainly not.

The more people, the more confusion. The more interests, the greater the politics.

Everyone will do their best. Everyone has good intentions. Everyone is good at what they do. That is not the problem.

The more important people in this game will oversimplify the undertaking. They are too far removed from the technology. They want to spread optimism. They simply do not have the time to work their way deep into it. It is also not their job.

Plans are made, slides are painted. It all sounds great. What is said is not wrong either. But it is not precise and not specific enough. When in doubt, the slide says something like “Engineering Team” or “Tech Lead” or “Architect xyz” as a substitute for precision.

The external experts throw themselves into it with full force. No expense is spared. Requirements are written down meticulously, all trillions of stakeholders have been consulted, no one was left out.

In parallel, dozens of workshops were held with dozens of people and everyone is in total agreement.

Hundreds of tickets are created, the backlog is filled, the plans are made, now the engineering team just has to deliver.

And then the problems start. I will spare you the details. You all know this anyway.

Let us take these keywords:

• Fear

• Innovation

• Power

• Recognition

• Play

• Sociability

• Silos

• Groupthink

• Curiosity

• Technology

• Ignorance

• Money

• Time

• Competition

• Uncertainty

• Transcendence

• Conflicts

• Success

• Market

• Customers

• Systems

• Tools

• Hurdles

• Data

• Chaos

• Growth

• Fun

• Expansion

• Confusion

• Waste

• Error

• Opportunities

• Insights

• Mistakes

• Coincidences

• Surprises

• Maintenance

• Structures

• Dependencies

• Ideas

• Overwhelm

• …

How do you intend to get all of this under control through a plan?

The answer is completely clear: YOU CANNOT.

It is not possible.

Can you get all of this under control through leading people?

The answer is very clear: NO.

It is insane to believe that you can master the situation through motivation alone.

So how does it work then?

The bad news: You have to master everything SIMULTANEOUSLY.

The good news: There are methods that help.

How can you avoid oversimplifying in the wrong places?

By identifying what matters. Precisely.

Ideally it is one sentence that contains the word customer. Maybe you need 2 or 3 sentences. If you need 20 sentences to explain how this AI initiative benefits the customer, then stop immediately.

Drop it.

Start over completely. Differently than before.

Once you have identified what matters, determine how you want to measure it. It must be measurable. And it is not always ROI. It can be something entirely different. I disagree with everyone who claims it is always only about return on investment.

If business were only about money, then automatically all illegal businesses that are only about money would be acceptable. And that is nonsense.

It is about VALUE. Values. That is what it is about. There can be different kinds of business value. The business value must ultimately have something to do with the customer. Otherwise it is not a healthy value generating business model.

Ok so now you know what the value is that AI is supposed to create and how you measure it. There can also be multiple values.

Now you need people who can understand, build, deliver, own and continuously improve what delivers this value.

You do not need: People who coordinate. People who have an opinion. People who have interests. People who want to control other people. People who only feel responsible for one specific thing.

Radically simplify the entire human and organizational setup.

Understand in depth the complexity of the technological challenge, of the people, their emotions, the customer problems, the market, the complexity of your own processes and data and above all how systems form out of this entire mix and what dynamics emerge from them.

Reduce the complexity of the organization to the maximum at every point where you can. And examine the complexity of the undertaking carefully.

The people working on this must be able to dive deeply into the subject matter and at the same time have drive towards the goal. That is the great art.

Understanding how the new technology with AI works and at the same time delivering something valuable and stable at pace.

This will never work immediately! Never ever!

It will be a continuous process of learning and improvement.

Drive towards the goal. That is what it is about.

The customer must be satisfied. The value must be created. In short, regular intervals, measurably proven.

To achieve this, a lot of other things must be completely removed from the agenda.

Countless requirements must be deleted without replacement. Not back into the backlog. DELETE! If it does not create value, the value that was agreed upon, it must GO!

Oh, someone feels stepped on? Then you realize your setup was not good enough. Why do you have people in the setup whose opinion does not contribute to the agreed upon value? Back to the drawing board.

Countless attempts must be killed. Stop immediately and cut them if they do not lead to the goal.

Oh, but it was on the plan and we showed it to dozens of people on dozens of slides? Well, tough luck, you will have to bite that bullet. If the attempt did not create value, it must be cut. I told you not to plan.

Countless things that nobody had thought of before suddenly need to be considered. Exactly! Welcome to reality! Look at the list from before again. No human can plan all of this in advance. Your setup must be built so that you can IMMEDIATELY respond to all the uncertainties and turn them into a success.

Oh wait, you cannot act immediately because dozens of people want to have a say first? Exactly, you are slowly getting it. Too many people.

Countless questions that no engineer has ever heard before, let alone can answer. Right. AI is new. Everything we are doing here is uncharted territory. Everyone learns something new every day. Much of it has not even been invented yet.

And with that we have arrived at the core: Acknowledge this.

Acknowledge that there are no immediate answers, that there cannot be.

The complexity must be faced, but you do not have to be paralyzed by it.

A small team that combines all skills, domain and technical, can find solutions together step by step.

The customer, the market, the process of how to reach measurable value, the technology that is supposed to enable it, the systems it needs to be embedded in, the data that is needed for it, all of this must first be thoroughly understood and then continuously simplified. The measurable value is the north star.

This requires the necessary skills together in one team and it requires calm, focus, support, help and accountability.

Everything that would disrupt this and not create value must go.

Only when you have achieved this on a small scale, only when it runs productively and stably and continues to create measurable value, only then are you ready to scale it. Not before.

If you cannot do it on a small scale, you cannot do it on a large scale either. Common sense.

You can perhaps already picture it a little. And you may feel it: it takes a great deal of courage to see this through.

In some organizations this would turn everything upside down.

But I see it as an opportunity.

Through AI you have the chance to think anew. Not just new business models, also new ways of working, organizations, a new way of thinking. This can also be an opportunity for everyone. Nobody has to be left behind. It can turn out better for everyone, if you only want it.

Seize the opportunity.

Start diving deeper now, where the complexity must be understood in order to create value. And start simplifying radically now, where not only no value is being created, but value is being diminished.

It can be a liberating new beginning. Be bold and do it.

Ankita Chatrath is VP Finance Data & AI Office in a regulated industry. The article was published in Ankita’s Substack.

I can higly recommend her newsletter!

Here the link:

The Hidden Prerequisites of AI Adoption

🎧 You can also listen to it.

We answer these questions:

• From a technology transformation lens, what are the core elements of AI readiness for you?

• What does real AI readiness look like inside an organization today? What do leaders need to prioritize to become AI-ready?

• How should organizations think about control, flexibility, and readiness as they build with AI?

• What makes one organization able to move faster than another when the technology is available to both?

• How do teams build AI systems in a way that fits their own context, constraints, and standards?

• What does it take to move from experimentation to an approach an organization can actually sustain? Can you share your on ground experience?

P.S.: This time English only

hier ist die deutsche Version.

Dear reader,

first a few words upfront:

Scope

This article is about agentic AI stacks, mainly for business workflows.

It is not about all other types of AI and it is not about coding agents.

AI is a huge field, I focus here purely on AI agents that can be deployed for business workflows.

Terms

Organisation:

This can range from a solopreneur to a huge corporation, but also the public sector or educational institutions that want to use agentic AI

Vendor:

By this I mean all those who provide or sell AI models or AI stacks or AI frameworks

Now let’s get started:

The agentic AI stack is a strategic decision

I am a fan of getting the full potential out of AI. When I thought about building an agentic AI stack for my consulting business, it was clear to me that I want to own it, not rent it. It is like with a house, I want a business asset. That is how I came to open source. But I am not a dogmatist. And I am also not a large company.

My motivation for writing this article was to understand what types of agentic AI stack exist.

Not everything fits everyone

Before deciding on an agentic AI stack, you need to research which of the types are suitable for your own industry, your own organisation size, your own type of organisation, your own strategy, your own employees and partners etc.

A custom agentic AI stack is also not worth it for all business areas. There are areas that are so standard everywhere that you can buy ready-made solutions on the market and integrate them.

In some industries, however, there is no choice, due to regulation or highly sensitive data or trade secrets.

So you have to engage intensively yourself with which AI stack comes into question for you. Depending on the industry or company size, you choose a different AI stack. Costs and how quickly you want to see results are of course also part of the decision.

In very large corporations it can even be the case that different areas each have different agentic AI stacks because the requirements are different.

Freedom vs. discipline

While researching I realised that in some cases it also moves within the tension of freedom vs. discipline. The more freedom I want, the more disciplined I must be in development and in governance.

So it is a tradeoff.

The agentic AI stack determines the operating model

After reading this article it will become relatively clear to you that the AI stack significantly determines the operating model, the organisational form and the way of working. What that means in detail in each case, I will cover in later articles. Today it is about you getting an overview and you will see very quickly where the differences lie.

No vendor recommendations

I have deliberately left out the names of existing providers and solutions. You have to research that yourself. I do not work for any provider and have no preferences whatsoever.

I have also deliberately not written recommendations. It really depends on so many factors. That does not all fit into one article, you can only find that out together in several personal conversations.

Mistakes happen

Errors may have crept in and I am happy if you point them out to me. Please help me improve this article. Thank you very much!

The 6 architecture layers of an agentic AI stack

Each layer builds on the previous one. Without understanding the lower layers, decisions in upper layers are not well-founded.

Layer 1: Infrastructure

Definition and purpose:

The infrastructure layer is the physical or virtual foundation on which all other layers operate. It answers the question: “Where do the GPUs run that compute the models?”

Infrastructure provides computing power, storage, and network connectivity. It is the foundation.

What exists:

• Cloud

  • Hyperscalers (US)

    • Full-stack cloud with GPU instances, globally available

  • Hyperscalers (EU)

    • EU regions available

  • Sovereign Cloud

    • Data in EU, GDPR-compliant

  • GPU Specialists

    • GPU-optimised infrastructure, often cheaper

  • Serverless GPU

    • Pay-per-use, no infrastructure management

• Local Hardware

  • Own servers in data centre

  • Own local hardware without servers

Important:

Infrastructure determines data location (on-prem vs. cloud), scalability (cloud burst), and compliance (GDPR, BaFin, sovereignty). A wrong infrastructure decision is expensive to correct later.

Layer 2: Model Serving: how models are hosted

Definition and purpose:

Model serving is the software layer that loads, manages, and serves inference requests for AI models. It is “the brain” of the AI: without model serving there is no intelligence.

Model serving provides models as a service: with APIs that can be called by agents. It manages model versions, batch sizes, and performance optimisation.

What exists:

• Proprietary

  • API

    • Frontier Models

      • Best performance, no own infrastructure

    • Enterprise APIs

      • Enterprise features, compliance certifications

  • Self-Hosted

    • Enterprise Serving

      • High performance, enterprise support

• Open-Source / Open-Weight

  • API (hosted)

    • Open-Weight Models

      • Models open, hosting with provider

    • Model Marketplaces

      • Many models, pay-per-use

  • Self-Hosted

    • Self-Hosted Inference

      • Full control, own infrastructure

Important:

Model serving determines what intelligence is available, how fast responses come, and where data is processed. Task-model matching means that not every task needs the largest and most expensive model. You assign the appropriate model to each task. That reduces costs and improves performance. The prerequisite for that is understanding which task requires which type of model.

Layer 3: Agent Runtime

Definition and purpose:

Agent runtime is the execution environment for AI agents. It can consist of the following things, although not all existing agent runtimes cover all features:

Process Management: Starting, stopping, persistently operating agents. Lifecycle from initialisation to termination.

State Management: Persistently keeping the state of a running agent across sessions. Where in the process, which intermediate results, which variables are set. Checkpointing on interruptions.

Durable Execution: Persistently storing every execution step. On abort, error or interruption, resuming exactly where the agent was.

Context Management: Controls what goes into the model’s context window. Conversation history, relevant context, summaries. Decides what to keep, compress or offload.

Sandboxing: Isolated execution environment per agent. Code execution, file access and commands without risk to production systems.

Tool Integration: Registering and providing external systems as callable functions. APIs, databases, file systems, browsers, MCP servers. Credential management and scoped permissions per agent.

Skill System: Storing reusable solution patterns from past tasks, making them searchable and applying them to new tasks. The agent learns from its own work.

Multi-Agent Coordination: Coordinating multiple agents. Delegation, parallelisation, communication between agents, shared task lists. Sub-agents for sequential subtasks, agent teams for parallel workstreams.

Self-Evaluation: Agent defines success criteria, evaluates own results, iterates until criteria are met.

Message Routing: Communication with users and external systems through various channels. Receiving inputs, delivering results.

Scheduling: Time-based, event-based or triggered by other agents execution. Autonomous operation without user interaction.

Model Routing: Controls which model is used for which agent or which task.

Observability: Tracing, debugging, audit trail across all agent actions.

What exists:

• Proprietary

  • Managed Platforms

    • Fully managed, enterprise features

  • Cloud-Native

    • Integration into cloud ecosystem

  • Enterprise RPA+AI

    • Existing RPA infrastructure

• Open-Source / Hybrid

  • Frameworks

    • Full control, self-hosted

  • Low-Code

    • Visual workflow creation

  • Personal Agents

    • Local installation, IDE integration

Important:

The agent runtime determines how workflows are built, orchestrated and connected with tools. It is the layer with the highest lock-in risk, because all the process logic resides here. Switching the runtime typically means rebuilding workflows. Even between open-source frameworks, portability is limited.

Layer 4: Data & Knowledge

Definition and purpose:

The data & knowledge layer provides persistent storage for data and knowledge. It is “the memory” of the system. Without it, agents forget everything after every session.

This layer can contain:

Memory (multi-level): Short-term memory holds the context within a running task. Long-term memory stores knowledge about users, projects and past interactions across sessions. Procedural memory stores reusable solution patterns from past tasks.

Retrieval (RAG): Agents search for relevant knowledge before responding. The trend is moving away from simple vector lookup towards hybrid retrieval that combines semantic search with structured querying.

Knowledge Graphs: Model relationships between entities (people, processes, systems, documents). Enable multi-hop reasoning, meaning questions that require multiple connection steps. Standard RAG alone cannot do that.

Data Ingestion: Parsing documents, chunking, extracting metadata, embedding, indexing. Without an ingestion pipeline, the knowledge layer is empty. The quality of ingestion determines the quality of all responses.

Data freshness: Knowledge gets outdated. Ingestion pipelines must run continuously, not once. Outdated or contradictory knowledge in the system is worse than no knowledge.

What exists:

The following technologies belong to the actual memory of the agent system. Beyond that, AI agents can access any data source via tool integrations, from relational databases to data lakes (that would be layer 3 though). In layer 4 there are:

• Vector databases (embeddings for semantic search and RAG)

• Knowledge graphs (relationships between entities, multi-hop reasoning)

• Document stores (unstructured documents, full-text search)

• In-memory stores (session state, short-term memory, caches)

• Personal knowledge (wikis, note systems, markdown collections)

Important:

Data & knowledge determines what AI agents know. The quality of this layer limits the quality of all agent responses, regardless of how good the model or the runtime is. Bad data in a good runtime with a good model produces bad results. Without this layer, AI agents start from zero with every request and would have no memory, no context and no learning from the past.

The difference between this layer and database queries via tool calls from layer 3 deserves its own article.

Layer 5: Governance & Control

Definition and purpose:

The governance & control layer enforces rules, policies and compliance requirements. It ensures that AI agents operate within defined boundaries.

It contains:

Policy Enforcement: Machine-readable rules that AI agents must follow (e.g. no PII data without masking, no actions above certain thresholds without approval)

Access Control: Who may use which AI agents, which data may AI agents see, which actions may they perform (RBAC, ABAC)

Data Classification: Which data may enter agent contexts, which may not. Sensitivity labels, data classification

Input/Output Guardrails: Prompt injection protection on the input side, hallucination detection and content filters on the output side

Audit Logging: Complete logging of all agent actions (who, when, what, with what result)

Compliance Reporting: Reports for authorities and internal stakeholders (BaFin, GDPR, EU AI Act, industry-specific regulation)

What exists:

• Policy engines (declarative, machine-readable rules as code)

• Identity & access management (SSO, RBAC, OAuth2, OIDC, user lifecycle)

• Logging & monitoring (logs, metrics, alerting, dashboards)

• AI observability (agent-specific tracing, token tracking, latency, cost per agent call)

• Compliance platforms (GDPR, SOC2, ISO certification, EU AI Act, industry-specific regulation)

• Cloud-native governance (policy enforcement integrated into cloud infrastructure)

• AI safety & guardrails (prompt injection protection, output validation, hallucination detection, content filters)

• Data classification & DLP (sensitivity labels, data loss prevention, masking of sensitive data)

• Model governance (model versioning, model registry, approval workflows for model changes)

• Audit trail & forensics (immutable logging of all agent actions, traceability for authorities)

• Cost governance (token budgets per agent, per team, per use case, alerting on thresholds)

Important:

Governance is the difference between demo and production. Without governance, no compliance, no audit, no trust. The question is whether you build it yourself or get it from the vendor, and what that means for your own organisation in each case.

Layer 6: Interface

Definition and purpose

The interface layer is the access point for users and external systems. It is the “face” of the system, the interface through which people and other systems interact with agents.

An interface enables:

• User interaction: Chat, portal, mobile app

• System integration: APIs for other applications

• Multi-channel: Slack, Teams, WhatsApp, web, mobile

• Personalisation: User-specific experiences

What exists:

• Messaging platforms (enterprise/community chat integration)

• Business messaging (mobile-first, high reach)

• Web frameworks (custom web apps)

• Low-code portals (rapid portal development)

• API gateways (API management, rate limiting)

• Chatbot platforms (visual bot creation)

• Voice interfaces (voice control)

• IDE integration (developer focus)

Important:

Interface determines user acceptance. The best AI agent system is useless if users cannot or do not want to use it.

Intermediate result

The different layers are an abstract way of looking at it that helps to break down “the big unknown topic” into units that everyone can understand.

Even if you are not a techie, you can roughly imagine something for each layer.

This abstraction helps enormously in understanding the different types of agentic AI stacks.

Here now are the ones I have identified. There may be additional types. I have limited myself to the most common ones.

Different types of agentic AI stacks

Not every organisation has to build all 6 layers itself. Platforms cover different layers. Each type is shown with a complete 6-layer diagram.

What exists:

• Type 1: Managed Control Plane

• Type 2: Ecosystem-Integrated

• Type 3: Open-Source Frameworks

• Type 4: Enterprise Application Suites

• Type 5: Infrastructure-Only

• Type 6: Managed Execution and self-hosted control

There are also hybrid forms, but the article is already very long, so I will only consider these.

For each type we look at the architecture layers.

There is the following colour legend:

✅ green = Organisation has full control

⚠️ yellow = limited room for manoeuvre or shared control

❌ red = Vendor controls (organisation cannot do anything)

Type 1: Managed Control Plane Platforms

Fully managed platforms that provide layer 1, 3, 4, 5, 6. Organisation only decides layer 2 (model selection) and defines own workflows.

Layer 6: Interface

❌ Platform controlled

Web UI and chat integrations predefined, own UI only via platform APIs, no direct access to agent communication

Layer 5: Governance & Control

❌ Platform controlled

Governance built in, own rules only configurable as far as platform provides (details see below)

Layer 4: Data & Knowledge

⚠️ Platform (exportable)

Vector DB and embedding pipeline managed, own data connectable via connectors, export possible but format and completeness platform-dependent

Layer 3: Agent Runtime

❌ Platform controlled

Workflows, orchestration and tool calls run in the platform engine, own logic only within the platform API, no access to runtime internals

Layer 2: Model Serving

⚠️ Limited selection

Few frontier and selected open-weight models available, own fine-tunes only if platform supports it

Layer 1: Infrastructure

❌ Platform controlled

Computing power, storage and network with provider, EU/US region selectable, no influence on hardware, scaling or failover

Governance: who does what from layer 5 in detail

Vendor handles:

• Providing RBAC/SSO integration

• Operating audit logging infrastructure

• Basic policies (rate limits, quotas)

• Compliance certification of platform (SOC2, ISO27001)

• Monitoring dashboard for platform usage

• Prompt injection protection

• Basic output validation

Organisation must do itself:

• Define own business policies (who may use which agents)

• Configure user roles and permissions

• Create compliance reports for authorities (BaFin, GDPR)

• Design human-in-the-loop workflows (escalation rules)

• Define data classification policies (which data in agents)

Workflow adaptability & use case freedom

• Workflow design: Workflows must follow platform paradigm

• Use case selection: Any use cases possible, as long as platform models support them

• Integrations: Platform connectors available, but custom integrations require platform-specific code

• Business logic: Complex custom logic only if platform supports it

• Scaling: Platform scales automatically, but cost control is your own responsibility

• Business transformation: Quickly test new use cases, but lock-in risk if successful

Type 2: Ecosystem-Integrated Platforms

AI as a feature in the existing ecosystem. Deeply integrated, but only usable within the ecosystem.

This type describes platforms that provide AI rather for all employees and type 4 would be more for specific business areas. However, there are partly providers that are both, type 2 as well as type 4.

Layer 6: Interface

❌ Ecosystem controlled.

AI is embedded directly in the existing apps, no separate UI, no own app needed. Users work in their familiar environment. Interaction via chat, sidebars or embedded suggestions. No access to underlying agent communication.

Layer 5: Governance & Control

❌ Ecosystem controlled. Governance built in, details see below.

Layer 4: Data & Knowledge

❌ Ecosystem controlled.

AI accesses the enterprise-wide index of the ecosystem (documents, mails, calendar, chats). No own vector DB needed but also no own one possible. Data is not exportable to another system. Quality of AI responses depends on how well the data in the ecosystem is maintained.

Layer 3: Agent Runtime

❌ Ecosystem controlled.

Workflows only creatable with ecosystem-native builder tools, own programming languages and paradigms per ecosystem, no portable logic. What is built here runs only in this ecosystem and nowhere else.

Layer 2: Model Serving

⚠️ Limited selection.

Ecosystem determines which models run, typically its own or an exclusive partner. Fine-tuning only within the given framework. No access to alternative models or own inference infrastructure.

Layer 1: Infrastructure

❌ Ecosystem controlled.

Runs on the cloud of the ecosystem provider. No choice of infrastructure, data centre region determined by provider. No influence on performance optimisation or cost structure of computing power.

Governance: who does what from layer 5 in detail

Vendor handles:

• Complete DLP (Data Loss Prevention)

• Compliance centre with prefabricated templates

• Audit logs in ecosystem format (for eDiscovery)

• Data classification automatically

• Integration into ecosystem apps

• Prompt injection protection

• Basic output validation

Organisation must do itself:

• Configure ecosystem-specific policies

• User management in ecosystem (who has which licence)

• Reporting only possible within ecosystem framework (no external tools)

• Assign sensitivity labels for documents

• External agents not covered (only ecosystem-internal)

Workflow adaptability & use case freedom

• Workflow design: Workflows must follow ecosystem paradigm (e.g. Copilot Studio: Power-Fx, Google: AppScript)

• Use case selection: Only use cases within the ecosystem (Teams, Outlook, Gmail, Docs)

• Integrations: Only ecosystem apps + limited external connectors (if released by vendor)

• Business logic: Complex logic only if ecosystem supports it (e.g. Power Apps formulas)

• Scaling: Ecosystem scales automatically, but licence costs increase linearly

• Business transformation: Only optimisation of existing ecosystem processes, no new business models

Type 3: Self-built

Self-built agentic AI stack, possibly with open-source frameworks that are self-hosted and operated. Full control over all layers, high own effort.

Layer 6: Interface

✅ Company controlled.

Own web app, own mobile app, own chat gateways. Full design freedom over user experience, channels and access paths. Any messaging platform integrable, any API designable by yourself.

Layer 5: Governance & Control

✅ Company controlled.

Governance must be built up completely by yourself, details see below.

Layer 4: Data & Knowledge

✅ Company controlled.

Free choice of database technology, own vector DBs, own knowledge graphs, own embedding pipelines. Data format, storage location and access completely in your own hands. Data exportable, migratable, combinable with other systems at any time.

Layer 3: Agent Runtime

✅ Company controlled.

Free choice of orchestration framework, any workflow paradigm implementable (state machines, event-driven, multi-agent, custom). Own code, own rules, own tool integrations. What is built here belongs to the company and is not tied to any provider.

Layer 2: Model Serving

✅ Company controlled.

Free model choice, any open-weight model deployable, own fine-tunes without restriction. Inference operable locally or in own cloud. Models exchangeable at any time without dependency on an API provider.

Layer 1: Infrastructure

✅ Company controlled.

On-prem, sovereign cloud, hybrid or any combination thereof. Full control over hardware, data centre location, scaling and costs. Decision on data location lies completely with the company.

Governance: who does what from layer 5 in detail

Since there is no vendor with type 3, there is at most what open source frameworks offer. Therefore:

• No managed services

• No monitoring

• No audit logs

• No compliance tools

• No human-in-the-loop

• No guardrails

Organisation must do itself:

• Write OPA/Kyverno policies (e.g. agent must not read PII data without masking)

• Operate Keycloak/Auth0 (SSO, RBAC, user lifecycle)

• Output validation: hallucination detection, content filters, JSON schema checks

• Set up ELK/Grafana stack (logs, metrics, alerting)

• Implement audit logging (who did what when)

• Generate compliance reports yourself (BaFin-MaRisk, GDPR, GxP)

• Code escalation workflows yourself (critical decisions to humans)

• Integrate prompt injection protection yourself (Lakera Guard or own rules)

Workflow adaptability & use case freedom

• Workflow design: Any workflow paradigm (state machines, event-driven, multi-agent, custom)

• Use case selection: Any use case possible, no platform restrictions

• Integrations: Any integration self-built, no vendor connector limits

• Business logic: Complex logic without platform limits, own code, own rules

• Scaling: Must scale yourself (Kubernetes, load balancing), but no vendor cost cap

• Business transformation: Completely new business models possible, platform does not limit

Type 4: Enterprise Application Suites

Complete packages from enterprise providers. Combine infrastructure to interface in one suite.

Layer 6: Interface

⚠️ Shared control.

Suite provides portal and integration into existing enterprise apps. Own customisations possible but only within the scope of suite configuration. UI extensions via suite-native development tools, not freely designable.

Layer 5: Governance & Control

⚠️ Shared control.

Governance built in and certified, details see below.

Layer 4: Data & Knowledge

⚠️ Shared control.

Suite delivers own vector DB and connectors to enterprise data within the suite. Access to data outside the suite only via suite connectors. Data belongs to the company, but storage format and access paths are suite-specific. Migration to another system requires considerable effort.

Layer 3: Agent Runtime

⚠️ Shared control.

Orchestration runs in the suite’s own framework. Workflows configurable and adaptable to business processes of the suite, but only within the suite paradigm. Own logic limitedly implementable. Agents outside the suite not orchestratable.

Layer 2: Model Serving

⚠️ Limited selection.

Suite offers own foundation models and selected external models. More flexibility than ecosystem-integrated (type 2), but less than self-built (type 3). Fine-tuning possible within suite framework, own inference infrastructure not intended.

Layer 1: Infrastructure

❌ Vendor controlled.

Runs on the cloud of the suite provider. No influence on hardware or data centre architecture. Regional options available depending on provider, but infrastructure decisions lie with the vendor.

Governance: who does what from layer 5 in detail

Vendor handles:

• Suite-internal governance completely

• Integration into suite apps

• Compliance for suite use cases (certified)

• Audit logs for suite actions

• Data governance within suite

• Prompt injection protection

• Basic output validation

Organisation must do itself:

• Configure suite policies (who may use which suite features)

• User management in suite (roles, permissions)

• Governance only within the suite, external agents not covered

• Reporting only for suite use cases (no cross-platform reports)

• Build hybrid scenarios yourself (suite + external agents)

Workflow adaptability & use case freedom

• Workflow design: Workflows must follow suite paradigm

• Use case selection: Only use cases that suite supports

• Integrations: Deep suite integration, but external systems only via suite connectors

• Business logic: Complex logic only if suite supports it

• Scaling: Suite scales automatically, but licence costs increase significantly

• Business transformation: Only transformation within suite framework, no AI-native products outside

Type 5: Infrastructure-Only Providers

Only infrastructure and model serving (layer 1-2). Organisation builds layer 3-6 itself.

Layer 6: Interface

✅ Company controlled.

Completely self-built. Full design freedom over all channels

Layer 5: Governance & Control

✅ Company controlled.

Governance must be built up completely by yourself, details see below.

Layer 4: Data & Knowledge

✅ Company controlled.

Free choice of all database technologies, own vector DBs, knowledge graphs, embedding pipelines. Full data sovereignty.

Layer 3: Agent Runtime

✅ Company controlled.

Any framework or own code. Full flexibility in orchestration, tool integration and workflow design.

Layer 2: Model Serving

⚠️ Provider (model selection flexible).

GPU cloud and model hosting with provider. Large model selection available, fast switching between models possible. But inference performance, availability and pricing lie with the provider. No own operation needed, but dependency on latency and costs.

Layer 1: Infrastructure

❌ Provider controlled.

GPU instances, storage and network lie with provider. No own data centre needed

Governance: who does what from layer 5 in detail

Vendor handles:

• Only infrastructure security (physical security, network isolation)

• No governance features

• No audit logging

• No compliance tools

• No prompt protection

• No output validation

• No human-in-the-loop

Organisation must do itself:

• Build up complete governance stack

• Implement model-specific guardrails (e.g. no PII in model requests)

• Implement audit logging yourself (all model calls with user ID, timestamp, input/output hash)

• Generate compliance reports yourself (document all model interactions for BaFin/GDPR)

• Integrate prompt injection protection yourself (Lakera Guard, own pattern matching rules)

• Code output validation yourself (JSON schema checks, content filters, hallucination detection)

• Build escalation workflows yourself (escalate critical model responses to humans)

Workflow adaptability & use case freedom

• Workflow design: Any paradigm, own code, no platform requirements

• Use case selection: Any use case possible, model APIs are generic

• Integrations: Any integration yourself, no vendor connector limits

• Business logic: Complex logic without limits, own code between user and model

• Scaling: Provider scales infrastructure, but cost control is your own responsibility

• Business transformation: Completely new business models, model APIs are commodity

Type 6: Managed Execution & self-hosted control

The model provider supplies inference and tool-use-capable execution via an API. The organisation builds all agent logic on top itself: memory, skills, orchestration, scheduling, multi-agent coordination.

Infrastructure (layer 1) and model serving (layer 2) lie with the provider. Layer 3 is shared: execution with the provider, everything above with the company. Layer 4, 5 and 6 are built by the organisation itself.

Layer 6: Interface

✅ Company controlled.

Completely self-built. Own web app, chat gateways, APIs. Full design freedom.

Layer 5: Governance & Control

✅ Company controlled.

Governance must be built up by yourself, details see below.

Layer 4: Data & Knowledge

✅ Company controlled.

Own vector DBs, knowledge graphs, embedding pipelines. Data format, storage location and access in your own hands.

Layer 3: Agent Runtime

⚠️ Shared control.

Parts of the runtime self-built (orchestration, tool integrations, workflow logic, scheduling). But the execution engine lies with the vendor. Sandboxing, durable execution and compute run with the vendor. The own logic sits on top, the execution underneath belongs to the vendor. If the provider disappears, the execution layer must be replaced, the self-built orchestration remains.

Layer 2: Model Serving

❌ Vendor controlled.

Inference runs via proprietary APIs. No own model serving, no own fine-tunes on own infrastructure. Model choice limited to the vendor’s offering. Switching providers possible, but requires adaptation of prompts and tool definitions.

Layer 1: Infrastructure

❌ Vendor controlled.

Computing power for inference lies with the provider. Own infrastructure only for the self-built parts (layer 4, 5, 6). No influence on availability, latency or pricing of model APIs.

Governance: who does what from layer 5 in detail

Vendor handles:

• Model-native safety guardrails (content filters, built into the model)

• API-level rate limiting and usage tracking

• Token consumption data via API dashboard

Organisation must do itself:

• Write OPA/Kyverno policies (e.g. agent must not read PII data without masking)

• Operate Keycloak/Auth0 (SSO, RBAC, user lifecycle)

• Output validation: hallucination detection, content filters, JSON schema checks

• Set up ELK/Grafana stack (logs, metrics, alerting)

• Implement audit logging (who did what when)

• Generate compliance reports yourself (BaFin-MaRisk, GDPR, GxP)

• Code escalation workflows yourself (critical decisions to humans)

• Integrate prompt injection protection yourself (Lakera Guard or own rules)

Workflow adaptability & use case freedom

• Workflow design: Any paradigm for the self-built orchestration, but execution patterns predefined by the vendor

• Use case selection: Any use case possible, as long as it can be mapped via the provider’s API

• Integrations: Any integration self-built, no vendor connector limits

• Business logic: Complex logic without platform limits in your own code, but execution capabilities dependent on the API provider

• Scaling: Own layers scale yourself, inference scales the provider, token costs are your own responsibility

• Business transformation: New business models possible, but with dependency on the execution layer. Differentiation lies in the self-built orchestration and in domain knowledge, not in the execution.

At a glance

Here is another overview in a matrix:

Conclusion

During the work on this article it became clear to me that AI in the best case extends the business strategy, because I can build new business models. But at the same time the business strategy limits the AI strategy.

Depending on what my business strategy looks like, I decide against certain types of agentic AI stack.

The decision depends on many factors.

Keep in mind when making your decision: the more freedom you have, the more responsibility lies with you.

There is no “one” operating model

While reading you have certainly also realised that depending on the stack you need very different roles to build or implement it and to ultimately operate it. The development is different. The governance part is different. And if you want to build new business models, you may need roles that you perhaps do not even have on your radar yet.

That means, each type of agentic AI stack has different consequences for the organisation. The following result from it:

• different operating models

• different team compositions

• different ways of working

• different organisation designs

• And you very likely need different AI consultants for each type.

How did you like the article?

I hope you liked the article!

If so, please like, share or recommend!

Comment if I made mistakes or if you have questions. Thank you very much!

Here is another section for all those who are looking for consulting:

What I do

My focus is on type 3, because this comes with the biggest challenges for the organisation.

For type 3 you need AI consultants with:

• strong engineering background

• lots of practical AI experience

• and above all years of experience with transformations

Large organisations may even assemble a team of internal and external AI experts and consultants.

No AI consultant covers all types of agentic AI stacks in detail. I am the consultant who can help you understand whether type 3 is an option for you or not.

And I am the consultant who brings type 3 to the road with you:

• for one because I am currently building stack 3 myself

• for another because this represents the biggest transformation for your organisation and I have a lot of experience in transformations

How does the consulting work?

The determined ones can contact me directly! Either via Substack or via LinkedIn or via my website.

For those who are still unsure

Soon I will offer a limited contingent of free stack assessments that clarify whether type 3 is suitable for you or not.

Subscribe to this Substack if you want to receive updates about when these start.

Subscribe now

the Englisch version follows right away!

Lieber Leser,

zunächst ein paar Worte vorab:

Abgrenzung

In diesem Artikel geht es um agentische KI-Stacks, hauptsächlich für Business Workflows.

Es geht nicht um alle andere Arten von KI und es geht auch nicht um Coding Agents.

KI ist ein riesiges Feld, ich fokussiere mich hier rein auf KI-Agenten, die für Business Workflows eingesetzt werden können.

Begriffe

Organisation:

Das kann vom Solopreneur bis zum riesigen Konzern sein, aber auch der öffentliche Bereich oder Bildungseinrichtungen, die agentische KI verwenden wollen

Vendor:

Damit meine ich alle diejenigen, die KI-Modelle oder KI-Stacks oder KI-Frameworks bereitstellen oder verkaufen

Nun geht es los:

Der agentische KI-Stack ist eine strategische Entscheidung

Ich bin ein Fan davon, das volle Potenzial aus KI herauszuholen. Als ich darüber nachdachte, einen agentischen KI-Stack für mein Beratungsgeschäft aufzubauen, war mir klar, dass ich ihn besitzen will, nicht mieten. Es ist wie mit einem Haus, ich will ein Business Asset. So kam ich zu Open Source. Aber ich bin kein Dogmatiker. Und ich bin auch kein großes Unternehmen.

Meine Motivation dafür diesen Artikel zu schreiben, war, zu verstehen welche Arten von agentischem KI-Stack es gibt.

Nicht alles passt für jeden

Bevor man sich für einen agentischen KI-Stack entscheidet, muss man recherchieren welche der Typen für die eigene Branche, die eigene Organisationsgröße, die eigene Art der Organisation, die eigene Strategie, die eigenen Mitarbeiter und Partner etc. geeignet sind.

Ein eigener agentischer KI-Stack lohnt sich auch nicht für alle Geschäftsbereiche. Es gibt Bereiche, die sind so 0815 überall, da kann man schon fertige Lösungen am Markt kaufen und diese integrieren.

In manchen Branchen gibt es allerdings keine Wahl, aufgrund von Regulierung oder hochsensiblen Daten oder Geschäftsgeheimnissen.

Man muss sich also selbst intensiv damit beschäftigen, welcher KI-Stack für einen in Frage kommt. Je nach Branche oder Unternehmensgröße entscheidet man sich für einen anderen KI-Stack. In die Entscheidungen fallen natürlich auch Kosten und wie schnell man Ergebnisse sehen will.

In sehr großen Konzernen kann es sogar sein, dass verschiedene Bereiche jeweils andere agentische KI-Stacks haben, weil die Anforderungen unterschiedlich sind.

Freiheit vs. Disziplin

Beim Recherchieren ist mir bewusst geworden, dass es sich in manchen Fällen auch im Spannungsfeld Freiheit vs. Disziplin bewegt. Je mehr Freiheit ich will, desto disziplinierte muss ich bei der Entwicklung und bei der Governance sein.

Es ist also ein Tradeoff.

Der agentische KI-Stack bestimmt das Operating Model

Nach dem Lesen des Artikels wird Dir relativ schnell klar, dass der KI-Stack maßgeblich über das Operating Model, die Organisationsform und die Arbeitsweise entscheidet. Was das jeweils im Detail bedeutet, darauf gehe ich in späteren Artikeln noch ein. Heute geht es darum, dass Du Dir einen Überblick verschaffst und Du wirst sehr schnell sehen, wo die Unterschiede liegen.

Keine Vendor Empfehlungen

Ich habe ganz bewusst die Namen der vorhandenen Anbieter und Lösungen weggelassen. Du musst das selbst recherchieren. Ich arbeite für keinen Anbieter und habe da keinerlei Vorlieben.

Ich habe auch absichtlich keine Empfehlungen geschrieben. Es hängt wirklich von so vielen Faktoren ab. Das passt nicht alles in einen Artikel, das kann man nur in mehreren persönlichen Gesprächen gemeinsam herausfinden.

Fehler passieren

Es könnte sich Fehler eingeschlichen haben und ich freue mich darüber, wenn Du mich darauf hinweist. Bitte hilf mir, diesen Artikel zu verbessern. Vielen Dank!

Die 6 Architektur-Schichten eines agentischen KI-Stacks

Jede Schicht baut auf der vorherigen auf. Ohne Verständnis der unteren Schichten sind Entscheidungen in oberen Schichten nicht fundiert.

Schicht 1: Infrastruktur

Definition und Zweck:

Die Infrastruktur-Schicht ist die physische oder virtuelle Grundlage auf der alle anderen Schichten operieren. Sie beantwortet die Frage: “Wo laufen die GPUs die die Modelle berechnen?”

Infrastruktur stellt Rechenleistung, Speicher, und Netzwerk-Konnektivität bereit. Sie ist das Fundament.

Was gibt es:

• Cloud

  • Hyperscaler (US)

    • Full-Stack Cloud mit GPU-Instanzen, global verfügbar

  • Hyperscaler (EU)

    • EU-Regionen verfügbar

  • Sovereign Cloud

    • Daten in EU, DSGVO-konform

  • GPU-Spezialisten

    • GPU-optimierte Infrastructure, oft günstiger

  • Serverless GPU

    • Pay-per-use, keine Infrastruktur-Verwaltung

• Lokale Hardware

  • Eigene Server im Rechenzentrum

  • Eigene lokale Hardware ohne Server

Wichtig:

Infrastructure bestimmt Datenlokation (On-Prem vs. Cloud), Skalierbarkeit (Cloud burst), und Compliance (DSGVO, BaFin, Souveränität). Eine falsche Infrastruktur-Entscheidung ist später teuer zu korrigieren.

Schicht 2: Model Serving - wie Modelle gehostet werden

Definition und Zweck:

Model Serving ist die Software-Schicht die KI-Modelle lädt, verwaltet, und Inference-Anfragen bedient. Sie ist “das Gehirn” der KI - ohne Model Serving gibt es keine Intelligenz.

Model Serving stellt Modelle als Service bereit - mit APIs, die von Agents aufgerufen werden können. Es verwaltet Modell-Versionen, Batch-Größen, und Performance-Optimierung.

Was gibt es:

• Proprietär

  • API

    • Frontier Models

      • Beste Performance, keine eigene Infrastruktur

    • Enterprise APIs

      • Enterprise-Features, Compliance-Zertifizierungen

  • Self-Hosted

    • Enterprise Serving

      • High-Performance, Enterprise-Support

• Open-Source / Open-Weight

  • API (gehostet)

    • Open-Weight Models

      • Modelle offen, Hosting beim Anbieter

    • Model Marketplaces

      • Viele Modelle, pay-per-use

  • Self-Hosted

    • Self-Hosted Inference

      • Volle Kontrolle, eigene Infrastruktur

Wichtig:

Model Serving bestimmt welche Intelligenz verfügbar ist, wie schnell Antworten kommen, und wo Daten verarbeitet werden. Task-Model-Matching bedeutet, dass nicht jede Aufgabe das größte und teuerste Modell braucht. Man ordnet jeder Aufgabe das passende Modell zu. Das reduziert Kosten und verbessert Performance. Die Voraussetzung dafür ist, dass man versteht welcher Task welche Art von Modell benötigt.

Schicht 3: Agent Runtime

Definition und Zweck:

Agent Runtime ist die Ausführungsumgebung für KI-Agenten. Sie kann aus folgenden Dingen bestehen, wobei nicht alle vorhandene Agent Runtimes alle Features abdecken:

Process Management: Agents starten, stoppen, persistent betreiben. Lifecycle von Initialisierung bis Beendigung.

State Management: Zustand eines laufenden Agents über Sessions hinweg persistent halten. Wo im Prozess, welche Zwischenergebnisse, welche Variablen gesetzt. Checkpointing bei Unterbrechungen.

Durable Execution: Jeden Ausführungsschritt persistent speichern. Bei Abbruch, Fehler oder Unterbrechung exakt dort fortsetzen wo der Agent war.

Context Management: Steuert was in das Context Window des Modells geht. Conversation History, relevanter Kontext, Zusammenfassungen. Entscheidet was behalten, verdichtet oder ausgelagert wird.

Sandboxing: Isolierte Ausführungsumgebung pro Agent. Code-Ausführung, Dateizugriff und Commands ohne Risiko für Produktivsysteme.

Tool Integration: Externe Systeme als aufrufbare Funktionen registrieren und bereitstellen. APIs, Datenbanken, Dateisysteme, Browser, MCP-Server. Credential Management und Scoped Permissions pro Agent.

Skill System: Wiederverwendbare Lösungsmuster aus vergangenen Aufgaben speichern, durchsuchbar machen und bei neuen Aufgaben anwenden. Der Agent lernt aus seiner eigenen Arbeit.

Multi-Agent Coordination: Mehrere Agents koordinieren. Delegation, Parallelisierung, Kommunikation zwischen Agents, geteilte Task-Listen. Subagents für sequentielle Teilaufgaben, Agent Teams für parallele Workstreams.

Self-Evaluation: Agent definiert Erfolgskriterien, evaluiert eigene Ergebnisse, iteriert bis Kriterien erfüllt.

Message Routing: Kommunikation mit Usern und externen Systemen über verschiedene Kanäle. Eingaben empfangen, Ergebnisse zustellen.

Scheduling: Zeitgesteuerte, eventbasierte oder durch andere Agents getriggerte Ausführung. Autonomer Betrieb ohne User-Interaktion.

Model Routing: Steuert welches Modell für welchen Agent oder welche Aufgabe eingesetzt wird.

Observability: Tracing, Debugging, Audit-Trail über alle Agent-Aktionen.

Was gibt es:

• Proprietär

  • Managed Platforms

    • Vollständig gemanagt, Enterprise-Features

  • Cloud-Native

    • Integration in Cloud-Ökosystem

  • Enterprise RPA+AI

    • Bestehende RPA-Infrastruktur

• Open-Source / Hybrid

  • Frameworks

    • Volle Kontrolle, selbst gehostet

  • Low-Code

    • Visuelle Workflow-Erstellung

  • Personal Agents

    • Lokale Installation, IDE-Integration

Wichtig:

Die Agent Runtime bestimmt wie Workflows aufgebaut, orchestriert und mit Tools verbunden werden. Sie ist die Schicht mit dem höchsten Lock-in-Risiko, weil die gesamte Ablauflogik hier liegt. Ein Wechsel der Runtime bedeutet in der Regel, Workflows neu zu bauen. Auch zwischen Open-Source-Frameworks ist die Portabilität begrenzt.

Schicht 4: Data & Knowledge

Definition und Zweck:

Die Data & Knowledge Schicht stellt persistente Speicherung für Daten und Wissen bereit. Sie ist “das Gedächtnis” des Systems. Ohne sie vergessen Agents nach jeder Session alles.

In dieser Schicht kann vorhanden sein:

Memory (mehrstufig): Kurzzeit-Memory hält den Kontext innerhalb einer laufenden Aufgabe. Langzeit-Memory speichert Wissen über Nutzer, Projekte und vergangene Interaktionen über Sessions hinweg. Prozedurales Memory speichert wiederverwendbare Lösungsmuster aus vergangenen Aufgaben.

Retrieval (RAG): Agents suchen relevantes Wissen vor der Antwort. Der Trend geht weg von einfachem Vektor-Lookup hin zu hybridem Retrieval, das semantische Suche mit strukturierter Abfrage kombiniert.

Knowledge Graphs: Modellieren Beziehungen zwischen Entitäten (Personen, Prozesse, Systeme, Dokumente). Ermöglichen Multi-Hop-Reasoning, also Fragen die mehrere Verbindungsschritte erfordern. Standard-RAG allein schafft das nicht.

Data Ingestion: Dokumente parsen, chunken, Metadaten extrahieren, embedden, indexieren. Ohne Ingestion-Pipeline ist die Knowledge Layer leer. Die Qualität der Ingestion bestimmt die Qualität aller Antworten.

Datenaktualität: Wissen veraltet. Ingestion-Pipelines müssen kontinuierlich laufen, nicht einmalig. Veraltetes oder widersprüchliches Wissen im System ist schlimmer als kein Wissen.

Was gibt es:

Die folgenden Technologien gehören zum eigentlichen Gedächtnis des Agent-Systems. Darüberhinaus können KI-Agenten über Tool-Integrationen auf jede beliebige Datenquelle zugreifen, von relationalen Datenbanken bis zu Data Lakes (das wäre aber Schicht 3). In Schicht 4 gibt es:

• Vector-Datenbanken (Embeddings für semantische Suche und RAG)

• Knowledge Graphs (Beziehungen zwischen Entitäten, Multi-Hop-Reasoning)

• Document Stores (unstrukturierte Dokumente, Volltextsuche)

• In-Memory Stores (Session-State, Kurzzeit-Memory, Caches)

• Personal Knowledge (Wikis, Notizsysteme, Markdown-Sammlungen)

Wichtig:

Data & Knowledge bestimmt was KI-Agenten wissen. Die Qualität dieser Schicht begrenzt die Qualität aller Agent-Antworten, unabhängig davon wie gut das Modell oder die Runtime ist. Schlechte Daten in einer guten Runtime mit einem guten Modell erzeugen schlechte Ergebnisse. Ohne diese Schicht fangen KI-Agenten bei jeder Anfrage bei Null an und hätten kein Gedächtnis, keinen Kontext und kein Lernen aus der Vergangenheit.

Der Unterschied zwischen dieser Schicht und Datenbankabfragen über Toolaufrufe aus Schicht 3 verdient einen eigenen Artikel.

Schicht 5: Governance & Control

Definition und Zweck:

Die Governance & Control Schicht setzt Regeln, Policies und Compliance-Anforderungen durch. Sie stellt sicher, dass KI-Agenten innerhalb definierter Grenzen operieren.

Darin enthalten:

Policy Enforcement: Maschinenlesbare Regeln die KI-Agenten einhalten müssen (z.B. keine PII-Daten ohne Maskierung, keine Aktionen über bestimmten Schwellenwerten ohne Freigabe)

Access Control: Wer darf welche KI-Agenten nutzen, welche Daten dürfen KI-Agenten sehen, welche Aktionen dürfen sie ausführen (RBAC, ABAC)

Data Classification: Welche Daten dürfen in Agent-Kontexte gelangen, welche nicht. Sensitivity-Labels, Datenklassifizierung

Input/Output Guardrails: Prompt-Injection-Schutz auf der Eingangsseite, Hallucination-Detection und Content-Filter auf der Ausgangsseite

Audit-Logging: Vollständige Protokollierung aller Agent-Aktionen (wer, wann, was, mit welchem Ergebnis)

Compliance-Reporting: Reports für Behörden und interne Stakeholder (BaFin, DSGVO, EU AI Act, branchenspezifische Regulierung)

Was gibt es:

• Policy Engines (deklarative, maschinenlesbare Regeln als Code)

• Identity & Access Management (SSO, RBAC, OAuth2, OIDC, User-Lifecycle)

• Logging & Monitoring (Logs, Metriken, Alerting, Dashboards)

• AI Observability (Agent-spezifisches Tracing, Token-Tracking, Latenz, Kosten pro Agent-Call)

• Compliance-Plattformen (DSGVO, SOC2, ISO-Zertifizierung, EU AI Act, branchenspezifische Regulierung)

• Cloud-Native Governance (Policy-Enforcement integriert in Cloud-Infrastruktur)

• AI Safety & Guardrails (Prompt-Injection-Schutz, Output-Validation, Hallucination-Detection, Content-Filter)

• Data Classification & DLP (Sensitivity-Labels, Data Loss Prevention, Maskierung sensibler Daten)

• Model Governance (Modell-Versionierung, Modell-Registry, Approval-Workflows für Modellwechsel)

• Audit-Trail & Forensik (unveränderliche Protokollierung aller Agent-Aktionen, Nachvollziehbarkeit für Behörden)

• Cost Governance (Token-Budgets pro Agent, pro Team, pro Use Case, Alerting bei Schwellenwerten)

Wichtig:

Governance ist der Unterschied zwischen Demo und Produktion. Ohne Governance keine Compliance, kein Audit, kein Vertrauen. Die Frage ist ob man sie selbst baut oder vom Vendor bekommt, und was das jeweils für die eigene Organisation bedeutet.

Schicht 6: Interface

Definition und Zweck

Die Interface Layer ist der Zugangspunkt für User und externe Systeme. Sie ist das “Gesicht” des Systems, die Schnittstelle durch die Menschen und andere Systeme mit Agents interagieren.

Ein Interface ermöglicht:

• User-Interaktion: Chat, Portal, Mobile App

• System-Integration: APIs für andere Anwendungen

• Multi-Channel: Slack, Teams, WhatsApp, Web, Mobile

• Personalisierung: User-spezifische Erfahrungen

  Was gibt es:

• Messaging Platforms (Enterprise/Community Chat-Integration)

• Business Messaging (Mobile-first, hohe Reichweite)

• Web Frameworks (Custom Web-Apps)

• Low-Code Portals (schnelle Portal-Entwicklung)

• API Gateways (API-Management, Rate Limiting)

• Chatbot Platforms (visuelle Bot-Erstellung)

• Voice Interfaces (Sprachsteuerung)

• IDE Integration (Developer-Fokus)

Wichtig:

Interface bestimmt User-Akzeptanz. Das beste KI-Agenten-System nützt nichts wenn User es nicht nutzen können oder wollen.

Zwischenergebnis

Die verschiedenen Schichten sind eine abstrakte Betrachtungsweise, die dabei hilft “das große unbekannte Thema” in jedem verständliche Einheiten herunterzubrechen.

Selbst wenn Du kein Techie bist, kannst Dur Dir unter jeder Schicht einigermaßen etwas vorstellen.

Diese Abstraktion hilft enorm beim verstehen der verschiedenen Typen von agentischen KI-Stacks.

Hier nun diejenigen, die ich identifiziert habe. Es gibt vielleicht noch weitere Typen. Ich habe mich auf die gängigsten beschränkt.

Verschiedene Typen von agentischen KI-Stacks

Nicht jede Organisation muss alle 6 Schichten selbst bauen. Plattformen decken unterschiedliche Schichten ab. Jeder Typ wird mit komplettem 6-Layer-Diagramm dargestellt.

Was gibt es:

• Typ 1: Managed Control Plane

• Typ 2: Ecosystem-Integrated

• Typ 3: Open-Source Frameworks

• Typ 4: Enterprise Application Suites

• Typ 5: Infrastructure-Only

• Typ 6: Managed Execution und self-hostet control

Es gibt auch Mischformen, aber der Artikel ist so schon sehr lang, also betrachte ich mal nur diese.

Für jeden Typ sehen wir uns die Architekturschichten an.

Es gibt folgende Farblegende:

✅ grün = Organisation hat volle Kontrolle

⚠️ gelb = begrenzter Handlungsspielraum oder geteilte Kontrolle

❌ rot = Vendor kontrolliert (Organisation kann nichts tun)

Typ 1: Managed Control Plane Platforms

Vollständig gemanagte Plattformen die Layer 1, 3, 4, 5, 6 bereitstellen. Organisation entscheidet nur Layer 2 (Model-Auswahl) und definiert eigene Workflows.

Schicht 6: Interface

❌ Platform kontrolliert

Web-UI und Chat-Integrationen vorgegeben, eigene UI nur über Platform-APIs, kein direkter Zugriff auf Agent-Kommunikation

Schicht 5: Governance & Control

❌ Platform kontrolliert

Governance eingebaut, eigene Regeln nur konfigurierbar soweit Platform es vorsieht (Details siehe unten)

Schicht 4: Data & Knowledge

⚠️ Platform (exportierbar)

Vector-DB und Embedding-Pipeline gemanagt, eigene Daten über Connectors anbindbar, Export möglich aber Format und Vollständigkeit plattformabhängig

Schicht 3: Agent Runtime

❌ Platform kontrolliert

Workflows, Orchestrierung und Tool-Aufrufe laufen in der Platform-Engine, eigene Logik nur im Rahmen der Platform-API, kein Zugriff auf Runtime-Internals

Schicht 2: Model Serving

⚠️ Begrenzte Auswahl

Wenige Frontier- und ausgewählte Open-Weight-Modelle verfügbar, eigene Fine-Tunes nur wenn Platform es unterstützt

Schicht 1: Infrastructure

❌ Platform kontrolliert

Rechenleistung, Speicher und Netzwerk beim Anbieter, EU/US Region wählbar, kein Einfluss auf Hardware, Skalierung oder Ausfallsicherheit

Governance: wer macht was aus Schicht 5 im Detail

Vendor übernimmt:

• RBAC/SSO Integration bereitstellen

• Audit-Logging Infrastruktur betreiben

• Basis-Policies (Rate Limits, Quotas)

• Compliance-Zertifizierung der Platform (SOC2, ISO27001)

• Monitoring-Dashboard für Platform-Nutzung

• Prompt-Injection-Schutz

• Basis-Output-Validation

Organisation muss selbst machen:

• Eigene Business-Policies definieren (wer darf welche Agents nutzen)

• User-Rollen und Berechtigungen konfigurieren

• Compliance-Reports für Behörden erstellen (BaFin, DSGVO)

• Human-in-the-Loop Workflows designen (Eskalationsregeln)

• Data-Classification Policies definieren (welche Daten in Agents)

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Workflows müssen Platform-Paradigma folgen

• Use-Case-Auswahl: Beliebige Use Cases möglich, solange Platform-Modelle sie unterstützen

• Integrationen: Platform-Connectors vorhanden, aber Custom-Integrationen erfordern Platform-spezifischen Code

• Business-Logik: Komplexe eigene Logik nur wenn Platform es unterstützt

• Skalierung: Platform skaliert automatisch, aber Cost-Control selbst verantworten

• Business-Transformation: Schnell neue Use Cases testen, aber bei Erfolg Lock-in-Risiko

Typ 2: Ecosystem-Integrated Platforms

KI als Feature im bestehenden Ökosystem. Tief integriert, aber nur innerhalb des Ökosystems nutzbar.

Dieser Typ beschreibt Plattformen, die KI eher für alle Mitarbeiter bereitstellen und Typ 4 wäre eher für bestimmte Business Bereiche. Teilweise gibt es aber Anbieter, die beides sind, sowohl Typ 2 als auch Typ 4.

Schicht 6: Interface

❌ Ecosystem kontrolliert.

KI ist direkt in die bestehenden Apps eingebettet, kein separates UI, keine eigene App nötig. Nutzer arbeiten in ihrer gewohnten Umgebung. Interaktion über Chat, Seitenleisten oder eingebettete Vorschläge. Kein Zugriff auf darunterliegende Agent-Kommunikation.

Schicht 5: Governance & Control

❌ Ecosystem kontrolliert. Governance eingebaut, Details siehe unten.

Schicht 4: Data & Knowledge

❌ Ecosystem kontrolliert.

KI greift auf den unternehmensweiten Index des Ecosystems zu (Dokumente, Mails, Kalender, Chats). Keine eigene Vector-DB nötig aber auch keine eigene möglich. Daten sind nicht exportierbar in ein anderes System. Qualität der KI-Antworten hängt davon ab wie gut die Daten im Ecosystem gepflegt sind.

Schicht 3: Agent Runtime

❌ Ecosystem kontrolliert.

Workflows nur mit Ecosystem-eigenen Builder-Tools erstellbar, eigene Programmiersprachen und Paradigmen pro Ecosystem, keine portable Logik. Was hier gebaut wird läuft nur in diesem Ecosystem und nirgendwo sonst.

Schicht 2: Model Serving

⚠️ Begrenzte Auswahl.

Ecosystem bestimmt welche Modelle laufen, typischerweise die hauseigenen oder ein exklusiver Partner. Fine-Tuning nur im vorgegebenen Rahmen. Kein Zugriff auf alternative Modelle oder eigene Inference-Infrastruktur.

Schicht 1: Infrastructure

❌ Ecosystem kontrolliert.

Läuft auf der Cloud des Ecosystem-Anbieters. Keine Wahl der Infrastruktur, Rechenzentrumsregion vom Anbieter vorgegeben. Kein Einfluss auf Performance-Optimierung oder Kostenstruktur der Rechenleistung.

Governance: wer macht was aus Schicht 5 im Detail

Vendor übernimmt:

• Vollständige DLP (Data Loss Prevention)

• Compliance Center mit vorgefertigten Templates

• Audit-Logs im Ecosystem-Format (für eDiscovery)

• Data-Classification automatisch

• Integration in Ecosystem-Apps

• Prompt-Injection-Schutz

• Basis-Output-Validation

Organisation muss selbst machen:

• Ecosystem-spezifische Policies konfigurieren

• User-Management im Ecosystem (wer hat welche Lizenz)

• Reporting nur im Ecosystem-Rahmen möglich (keine externen Tools)

• Sensitivity-Labels für Dokumente vergeben

• Externe Agents nicht abgedeckt (nur Ecosystem-intern)

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Workflows müssen Ecosystem-Paradigma folgen (z.B. Copilot Studio: Power-Fx, Google: AppScript)

• Use-Case-Auswahl: Nur Use Cases innerhalb des Ecosystems (Teams, Outlook, Gmail, Docs)

• Integrationen: Nur Ecosystem-Apps + begrenzte externe Connectors (wenn vom Vendor freigegeben)

• Business-Logik: Komplexe Logik nur wenn Ecosystem sie unterstützt (z.B. Power Apps Formeln)

• Skalierung: Ecosystem skaliert automatisch, aber Lizenzkosten steigen linear

• Business-Transformation: Nur Optimierung bestehender Ecosystem-Prozesse, keine neuen Geschäftsmodelle

Typ 3: Selbstgebaut

Selbst gebauter agentischer KI-Stack, evtl. mit Open-Source-Frameworks die selbst gehostet und betrieben werden. Volle Kontrolle über alle Schichten, hoher eigener Aufwand.

Schicht 6: Interface

✅ Unternehmen kontrolliert.

Eigene Web-App, eigene Mobile-App, eigene Chat-Gateways. Volle Gestaltungsfreiheit über Nutzererfahrung, Kanäle und Zugangswege. Jede Messaging-Plattform integrierbar, jede API selbst designbar.

Schicht 5: Governance & Control

✅ Unternehmen kontrolliert.

Governance muss komplett selbst aufgebaut werden, Details siehe unten.

Schicht 4: Data & Knowledge

✅ Unternehmen kontrolliert.

Freie Wahl der Datenbank-Technologie, eigene Vector-DBs, eigene Knowledge Graphs, eigene Embedding-Pipelines. Datenformat, Speicherort und Zugriff vollständig in eigener Hand. Daten jederzeit exportierbar, migrierbar, kombinierbar mit anderen Systemen.

Schicht 3: Agent Runtime

✅ Unternehmen kontrolliert.

Freie Wahl des Orchestrierungs-Frameworks, beliebige Workflow-Paradigmen umsetzbar (State-Machines, Event-Driven, Multi-Agent, Custom). Eigener Code, eigene Regeln, eigene Tool-Integrationen. Was hier gebaut wird gehört dem Unternehmen und ist nicht an einen Anbieter gebunden.

Schicht 2: Model Serving

✅ Unternehmen kontrolliert.

Freie Modellwahl, jedes Open-Weight-Modell einsetzbar, eigene Fine-Tunes ohne Einschränkung. Inference lokal oder in eigener Cloud betreibbar. Modelle jederzeit austauschbar ohne Abhängigkeit von einem API-Anbieter.

Schicht 1: Infrastructure

✅ Unternehmen kontrolliert.

On-Prem, Sovereign Cloud, Hybrid oder jede Kombination davon. Volle Kontrolle über Hardware, Rechenzentrumsstandort, Skalierung und Kosten. Entscheidung über Datenlokation liegt komplett beim Unternehmen.

Governance: wer macht was aus Schicht 5 im Detail

Da es bei Typ 3 keinen Vendor gibt, gibt es maximal das, was Open Source Frameworks anbieten. Daher:

• Keine Managed Services

• Kein Monitoring

• Keine Audit-Logs

• Keine Compliance-Tools

• Kein Human-in-the-Loop

• Keine Guardrails

Organisation muss selbst machen:

• OPA/Kyverno Policies schreiben (z.B. Agent darf keine PII-Daten lesen ohne Maskierung)

• Keycloak/Auth0 betreiben (SSO, RBAC, User-Lifecycle)

• Output-Validation: Hallucination-Detection, Content-Filter, JSON-Schema-Checks

• ELK/Grafana-Stack aufsetzen (Logs, Metriken, Alerting)

• Audit-Logging implementieren (wer hat wann was getan)

• Compliance-Reports selbst generieren (BaFin-MaRisk, DSGVO, GxP)

• Escalation-Workflows selbst coden (kritische Entscheidungen an Menschen)

• Prompt-Injection-Schutz selbst integrieren (Lakera Guard oder eigene Rules)

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Beliebiges Workflow-Paradigma (State-Machines, Event-Driven, Multi-Agent, Custom)

• Use-Case-Auswahl: Jeder Use Case möglich, keine Platform-Beschränkungen

• Integrationen: Jede Integration selbst gebaut, keine Vendor-Connector-Grenzen

• Business-Logik: Komplexe Logik ohne Platform-Limits, eigener Code, eigene Rules

• Skalierung: Muss selbst skalieren (Kubernetes, Load-Balancing), aber keine Vendor-Cost-Cap

• Business-Transformation: Komplett neue Geschäftsmodelle möglich, Platform limitiert nicht

Typ 4: Enterprise Application Suites

Komplett-Pakete von Enterprise-Anbietern. Kombinieren Infrastructure bis Interface in einer Suite.

Schicht 6: Interface

⚠️ Geteilte Kontrolle.

Suite stellt Portal und Integration in bestehende Enterprise-Apps bereit. Eigene Anpassungen möglich aber nur im Rahmen der Suite-Konfiguration. UI-Erweiterungen über Suite-eigene Entwicklungstools, nicht frei gestaltbar.

Schicht 5: Governance & Control

⚠️ Geteilte Kontrolle.

Governance eingebaut und zertifiziert, Details siehe unten.

Schicht 4: Data & Knowledge

⚠️ Geteilte Kontrolle.

Suite liefert eigene Vector-DB und Connectors zu den Enterprise-Daten innerhalb der Suite. Zugriff auf Daten außerhalb der Suite nur über Suite-Connectors. Daten gehören dem Unternehmen, aber Speicherformat und Zugriffswege sind Suite-spezifisch. Migration auf ein anderes System erfordert erheblichen Aufwand.

Schicht 3: Agent Runtime

⚠️ Geteilte Kontrolle.

Orchestrierung läuft im Suite-eigenen Framework. Workflows konfigurierbar und an Business-Prozesse der Suite anpassbar, aber nur innerhalb des Suite-Paradigmas. Eigene Logik begrenzt umsetzbar. Agents außerhalb der Suite nicht orchestrierbar.

Schicht 2: Model Serving

⚠️ Begrenzte Auswahl.

Suite bietet eigene Foundation Models und ausgewählte externe Modelle an. Mehr Flexibilität als Ecosystem-Integrated (Typ 2), aber weniger als Selbstgebaut (Typ 3). Fine-Tuning im Suite-Rahmen möglich, eigene Inference-Infrastruktur nicht vorgesehen.

Schicht 1: Infrastructure

❌ Vendor kontrolliert.

Läuft auf der Cloud des Suite-Anbieters. Kein Einfluss auf Hardware oder Rechenzentrumsarchitektur. Regionale Optionen je nach Anbieter verfügbar, aber Infrastruktur-Entscheidungen liegen beim Vendor.

Governance: wer macht was aus Schicht 5 im Detail

Vendor übernimmt:

• Suite-interne Governance komplett

• Integration in Suite-Apps

• Compliance für Suite-Use-Cases (zertifiziert)

• Audit-Logs für Suite-Aktionen

• Data-Governance innerhalb Suite

• Prompt-Injection-Schutz

• Basis-Output-Validation

Organisation muss selbst machen:

• Suite-Policies konfigurieren (wer darf welche Suite-Features)

• User-Management in Suite (Rollen, Berechtigungen)

• Governance nur innerhalb der Suite, externe Agents nicht abgedeckt

• Reporting nur für Suite-Use-Cases (keine cross-Platform Reports)

• Hybrid-Szenarien selbst bauen (Suite + externe Agents)

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Workflows müssen Suite-Paradigma folgen

• Use-Case-Auswahl: Nur Use Cases die Suite unterstützt

• Integrationen: Tiefe Suite-Integration, aber externe Systeme nur über Suite-Connectors

• Business-Logik: Komplexe Logik nur wenn Suite sie unterstützt

• Skalierung: Suite skaliert automatisch, aber Lizenzkosten steigen stark

• Business-Transformation: Nur Transformation innerhalb Suite-Rahmen, keine AI-native Products außerhalb

Typ 5: Infrastructure-Only Providers

Nur Infrastructure und Model Serving (Layer 1-2). Organisation baut Layer 3-6 selbst.

Schicht 6: Interface

✅ Unternehmen kontrolliert.

Komplett selbst gebaut. Volle Gestaltungsfreiheit über alle Kanäle

Schicht 5: Governance & Control

✅ Unternehmen kontrolliert.

Governance muss komplett selbst aufgebaut werden, Details siehe unten.

Schicht 4: Data & Knowledge

✅ Unternehmen kontrolliert.

Freie Wahl aller Datenbank-Technologien, eigene Vector-DBs, Knowledge Graphs, Embedding-Pipelines. Volle Datenhoheit.

Schicht 3: Agent Runtime

✅ Unternehmen kontrolliert.

Beliebiges Framework oder eigener Code. Volle Flexibilität bei Orchestrierung, Tool-Integration und Workflow-Design.

Schicht 2: Model Serving

⚠️ Provider (Model-Auswahl flexibel).

GPU-Cloud und Model-Hosting beim Provider. Große Modellauswahl verfügbar, schneller Wechsel zwischen Modellen möglich. Aber Inference-Performance, Verfügbarkeit und Preisgestaltung liegen beim Provider. Kein eigener Betrieb nötig, dafür Abhängigkeit bei Latenz und Kosten.

Schicht 1: Infrastructure

❌ Provider kontrolliert.

GPU-Instanzen, Speicher und Netzwerk liegen beim Provider. Kein eigenes Rechenzentrum nötig

Governance: wer macht was aus Schicht 5 im Detail

Vendor übernimmt:

• Nur Infrastructure-Security (Physische Sicherheit, Netzwerk-Isolation)

• Keine Governance-Features

• Kein Audit-Logging

• Keine Compliance-Tools

• Kein Prompt-Schutz

• Keine Output-Validation

• Kein Human-in-the-Loop

Organisation muss selbst machen:

• Kompletten Governance-Stack aufbauen

• Model-spezifische Guardrails implementieren (z.B. Keine PII in Model-Requests)

• Audit-Logging selbst implementieren (alle Model-Calls mit User-ID, Timestamp, Input/Output-Hash)

• Compliance-Reports selbst generieren (alle Model-Interactions für BaFin/DSGVO dokumentieren)

• Prompt-Injection-Schutz selbst integrieren (Lakera Guard, eigene Pattern-Matching-Rules)

• Output-Validation selbst coden (JSON-Schema-Checks, Content-Filter, Hallucination-Detection)

• Escalation-Workflows selbst bauen (kritische Model-Antworten an Menschen eskalieren)

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Beliebiges Paradigma, eigener Code, keine Platform-Vorgaben

• Use-Case-Auswahl: Jeder Use Case möglich, Model-APIs sind generisch

• Integrationen: Jede Integration selbst, keine Vendor-Connector-Grenzen

• Business-Logik: Komplexe Logik ohne Limits, eigener Code zwischen User und Model

• Skalierung: Provider skaliert Infrastructure, aber Cost-Control selbst verantworten

• Business-Transformation: Komplett neue Geschäftsmodelle, Model-APIs sind Commodity

Typ 6: Managed Execution & self-hosted control

Der Modell-Anbieter stellt Inference und Tool-Use-fähige Execution über eine API bereit. Die Organisation baut darauf die gesamte Agent-Logik selbst: Memory, Skills, Orchestrierung, Scheduling, Multi-Agent-Koordination.

Infrastructure (Layer 1) und Model Serving (Layer 2) liegen beim Anbieter. Layer 3 ist geteilt: Execution beim Anbieter, alles darüber beim Unternehmen. Layer 4, 5 und 6 baut die Organisation selbst.

Schicht 6: Interface

✅ Unternehmen kontrolliert.

Komplett selbst gebaut. Eigene Web-App, Chat-Gateways, APIs. Volle Gestaltungsfreiheit.

Schicht 5: Governance & Control

✅ Unternehmen kontrolliert.

Governance muss selbst aufgebaut werden, Details siehe unten.

Schicht 4: Data & Knowledge

✅ Unternehmen kontrolliert.

Eigene Vector-DBs, Knowledge Graphs, Embedding-Pipelines. Datenformat, Speicherort und Zugriff in eigener Hand.

Schicht 3: Agent Runtime

⚠️ Geteilte Kontrolle.

Teile der Runtime selbst gebaut (Orchestrierung, Tool-Integrationen, Workflow-Logik, Scheduling). Aber die Execution Engine liegt beim Vendor. Sandboxing, Durable Execution und Compute laufen beim Vendor. Die eigene Logik sitzt obendrauf, die Ausführung darunter gehört dem Vendor. Bei Wegfall des Anbieters muss die Execution-Schicht ersetzt werden, die selbstgebaute Orchestrierung bleibt.

Schicht 2: Model Serving

❌ Vendor kontrolliert.

Inference läuft über proprietäre APIs. Kein eigenes Model Serving, keine eigenen Fine-Tunes auf eigener Infrastruktur. Modellwahl auf das Angebot des Vendors begrenzt. Wechsel des Anbieters möglich, aber erfordert Anpassung der Prompts und Tool-Definitionen.

Schicht 1: Infrastructure

❌ Vendor kontrolliert.

Rechenleistung für Inference liegt beim Anbieter. Eigene Infrastruktur nur für die selbstgebauten Teile (Layer 4, 5, 6). Kein Einfluss auf Verfügbarkeit, Latenz oder Preisgestaltung der Modell-APIs.

Governance: wer macht was aus Schicht 5 im Detail

Vendor übernimmt:

• Modell-eigene Safety-Guardrails (Content-Filter, im Modell eingebaut)

• API-Level Rate Limiting und Usage Tracking

• Token-Verbrauchsdaten über API-Dashboard

Organisation muss selbst machen:

• OPA/Kyverno Policies schreiben (z.B. Agent darf keine PII-Daten lesen ohne Maskierung)

• Keycloak/Auth0 betreiben (SSO, RBAC, User-Lifecycle)

• Output-Validation: Hallucination-Detection, Content-Filter, JSON-Schema-Checks

• ELK/Grafana-Stack aufsetzen (Logs, Metriken, Alerting)

• Audit-Logging implementieren (wer hat wann was getan)

• Compliance-Reports selbst generieren (BaFin-MaRisk, DSGVO, GxP)

• Escalation-Workflows selbst coden (kritische Entscheidungen an Menschen)

• Prompt-Injection-Schutz selbst integrieren (Lakera Guard oder eigene Rules)

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Beliebiges Paradigma für die selbstgebaute Orchestrierung, aber Execution-Patterns durch den Vendor vorgegeben

• Use-Case-Auswahl: Jeder Use Case möglich, solange er über die API des Anbieters abbildbar ist

• Integrationen: Jede Integration selbst gebaut, keine Vendor-Connector-Grenzen

• Business-Logik: Komplexe Logik ohne Platform-Limits im eigenen Code, aber Execution-Fähigkeiten abhängig vom API-Anbieter

• Skalierung: Eigene Schichten selbst skalieren, Inference skaliert der Anbieter, Token-Kosten selbst verantworten

• Business-Transformation: Neue Geschäftsmodelle möglich, aber mit Abhängigkeit bei der Execution-Schicht. Differenzierung liegt in der selbstgebauten Orchestrierung und im Domänenwissen, nicht in der Execution.

Auf einen Blick

Hier nochmal eine Übersicht in einer Matrix:

Fazit

Während der Arbeit an diesem Artikel ist mir klar geworden, dass KI im besten Falle die Business Strategie erweitert, weil ich neue Geschäftsmodelle aufbauen kann. Aber gleichzeitig begrenzt die Business Strategie die KI Strategie.

Je nach dem wie meine Business Strategie aussieht, entscheide ich mich gegen bestimmte Typen von agentischem KI-Stack.

Die Entscheidung hängt von vielen Faktoren ab.

Bedenke bei Deiner Entscheidung: Je mehr Freiheit Du hast, desto mehr Verantwortung liegt bei Dir.

Es gibt nicht “das eine” Operating Model

Bestimmt ist Dir beim Lesen auch klar geworden, dass Du je nach Stack ganz unterschiedliche Rollen benötigst, die Dir das aufbauen oder implementieren und die es letztendlich betreiben. Die Entwicklung ist unterschiedlich. Der Governance Teil ist unterschiedlich. Und wenn Du neue Geschäftsmodelle aufbauen willst, benötigst Du evtl. Rollen, die Du vielleicht noch gar nicht auf dem Schirm hast.

Das bedeutet, jeder Typ eines agentischen KI Stacks hat unterschiedliche Konsequenzen für die Organisation. Es ergeben sich daraus:

• unterschiedliche Operating Modelle

• unterschiedliche Teamzusammsetzungen

• unterschiedliche Arbeitsweisen

• unterschiedliche Organisationsdesigns

• Und man benötigt sehr wahrscheinlich für jeden Typ unterschiedliche KI-Berater.

Wie gefiel Dir der Artikel?

Ich hoffe der Artikel hat Dir gefallen!

Falls ja, bitte liken, teilen oder weiter empfehlen!

Kommentiere, wenn ich Fehler gemacht habe oder Du Fragen hast. Vielen Dank!

Hier kommt noch ein Abschnitt für alle diejenigen, die eine Beratung suchen:

Was mache ich

Mein Fokus liegt auf Typ 3, denn dieser kommt mit den größten Herausforderungen für die Organisation.

Für Typ 3 brauchst Du KI Berater mit:

• starkem Engineering Background

• viel praktischer KI Erfahrung

• und vor allem jahrelange Erfahrungen mit Transformationen

Große Organisationen stellen vielleicht sogar ein Team aus internen und externen KI Experten und Beratern zusammen.

Kein KI-Berater deckt alle Typen von agentischen KI-Stacks im Detail ab. Ich bin der Berater, der Dir helfen kann zu verstehen, ob Typ 3 für Dich in Frage kommt oder nicht.

Und ich bin der Berater, der Typ 3 mit Dir zusammen auf die Straße bringt:

• zum einen weil ich Stack 3 gerade selbst aufbaue

• zum anderen weil dieser die größte Transformation für Deine Organisation darstellt und ich sehr viel Erfahrung in Transformationen habe

Wie funktioniet die Beratung?

Die Entschlossenen können mich direkt kontaktieren! Entweder über Substack oder über LinkedIn oder über meine Website.

Für diejenigen, die sich noch unsicher sind

Bald biete ich ein begrenztes Kontingent kostenloser Stack Assessments an, die klären ob Typ 3 für dich geeignet ist oder nicht.

Abonniere diesen Substack falls du Updates darüber erhalten willst, wann diese starten:

Subscribe now

Dear reader,

this article is structured so that you can simply jump to the heading that interests you.

Always start with Why

Why would I even want an AI transformation?

Imagine the following scenario:

A potential customer asks something via Claude.ai or ChatGPT for which you would have the matching products or services.

In the chat response, your products and services are linked.

The potential customer clicks on it and on your website you manage to understand the potential customer through a few targeted interactive questions so well that you can make an individually tailored offer. Maybe the potential customer has even been on your website before and you recognize it and have all the information from back then ready.

The potential customer feels understood and you manage to fulfill the customer’s wish, across all media - website, email, app, phone, whatever - always in sync, seamless and smooth, offering a thoroughly successful customer experience.

The customer is super happy because everything runs so smoothly and when they really have a special concern, they immediately get to a real employee.

Sounds great, right?

What does reality look like?

Well, in the last 2 years alone I had 4 experiences with banks, insurance companies, health insurance providers and online retailers that were exactly the opposite: exhausting, many media breaks, suddenly the information was no longer consistent everywhere, concerns were not understood, you get sent from pillar to post, instructions too complicated or contradictory, concerns were not resolved, mistakes were made, lots of communication etc. etc. You all know this.

Those who work in such areas know: it takes more than just AI to set up such processes properly and I will go into that later. But AI can take the whole thing to another level.

There are many, many more use cases where AI really helps. But, how do we get there?

AI transformation - how does it usually begin?

AI transformation is a vague term. I mean, AI alone is such a huge spectrum. Not every use case requires the same AI transformation.

Before we go into that, my personal AI journey - what part of it is actually the AI transformation??

• Nearly 20 years ago I showed my students what ELIZA is, invented in 1966: masswerk.at/elizabot
  

  → No, not an AI transformation, but interesting what already existed back then
  

• Over 10 years ago I worked for an automotive manufacturer and heard about autonomous driving (the innovation was even much earlier, the research there began in 2000)
  

  → Yes, the companies that already started back then also started their AI transformation, because they already acquired a lot of knowledge and experience
  

• In 2021 I heard about Machine Learning for the first time. I was an Agile Coach of a Data Team for an automotive supplier and we discussed it
  

  → Yes, that is also a beginning of the AI transformation. You start to engage with the topic
  

• In 2022 I completed the Coursera training “AI for everyone” by Andrew Ng, which did not talk about ChatGPT but about Machine Learning, Deep Learning and Data Science
  

  → Yes, trainings and courses are definitely part of the AI transformation
  

• In 2023 I was Agile Coach of several Data Teams in the Health Care sector and one team developed a Recommendation Model with Machine Learning and Data Science
  

  → Yes, that is already right in the middle of it. Today the work looks different in detail because the models are better. But those who started back then have already begun their AI transformation
  

• Also in 2023 I started using ChatGPT
  

  → Yes, I would count that as well. Companies that give their employees an AI for chatting or as an AI assistant are taking a first step. I cannot build the scenario from the introduction with it yet, but at least you have an AI tool
  

• In the last 3 years I have learned as much as possible about the different types of AI, tested a lot, built a lot, too many to list them all here
  

  → Yes, that is absolutely AI transformation. Maybe in your company you have also tried out dozens of things, sometimes with more, sometimes with less success. Maybe by now there is also some AI chaos - island solutions everywhere, partly shadow AI, lots of half-baked stuff - for me that is all part of the journey
  

• Recently I started using an open source AI agent Hermes to bring order back in and set everything up properly
  

  → Yes, when you start understanding the components of AI agents, you are right at the forefront!
  

• As a next step comes the multi-agent system with Hermes, I am still figuring out how I want to do it
  

  → Yes, that is AI transformation on a larger scale: a functioning multi-AI-agent setup that always has the right information at the right place, is built in at the right spots, is well monitored and controlled. If you have achieved that, you can build the use case from the introduction.

Your AI journey might look different. Or similar.

Maybe your company already has some AI in place.

The question remains, where do you start in a company to also have agentic AI on a large scale.

How do you start in a company?

You start simultaneously with the company leadership and with the first team and every employee:

Leadership

The company leadership initiates,

• that the company remembers its old roots,

• repositions itself with a vision that serves the customers and the employees

• and AI is merely the tool

Why?

A company needs a good corporate culture to be successful. A good corporate culture needs an origin story and a vision. The good culture is grounded and yet motivating and inspiring.

Proclaiming AI as the vision confuses and frightens. Besides, it then goes in the wrong direction. What good is AI to you if your customers are unhappy. Therefore focus on customers and employees and AI is the means to an end.

Trainings and first AI tools

Simultaneously, employees receive trainings, an AI chat or an AI assistant and time to learn

First team as a seed

Simultaneously, the first small team begins. Emphasis here is on small. Pick a use case, do it right until it runs stably in production for a while, then move on to scaling.

More on that in many more articles.

I know that in most companies it starts with AI support or AI agents in software development. But this part is easier to implement than the rest, which is why I focused on business workflows here.

Which AI tools?

You could write dozens of articles about this as well and dozens of articles have already been written by others.

In the further course of this article I assume processes in the company that do not require predictions or recommendations, because that is yet another topic (that goes in the direction of Data Science).

Open source and local models

Open source AI and models that you can use locally are getting better and better. There are already many use cases that you can cover with them.

AI tools “out-of-the-box”

If the use case is clearly defined and many companies have a similar use case and you hardly need any customizing or it is not complex to adapt, then a “ready-made” AI tool is worth it.

“Building” it yourself??

If your use case fulfills the following characteristics, then building it yourself is worth it (and building it yourself does not mean that you develop everything from scratch, more on that below):

• the affected workflow is deep at the heart of your company

• the workflow that could be improved with AI is nothing you would show your competitors

• the use case would require a lot of your company data and this data is not yet prepared in a way that you could just hand it to the AI

• the workflow requires not just answers but real actions across multiple steps

• the workflow does not follow a rigid pattern, but the next sensible step always depends on the specific case

• multiple tools, systems or data sources need to work together cleanly and you cannot achieve that properly with an off-the-shelf solution

• the use case requires a lot of internal context that needs to be fetched, classified and further processed at the right moment

• you want to keep control over which tools are used, which data flows where and when a human steps in

• the case does not occur just once but repeatedly, so that the building effort is really worth it

• the workflow changes continuously and you want to be able to adapt the logic yourself, instead of waiting for an external product

What does building it yourself actually mean?

Models

You do not have to train models yourself for every use case. Models can be LLMs, but there are also other types of models. There are also not only LLMs from Anthropic and OpenAI, but many more. A separate article on that sometime.

In any case, you have a large selection and some of them can also be used on local hardware.

“Harness” around the model

Around the model, roughly speaking, there is actually “just” software.

When you use ChatGPT or Claude, you have a user interface (abbreviation UI).

Between the UI and the model there is more software and many files.

You can see that when you set the mode that thinks longer. Either the orange thing spins at Claude or at ChatGPT various messages appear about what it is doing. All of that is controlled by software and various files are read and various tools are used in the process.

I already briefly touched on that in my last article about the Hermes agent.

That’s good news!

It is extremely good news for everyone: It is not rocket science.

You just have to understand it once: You have some business workflows and somewhere in the workflow there are cumbersome and lengthy steps and exactly these steps you let an AI model handle.

For that, you provide the right data, files and tool access with the request to the model and the model takes care of the rest. In detail it is of course much more complicated, but I only want to make one point here.

And this connection between the user or the trigger and the model is simply software architecture and software engineering. To build this you do not need a PhD in AI.

On a large scale, quite a bit of work is involved of course. But the work needs to be done in areas that most companies already master very well:

• Workflow design

• Subject matter preparation & orchestration (to be honest, I do not know if this is the correct English term) → this falls under the term “Context Engineering”, meaning what content does the AI need when and in what form

• Data Modeling & Data Engineering

• Governance, quite a lot of it!

• Software Architecture & Engineering

• System integration

• Customer Centricity

• DevOps

• Operations & Monitoring

• Security

• Domain & subject matter expertise

• Testing & quality assurance

• etc. etc.

None of this has anything to do with AI at first.

As you can see, I still have to write many articles to at least touch on everything.

My tips for getting started:

• Buy a Mac Mini or several or straight away a local server or host with a trustworthy provider

• Install something like the open source AI agent Hermes or similar

• Use local models or models hosted by trustworthy providers

• Let a few people try things out

• Find a consultant if needed

Assuming you already have a fair amount of AI chaos in your company, then it is time to properly tackle a use case.

But stop: You are probably wondering now why I keep bringing up open source…

Why open source?

Data protection, confidentiality, laws

There are good reasons not to hand over your company data, your internal processes, your workflows, your entire domain knowledge, your own experience and that of your employees, everything that makes you who you are and makes you successful, all of that to an AI company.

Some companies and organizations will not even be allowed to do so due to laws.

If you do want to work with the big AI providers, you need to regulate quite a few things contractually.

But there are further points that speak in favor of open source and/or local and/or self-developed AI agent frameworks.

Dependency

If you do not build the framework of the AI agents yourself but take Claude Code, Codex or something else, and you embed the whole thing deep into your business processes, you make yourself very dependent.

Anyone who has ever dealt with legacy systems or migrations knows how painful that is.

Costs

The big AI companies have raised enormous amounts of money. Now they have to earn enormous amounts of money. Do not make that your problem.

Build your agentic AI in a way that you can control costs and not in a way that the other controls you.

In the future

In the future there may be cleanly encapsulated off-the-shelf solutions for agentic AI. You can look at that again then. But I would still start now, so that the competitors’ head start does not become too large.

The mix is key

When you dive deeper into the topic, it will become apparent that for some parts of agentic AI a big well-known AI model could be suitable and for many others a local model is sufficient.

You really have to disentangle it and build the agentic AI in a way that you can choose different models for different tasks.

But now back to the use cases.

How do I recognize whether a use case is suitable for AI?

You could recognize suitable use cases by this:

• You have cumbersome work steps where people have to search through, process, evaluate and pass on a lot of material or information

• Your tools, systems or data sources do not communicate cleanly with each other and this creates effort and frustration

• A workflow does not simply follow a rigid pattern but repeatedly requires classification, prioritization and only then do you know the next sensible step

• The use case requires a lot of internal context, knowledge or company data that is not simply included in off-the-shelf tools

• The workflow is important for your business and not something you want to map as a standard solution off the rack

• The effort does not occur just once but repeatedly, so that a proper solution is really worth it

• You want to keep the logic, data access and further development in your own hands

Market and competitive analysis

A very good starting use case is often to first let the local AI classify your own company, the market, the competitors and the strategic direction

If you do this locally, your company data does not leave the hardware, meaning you can work with it without concern (this might sound strange to people from the US, but it is a big concern in Germany).

Back to the introduction

Many who have been dealing with AI for a while repeat it often: AI changes organizations significantly. To achieve a scenario as described in the introduction well, many things need to work together perfectly.

Anyone who has been involved in such an endeavor knows the challenges.

In my view there are several causes for why it is so difficult and I want to briefly address one more.

Not an IT project - it stands and falls with people

Most AI consultants say themselves that AI is not an IT project and yet everyone starts with the technology.

Anyone who has been in professional life for a while knows that it always begins with people.

There are so many obstacles on the human and on the leadership level that have already complicated many initiatives.

Today just one aspect:

• If in your company you have business departments strictly separated from software engineers, data engineers or other IT people

• If you have so many leading and coordinating roles that they are already stepping on each other’s toes, such as per team a team lead, a product owner, a project manager, a Scrum Master and then the whole thing multiplied per team and from 2 teams onward all the department heads come in and from 2 departments onward the division heads and then we have not even listed all the architects and subject matter experts

• If you manage to fill a workshop with 30 people and everyone has an opinion and no one has to take responsibility if something does not work in production

Then these are structures that will make your AI transformation very difficult. Everything that does not “flow” along the customer or business workflow and interlock meaningfully slows down the AI transformation.

Sometimes you have experiences like that as a customer where you are just frustrated.

Often organizational structures are the root cause, since they dictate the communication, way of working and career paths.

There are proven ways to build a company differently, you just have to want it. I will write quite a bit more about this, because that is my specialty.

Learning journey

Whoever is ready for this begins a learning journey. There is incredibly much to learn and it is fun.

Will we lose our job through the AI transformation?

I honestly do not believe so. There is so much work involved in building agentic AI properly.

What I am sure about though:

But everyone has to adapt, especially the leaders.

I am sure that AI will reshape the entire organization in the long run. Therefore I would prepare for the fact that everyone has to live with titles and roles disappearing and doing different things later than before. And for this to succeed, you have to meet people where they are.

Starting with people

A successful AI transformation - no matter how much AI is already present in the company:

• has this one moment where you reflect on the origin and the vision of the company

• ensures that the company delivers value to customers and employees, through AI

• gives all employees trainings and time to learn

• gives all employees security

• but says clearly and distinctly that EVERYONE - including the entire leadership team - has to prepare for different tasks and roles

To achieve this successfully, you need not only technical AI consultants but also those who have experience in bringing people along and how to shape transformations successfully.

If you liked this article, I would be happy about a like or a recommendation.

Please also comment if you see things differently or if I have made mistakes.

Anyone who wants to discuss their own AI transformation with me, no obligation and free of charge, can reach me via LinkedIn , via my website or here on Substack.

I look forward to the exchange!

English version will follow right away!

Lieber Leser,

der Artikel ist so aufgebaut, dass Du auch einfach zu der Überschrift springen kannst, die Dich interessiert.

Always start with Why

Warum sollte ich überhaupt eine KI-Transformation wollen würden?

Stell Dir folgendes Szenario vor:

Ein potentieller Kunde fragt über Claude.ai oder ChatGPT etwas, wofür Du die passenden Produkte oder Services hättest.

In der Chatantwort wird zu Deinen Produkten und Services verlinkt.

Der potentielle Kunde klickt darauf und auf Deiner Website schaffst Du es durch ein paar gezielte interaktive Fragen den potentiellen Kunden so zu verstehen, dass Du ihm ein individuell zugeschnittenes Angebot machen kannst. Vielleicht war der potentielle Kunde sogar schon mal auf Deiner Website und Du erkennst es und hast alle Informationen von damals parat.

Der potentielle Kunde fühlt sich verstanden und Du schaffst es den Kundenwunsch zu erfüllen, über alle Medien hinweg - Website, E-Mail, App, Handy, egal was - stets synchron, nahtlos und geschmeidig ein rundum gelungenes Kundenerlebnis anzubieten.

Der Kunde ist super happy, weil alles so glatt läuft und wenn er wirklich mal ein spezielles Anliegen hat, kommt er sofort an einen echten Mitarbeiter.

Klingt toll oder?

Wie sieht die Realität aus?

Also ich hatte in den letzten 2 Jahren allein 4 Erfahrungen mit Banken, Versicherungen, Krankenversicherungen und Online-Händlern, die genau das Gegenteil waren: anstrengend, viele Medienbrüche, auf einmal waren die Informationen nicht mehr überall konsistent, Anliegen wurden nicht verstanden, man wird von Pontius zu Pilatus geschickt, Anleitungen zu kompliziert oder widersprüchlich, Anliegen wurde nicht gelöst, Fehler wurden gemacht, viel Kommunikation etc. pp. Ihr kennt das alle.

Diejenigen, die in solchen Bereichen arbeiten, wissen: da gehört nicht nur KI dazu, solche Prozesse sauber aufzusetzen und ich gehe später noch darauf ein. Aber KI kann das ganze nochmal auf eine andere Stufe heben.

Es gibt noch viel, viel mehr Use Cases, wo KI wirklich hilft. Aber, wie kommen wir da hin?

KI-Transformation - wie beginnt es denn meistens?

KI-Transformation ist ein schwammiger Begriff. Ich meine, schon alleine KI ist so ein riesiges Spektrum. Nicht für jeden Use Case sieht die KI-Transformation gleich aus.

Bevor wir darauf eingehen, meine persönliche KI-Reise - was davon ist denn eigentlich die KI-Transformation??

• Vor knapp 20 Jahren habe ich meinen Schülern gezeigt, was ELIZA ist, erfunden 1966: masswerk.at/elizabot
  
  → Nein, keine KI-Transformation, aber interessant, was es damals schon gab
  

• Vor über 10 Jahren habe ich für einen Automobilhersteller gearbeitet und von autonomem Fahren gehört (die Innovation war sogar viel früher, die Forschung begann dort 2000)
  

  → Ja, die Firmen, die damals schon anfingen, fingen auch schon mit der KI-Transformation an, denn sie haben sich schon sehr viel Wissen und Erfahrung angeeignet
  

• 2021 habe ich zum ersten Mal von Machine Learning gehört. Ich war Agile Coach eines Data Teams für einen Automobilzuliefer und wir haben darüber diskutiert
  

  → Ja, das ist auch ein Anfang der KI-Transformation. Man fängt an sich mit dem Thema auseinanderzusetzen
  

• 2022 habe ich das Coursera-Training „AI for everyone“ von Andrew Ng absolviert, das nicht über ChatGPT sprach, sondern über Machine Learning, Deep Learning und Data Science
  

  → Ja, Schulungen und Trainings gehören definitiv zur KI-Transformation
  

• 2023 war ich Agile Coach mehrerer Data Teams im Bereich Health Care und ein Team entwickelte ein Recommendation Model mit Machine Learning und Data Science
  

  → Ja, das ist schon mittendrin. Heute sieht die Arbeit im Detail anders aus, weil die Modelle besser sind. Aber wer damals schon begonnen hat, hat die KI-Transformation schon gestartet
  

• Ebenfalls 2023 habe ich angefangen, ChatGPT zu nutzen
  
  → Ja, auch das würde ich dazu zählen. Firmen, die ihren Mitarbeitern eine KI zum Chatten oder als KI-Assistenten geben, machen einen ersten Schritt. Ich kann damit zwar noch nicht das Szenario in der Einleitung bauen, aber immerhin hat man ein KI Hilfsmittel
  

• In den letzten 3 Jahren habe ich so viel wie möglich über die verschiedenen Arten von KI gelernt, viel getestet, viel gebaut, zu viele, um sie hier alle aufzuzählen
  

  → Ja, das ist sowas von KI-Transformation. Vielleicht hast Du in Deinem Unternehmen auch schon zig Sachen ausprobiert, mal mit mehr, mal mit weniger Erfolg. Vielleicht gibt es mittlerweile auch etwas KI Chaos - überall Insellösungen, teils Schatten KI, viel halbgarenes Zeug - das gehört für mich alles mit zur Reise
  

• Vor kurzem habe ich angefangen, einen Open-Source-KI-Agenten Hermes zu nutzen um wieder Ordnung reinzubringen und alles sauber aufzusetzen
  
  → Ja, wenn Du anfängst die Bestandteile von KI-Agenten zu verstehen, bist Du ganz vorne mit dabei!
  

• Als nächster Schritt kommt das Multi-Agenten-System mit Hermes, ich bin noch am Herausfinden, wie ich das machen will
  
  → Ja, das ist KI-Transformation im größeren Stil: ein funktionierendes Multi-KI-Agenten-Setup, das stets die richtigen Informationen zur richtigen Stelle hat, an den richtigen Stellen eingebaut ist, gut überwacht und kontrolliert ist. Wenn Du das geschafft hast, kannst Du den Use Case aus der Einleitung bauen.
  

Deine KI-Reise sieht vielleicht anders aus. Oder ähnlich.

Vielleicht hast Dein Unternehmen schon das eine odere an KI.

Die Frage bleibt, wo fängt man im Unternehmen an um auch die agentische KI im großen Stil zu haben.

Wie fängt man im Unternehmen an?

Du fängst gleichzeitig bei der Unternehmensleitung und beim ersten Team und jedem Mitarbeiter an:

Unternehmensleitung

Die Unternehmensleitung initiiert,

• dass sich das Unternehmen an alte Wurzeln erinnert,

• sich neu aufstellt mit einer Vision, die den Kunden und den Mitarbeitern dient

• und KI ist lediglich das Hilfsmittel

Warum?

Ein Unternehmen braucht eine gute Unternehmenskultur um erfolgreich zu sein. Eine gute Unternehmenskultur braucht eine Entstehungsgeschichte und eine Vision. Die gute Kultur ist geerdet und trotzdem motivierend und inspirierend.

KI als Vision auszurufen verwirrt und verängstigt. Außerdem geht es dann in die falsche Richtung. Was nützt Dir KI wenn Deine Kunden unzufrieden sind. Daher Fokus auf Kunden und Mitarbeiter und KI ist das Mittel zum Zweck.

Schulungen und erste KI-Hilfsmittel

Gleichzeitig erhalten Mitarbeiter Schulungen, einen KI-Chat oder einen KI-Assistenten und Zeit zum Lernen

Erstes Team als Keimzelle

Gleichzeitig beginnt das erste kleine Team. Betonung liegt hier auf klein. Suche einen Use Case aus, mach ihn richtig bis er stabil eine Weile in Produktion läuft, dann geht es weiter mit Skalierung.

Mehr dazu in vielen weiteren Artikeln.

Ich weiß, dass es in der Softwareentwicklung meistens beginnt in Unternehmen mit KI-Unterstützung oder KI-Agenten. Dieser Teil ist aber leichter umzusetzen als der Rest, daher habe ich mich hier auf Business Prozesse konzentriert.

Welche KI Tools?

Auch darüber könnte man zig Artikel schreiben und wurden auch schon zig Artikel von anderen geschrieben.

Im weiteren Verlauf des Artikels gehe ich von Prozessen im Unternehmen aus, die keine Vorhersagen oder Empfehlungen benötigen, denn das ist nochmal ne andere Baustelle (da geht es dann Richtung Data Science).

Open Source und lokale Modelle

Open Source KI und Modelle, die man lokal benutzen kann, werden immer besser. Es gibt bereits viele Use Cases, die man damit abdecken kann.

KI-Tools “out-of-the-box”

Wenn der Use Case klar abgegrenzt ist und viele Unternehmen einen ähnlichen Use Case haben und Du kaum Customizing brauchst bzw. es nicht aufwändig ist es anzupassen, dann lohnt sich ein “fertiges” KI-Tool.

Selber “bauen”??

Wenn Dein Use Case folgende Eigenschaften erfüllt, dann lohnt sich selber bauen (und selber bauen heißt nicht, dass man alles von Null auf selbst entwickelt, unten mehr dazu):

• der betroffene Prozess steckt tief im Herzen Deines Unternehmens

• der Ablauf, der mit KI besser werden könnte, ist nichts, was Du Deinen Mitbewerbern zeigen würdest

• der Anwendungsfall würde viele Deiner Unternehmensdaten benötigen und diese sind noch nicht so aufbereitet, dass man sie gleich der KI geben könnte

• der Vorgang braucht nicht nur Antworten, sondern echte Aktionen über mehrere Schritte hinweg

• der Ablauf ist nicht stur nach Schema F, sondern der nächste sinnvolle Schritt hängt immer wieder vom konkreten Fall ab

• mehrere Tools, Systeme oder Datenquellen müssen sauber zusammenspielen und das kriegst Du mit einer fertigen Lösung nicht ordentlich hin

• der Anwendungsfall braucht viel internen Kontext, der im richtigen Moment geholt, eingeordnet und weiterverarbeitet werden muss

• Ihr wollt die Steuerung darüber behalten, welche Tools genutzt werden, welche Daten wohin fließen und wann ein Mensch dazwischen geht

• der Fall kommt nicht nur einmal vor, sondern immer wieder, so dass sich der Bauaufwand wirklich lohnt

• der Prozess verändert sich laufend und Ihr wollt die Logik selbst anpassen können, statt auf ein Produkt von außen zu warten

Was heißt selber bauen überhaupt?

Modelle

Modelle muss man nicht für jeden Use Case selbst trainieren. Modelle können LLMs sein, es gibt aber auch andere Arten von Modellen. Es gibt auch nicht nur LLMs von Anthropic und OpenAI, sondern noch viele mehr. Dazu mal ein separater Artikel.

Man hat auf jeden Fall eine große Auswahl und einige davon kann man auch auf lokaler Hardware verwenden.

“Gerüst” um das Modell herum

Um das Modell herum ist ganz grob gesagt eigentlich “nur” Software.

Wenn Du ChatGPT oder Claude verwendest, hast Du ja eine Benutzeroberfläche (Abkürzung UI für User Interface).

Zwischen der UI und dem Modell ist noch Software und viele Dateien.

Du siehst das, wenn Du den Modus einstellst, der länger nachdenkt. Entweder dreht sich das orangene Ding bei Claude oder bei ChatGPT kommen verschiedene Meldungen, was er denn so treibt. Das alles wird durch Software gesteuert und es werden dabei verschiedene Dateien gelesen und verschiedene Tools benutzt.

Ich hab das in meinem letzen Artikel zum Hermes Agenten schon mal kurz angerissen.

That’s good news!

Es sind extrem gute Neuigkeiten für alle: Es ist kein Hexenwerk. Es ist keine Raketenwissenschaft.

Du musst es nur einmal verstehen: Du hast irgendeinen Unternehmensprozess und irgendwo im Prozess gibt es umständliche und langwierige Schritte und genau diese Schritte lässt Du von einem KI-Modell erledigen.

Dazu stellst Du bei der Anfrage an das Modell die richtigen Daten, Dateien und Toolzugriffe zur Verfügung und das Modell erledigt den Rest. Im Detail ist es natürlich viel komplizierter, aber ich will hier nur auf einen Punkt raus.

Und diese Verbindung zwischen dem User oder dem Trigger und dem Modell ist einfach nur Software Architektur und Software Engineering. Um das bauen zu können braucht man keinen Doktortitel in KI. Eine Fachinformatikerausbildung und der Wille zu lernen reicht aus.

Im großen Stil gehört natürlich einiges an Arbeit dazu. Aber die Arbeit ist in Bereichen zu erledigen, die die meisten Unternehmen schon sehr gut beherrschen:

• Prozessdesign

• Sachverhaltsaufbereitung & Steuerung → das geht dann unter dem Begriff “Context Engineering” auf, also welchen Inhalt braucht die KI wann und in welcher Form

• Data Modeling & Data Engineering

• Governance, ziemlich viel davon!

• Software Architektur & Engineering

• Systemintegration

• Customer Centricity

• DevOps

• Operations & Monitoring

• Security

• Fachbereichs- & Domänenwissen

• Testen & Qualitätssicherung

• etc. pp

Hat alles erstmal nix mit KI zu tun.

Wie Ihr seht muss ich noch viele Artikel schreiben um alles mal wenigstens anzureißen.

Meine Tipps für den Start:

• Kauf nen Mac Mini oder mehere oder gleich nen lokalen Server oder hoste bei einem vertrauenswürdigen Anbieter

• Installiere sowas wie den Open Source KI Agenten Hermes oder ähnliches

• Verwende lokale Modelle oder Modelle, die bei vertrauenswürdigen Anbietern gehostet sind

• Lass mal ein paar Leute was ausprobieren

• Suche Dir ggf. einen Berater

Angenommen Du hast schon einigermaßen ein KI Chaos im Unternehmen dann wird es Zeit sich mal einen Use Case ordentlich vorzuknüpfen.

Aber Stopp: Du fragst Dich jetzt bestimmt warum ich hier dauernd mit Open Source komme…

Warum Open Source?

Datenschutz, Geheimhaltung, Gesetze

Es gibt Gute Gründe seine Unternehmensdaten, die internen Abläufe, die Prozesse, das gesamtes Fachwissen, die eigene Erfahrung und die der Mitarbeiter, alles, was Euch ausmacht und erfolgreich macht, all das nicht einem KI-Unternehmen zu übergeben.

Einige Unternehmen und Organisationen werden es auch aufgrund von Gesetzen gar nicht dürfen.

Falls man doch mit den großen KI-Anbietern zusammenarbeiten will, muss man vertraglich einiges regeln.

Es gibt aber noch weitere Punkte, die für Open Source und/oder lokal und/oder selbst entwickeltes KI-Agenten-Gerüst sprechen.

Abhängigkeit

Wenn Du das Gerüst der KI-Agenten nicht selbst baust, sondern Claude Code, Codex oder was anderes nimmst, und Du das ganze tief in Deine Unternehmensprozesse einbaust, machst Du Dich sehr abhängig.

Jeder der schon mal mit Legacy oder mit Migrationen zu tun hatte, weiß wie schmerzhaft das ist.

Kosten

Die großen KI-Firmen haben enorm viel Geld eingesammelt. Nun müssen sie enorm viel Geld verdienen. Mach das nicht zu Deinem Problem.

Baue Deine agentische KI so auf, dass Du Kosten steuern kannst und nicht so, dass der andere Dich steuert.

In Zukunft

In Zukunft wird es vielleicht sauber gekapselte Kauf-Lösungen für agentische KI geben. Das kann sich dann wieder anschauen. Ich würde aber trotzdem jetzt schon anfangen, damit der Vorsprung der Konkurrenz nicht zu groß wird.

Die Mischung macht’s

Wenn man tiefer in das Thema einsteigt, wird sich zeigen, dass für manche Abschnitte in der agentischen KI ein großes bekanntes KI-Modell geeignet sein könnte und für viele andere ein lokales Modell ausreicht.

Man muss es wirklich auseinanderklamüsern und die agentische KI so aufbauen, dass man verschiedene Modelle für verschiedene Aufgaben wählen kann.

Aber nun zurück zu den Use Cases.

Woran erkenne ich ob ein Use Case für KI geeignet ist?

Passende Use Cases könntest Du daran erkennen:

• Ihr habt umständliche Arbeitsschritte, bei denen Menschen viel Material oder Informationen suchen, durcharbeiten, bewerten und weiterverarbeiten müssen

• Eure Tools, Systeme oder Datenquellen sprechen nicht sauber miteinander und dadurch entsteht Aufwand und Frust

• Ein Vorgang läuft nicht einfach stur nach Schema F, sondern erfordert immer wieder Einordnung, Priorisierung und erst dann weiß man den nächsten sinnvollen Schritt

• Der Anwendungsfall braucht viel internen Kontext, Wissen oder Unternehmensdaten, die in fertigen Tools nicht einfach so drinstecken

• Der Prozess ist wichtig für Euer Geschäft und nichts, was Ihr als Standardlösung von der Stange abbilden wollt

• Der Aufwand fällt nicht nur einmal an, sondern immer wieder, so dass sich eine saubere Lösung wirklich lohnt

• Ihr wollt die Logik, den Datenzugriff und die Weiterentwicklung selbst in der Hand behalten

Markt- und Wettbewerbsanalyse

Ein sehr guter Start-Use-Case ist oft, die lokale KI erst einmal das eigene Unternehmen, den Markt, die Mitbewerber und die strategische Richtung einordnen zu lassen

Wenn Du das lokal durchführst, verlassen Deine Unternehmensdaten nicht die Hardware, d.h. Du kannst bedenkenlos damit arbeiten.

Zurück zur Einleitung

Viele, die sich schon eine Weile mit KI beschäftigen, wiederholen es oft: KI verändert Unternehmen stark. Um so ein Szenario wie in der Einleitung beschrieben, gut hinzubekommen, müssen viele Dinge perfekt ineinanderspielen.

Wer schon mal in so einem Vorhaben tätig war, kennt die Herausforderungen.

Meiner Ansicht nach gibt es mehrere Ursachen dafür, warum es so schwierig ist und auf eine möchte ich noch kurz eingehen.

Kein IT-Projekt - es steht und fällt mit Menschen

Die meisten KI Berater sagen ja selbst, dass KI kein IT-Projekt ist und trotzdem fangen alle mit der Technik an.

Wer schon eine Weile im Berufsleben ist, weiß aber, dass es immer mit den Menschen beginnt.

Es gibt so viele Hindernisse auf der menschlichen und auf der Führungsebene, die schon viele Vorhaben verkompliziert haben.

Heute mal nur ein Aspekt:

• Wenn Du in Deinem Unternehmen Fachbereiche strikt getrennt hast von Software Engineers, Data Engineers oder sonstigen IT Leuten

• Wenn Du so viele führende und koordinierende Rollen hast, dass sie sich schon gegenseitig auf die Füße treten, wie z.B. pro Team einen Teamleiter, einen Product Owner, einen Projektmanager, einen Scrum Master und dann das ganze multipliert pro Team und ab 2 Teams kommen dann noch die ganzen Abteilungsleiter hinzu und ab 2 Abteilungen die Bereichsleiter und dann haben wir ja noch gar nicht die ganzen Architekten und Subject Matter Experts aufgezählt

• Wenn Du es schaffst einen Workshop mit 30 Personen zu füllen und alle eine Meinung haben und keiner muss den Kopf dafür hinhalten, wenn etwas in Produktion nicht funktioniert

Dann sind das Strukturen, die Dir Deine KI-Transformation sehr erschweren werden. Alles, was nicht entlang des Kunden- oder Unternehmensprozesses “fließt” und sinnvoll ineinandergreift, verzögert die KI-Transformation.

Manchmal hat man solche Erlebnisse, dass man als Kunde nur noch frustriert ist.

Oft sind organisatorische Strukturen die Ursache, da diese die Kommunikations-, Arbeits- und Karrierewege vorgeben.

Es gibt bewährte Wege ein Unternehmen anders aufzubauen, man muss es nur wollen. Dazu werde ich auch noch einiges schreiben, denn das ist mein Spezialgebiet.

Lernreise

Wer dafür bereit ist, beginnt eine Lernreise. Es gibt unglaublich viel zu lernen und es macht Spaß.

Werden wir durch die KI-Transformation unseren Job verlieren?

Ich glaube es ehrlich gesagt nicht. Es ist so viel Arbeit die agentische KI richtig aufzubauen.

Wo ich mir aber sicher bin:

Aber alle müssen sich umstellen, vor allem die Führungskräfte.

Ich bin mir sicher, dass KI die gesamte Organisation langfristig umkrempeln wird. Daher würde ich mich schon darauf einstellen, dass jeder damit leben muss, dass Titel und Rollen verschwinden und man später andere Dinge tut als vorher. Und damit dies gelingt, muss man die Menschen abholen wo sie sind.

Mit den Menschen beginnen

Eine gelungene KI-Transformation - egal wie viel KI schon im Unternehmen vorhanden ist:

• hat diesen einen Moment, wo man sich wieder auf den Ursprung und die Vision des Unternehmens besinnt

• achtet darauf, dass das Unternehmen für Kunden und Mitarbeiter einen Mehrwert liefert, durch KI

• gibt allen Mitarbeitern Schulungen und Zeit zum Lernen

• gibt allen Mitarbeitern Sicherheit

• sagt aber klar und deutlich, dass ALLE - inklusive der gesamten Führungsmannschaft - sich auf andere Aufgaben und Rollen einstellen müssen

Um dieses erfolgreich hinzubekommen, brauchst Du nicht nur technische KI Berater, sondern auch welche, die Erfahrung damit haben die Menschen mitzunehmen und wie man Transformationen erfolgreich gestaltet.

Wenn Dir dieser Artikel gefallen hat, dann freue ich mich über ein Like oder ein Weiterempfehlen.

Bitte kommentiert auch, wenn Ihr Dinge anders seht oder wenn mir Fehler unterlaufen sind.

Wer seine eigene KI-Transformation mit mir unverbindlich und kostenlos besprechen will, kann mich über LinkedIn , über meine Website oder hier in Substack erreichen.

Ich freue mich auf den Austausch!

this article is modular again. You can simply jump to the heading that interests you.

Have you already installed the autonomous AI agent Hermes? If not, here is the guide.

First Use Case for the Hermes Agent: Creating a Wiki

We want to create a small wiki, for the following reasons:

• A wiki is very useful for knowledge workers. It replaces folders and files and provides real added value through linking and categorization.

• Creating a wiki manually is very time-consuming and tedious. An AI agent does in minutes what a human would need weeks to accomplish.

• The underlying structure (Markdown files, see below) is reusable for many other use cases.

As an example topic we take the EU AI Act, for the following reasons:

• The topic is neutral yet interesting.

• It is easy for LLMs to research and break down, meaning not much can go wrong.

Further learning goals:

• how an autonomous AI agent works and what instructions it needs

• what Markdown is and how to view it with Obsidian

• what the AI agent is roughly made of

And at the end of the article I will go into what I derive from this for AI transformation in companies.

Guide

Open a terminal window and type “hermes chat”.

Pre-discussion

Discuss with Hermes what should be in the wiki.

My tips:

For the trial run, start with an easy topic. First see small wins, then expand. Agile by the book, so to speak.

Also think about a few kill criteria in advance. I am rigorous about this. If it takes longer than a few minutes, I stop and we start fresh. I want an autonomous AI agent and not to sit in front of the screen for hours. There needs to be something tangible to see quickly. If that is not the case, my approach was not optimal. Don’t get lost.

Example

After some back and forth, this is what emerged. Honestly, I am not sure whether this is strictly speaking a “skill” or an “instruction” or a “prompt” and I have to say, I don’t really care. In my view the terms are not sharply defined anyway, and who knows what they will be called in a few months. In any case, this is something like an instruction for the agent.

Hermes wrote all of this. It is certainly not perfect. Feel free to adapt it to your needs.

At this stage I had not yet worked with different sub-agents or parallel agents. One thing at a time.

---
name: eu-ai-act-wiki-construction
category: software-development
description: Workflow for creating an atomic knowledge wiki about the EU AI Act, optimized for advising German companies (users/deployers).
---

# 🚀 EU AI Act Wiki - Master Construction Guide

## 1. Context & Goal
The goal is to build a "single source of truth" in Markdown (Obsidian) that makes it possible to generate summaries, slides, or web apps individually tailored to client needs.
**Focus:** German companies that deploy AI systems (deployers).

### Target Groups (The First Movers)
1. **High-Risk Users:** HR, healthcare, financial services, critical infrastructure, public authorities.
2. **Enterprise AI Users:** Large companies with deep integration of AI into core processes.
3. **Compliance Managers:** Legal and IT departments.

---

## 2. The Creation Process (Iteration Cycle)

### Phase 1: Analysis & Mapping
- Identification of relevant modules of the AI Act.
- Creation of a prioritization matrix based on regulatory deadlines.

### Phase 2: Atomization (Markdown Creation)
Each knowledge point is created as an individual `.md` file (Zettelkasten principle).
- **Hub Structure:** Implementation of sector landing pages.
- **Linking Logic:** Hub Page → Use Case Note → Obligation Note → Original Source.

### Phase 3: Networking & Review
- Building of topic clusters.
- Validation by consultants.
- Iterative refinement based on feedback.

---

## 3. Operational Standards & Quality Assurance

### 🛡️ The QA Protocol (Strict Sequence)
Each use case must be validated in exactly this order:
1. **Syntax Check:** Comparison with design templates, no double blank lines, consistent labels.
2. **Mandatory Field Injection:** Check `**Compliance Data:**` (All / Aug 2026 / 01.08.24).
3. **Implementation Page Initialization:** Create `[UC-Name]-Implementation.md`.
4. **Implementation Page Population:** Complete contents according to template (Measures 1-4).
5. **Use Case Feedback:** Set link to implementation.
6. **Categorization:** Place correct `[[Sector-Hub]]` in first position.
7. **Navigation Check:** Verify bidirectionality (UC ↔ Impl), hierarchy (UC → Hub), and index entry.

### 🚀 Batch-Processing Mode (Performance Optimization)
To avoid sequential bottlenecks, the following mode is used:
- **Bulk-Read:** Load 10-15 use cases into context simultaneously.
- **Analysis & Synthesis:** Identify gaps and formulate content in batch.
- **Bulk-Write:** Massive sequence of `write_file` calls.
- **Verification:** Post-batch check of all updated files.

### 🎯 Quality Requirements (Zero-Tolerance)
- **Sector:** Must link to the hub without exception.
- **Classification:** Explicit statement of High-Risk vs. Transparency (Annex III / Art. 50).
- **Implementation:** "Consultant-grade" practical scenarios, no generic summaries.
- **Sources:** Direct mandatory reference to the original text (e.g. Annex III).

---

## 4. Design Templates

### 📋 Use Case Page
# [UC-Name]
**Sector:** [[Hub-Name]]

**Classification:** [Risk class] analogous to [[High-Risk-AI-Classification]], [justification].

**Compliance Data:**
- **Company Size:** All (including micro-enterprises)
- **Timeline / Deadline:** August 2026 (Phase 3)
- **Entry into Force:** 01 August 2024

**What does this mean concretely for you as an employee? (Implementation)**
1. **Transparency:** [Description]
2. **Human Oversight:** [Description] ([[High-Risk-AI-Obligations-Deployer]])
3. **Bias Check:** [Description]
4. **Documentation:** [Description]

**Implementation:** [[UC-Name-Implementation]]

**Sources:** [[EU-AI-Act-Original-Text]] (Annex III)

### 🛠️ Implementation Page
**Use Case:** [[UC-Name]]

# [UC-Name]-Implementation

**Measure 1: Transparency**
- Example: [Concrete implementation scenario]

**Measure 2: Human-in-the-Loop**
- Example: [Concrete implementation scenario]

**Measure 3: Bias Check**
- Example: [Concrete implementation scenario]

**Measure 4: Documentation**
- Example: [Concrete implementation scenario]

---

## 5. Infrastructure & Structure

### Directory Structure
- `/EU-AI-Act/`
    - `/Basics/` (Definitions, scope, timeline)
    - `/Risk-Framework/` (Definitions of classes & obligations)
    - `/Use-Cases/` (Sectoral notes & use cases)
    - `/Compliance-Check/` (Sanctions, deadlines, checklists)
    - `/Archive-Sources/` (Raw sources/references)

### Quality Standards
- **No summaries:** Only granular facts.
- **Reference obligation:** Every claim must be substantiated.
- **Consultant perspective:** Content must be directly transferable to slides or training sessions.

• Hermes then saved the file as a Markdown file with the extension .md.

• It is also advisable to agree with Hermes on where the wiki should be saved.

• Then you only need to say: read it in and get started.

• A few minutes later the wiki is ready.

• There will still be errors in the first run though.

AI Works Differently Than Software

LLMs work probabilistically.

That means: If you give them the same command multiple times, you get a different result each time.

Why this is the case, there are already many articles on this. It has something to do with mathematically calculated probabilities. It is called probabilistic.

For AI transformation in companies this means: You first have to get used to it.

For years people learned: Input → Processing → Output

And now it is: Input → AI does something → Output always slightly different

Why use AI then?

The strength of AI is processing enormous amounts of text, images, and other formats at tremendous speed and generating something useful from them.

Often though you need something that works by strict rules and delivers correct results. That is called deterministic. Then you use software.

Software will continue to exist.

The strength of software is: always applying the same rules and thereby always delivering the desired results.

Using AI for Wiki Creation

The use case of creating a wiki would be barely achievable with software, especially if you were doing extensive research. You would have to know in advance what the research material looks like, how it should be processed, etc., and creating that software would also be time-consuming.

AI has no problem with that, it simply does it and does it fast.

A few minutes after you have given Hermes the instruction to create a wiki on the EU AI Act, you might have something like this (I’m really sorry that all my screenshots are German):

How Do You View the Wiki?

Markdown files are not particularly pleasant to read.

As a UI you can use Obsidian. Simply download it:

https://obsidian.md/

I first tried to read and understand the Obsidian website, but such pages tire me out. So I left it. I simply downloaded it and used it.

It then looks like this:

With Obsidian you navigate through folders and files and click from page to page.

You can also edit directly within it.

Extremely handy.

Obsidian can do more, just try it out. I don’t want to write detailed tutorials, but rather encourage learning and later derive principles.

There is one nice gimmick I still want to show. The Knowledge Graph. But beware! It is not a REAL knowledge graph. A real knowledge graph would have relationship types between the nodes.

This here is simply a networked visualization of all existing wiki pages:

The nice thing is, when you click on a node, you can see the linked pages highlighted in color:

I think that will be very helpful to me later.

As mentioned above, be prepared for the first run not to be error-free. Then run a QA session with Hermes. Tell Hermes what to watch out for and then it starts again.

For large research tasks and a lot of material you would build a multi-agent setup. I am currently experimenting with how that works. If anyone has already done it, please get in touch!

Further Use of the Markdown Files

Markdown files are ideal for LLMs: they are fairly “raw,” consist of only a few characters, and still have structure. That is exactly what LLMs love.

When reading Markdown files they do not have to process as many characters and therefore consume fewer tokens than if they had to read PDFs, Word documents, or HTML pages every time.

With the Markdown files you can then do all sorts of other things. The agent can make suggestions, but it can also build web apps from them, create presentations or templates, whatever you need.

When NOT to Use Markdown

Markdown is not the format for everything.

Rule of thumb:

• Is what I want more like a document or a mind map? → Markdown

• Is what I want more like a table, because I want to sort, filter, or calculate something? → Database

More articles will follow on what you can do with an AI agent and a database, because I will need that myself. But for today, just the basics.

What Is the AI Agent Made Of?

I found it very enlightening to understand that the AI agent is simply a few folders with files that sit on my hardware, here is an excerpt:

And an LLM is basically also just folders and files, here is an image from the internet:

So an agent (folders and files on your hardware) connects to an LLM (again files, either local or cloud).

Relatively unspectacular.

Everything that makes agentic AI complicated and complex is all the software engineering around it, possibly also infrastructure.

So the questions are:

• How can you run multiple agents in parallel?

• How do you ensure they do the right thing in the right order?

Technically speaking there are many more questions. More on that in later articles.

What I only want to say here: Those are software engineering questions. You don’t need a doctorate in data science for that. Those are great software engineering questions and all of it is doable.

The organizational questions, the ways of working, governance, data — I will also address those in later articles.

For today I just want to say:

For the vast majority of use cases in which you are simply using existing models, you can already start to understand and learn using the knowledge you already have about software engineering, data modelling and engineering, your own definitions, your own use cases, your own processes, and so on.

AI transformation will be a long learning journey. But to get started you only need a lot of foundation knowledge first.

Everything else must then be worked out step by step, because not that many companies are fully “AI first” yet, so we are all at the beginning.

Perhaps you can already see through this article: You learn best by trying things out.

What Does This Mean for AI Transformation?

My insight after this small experiment: the whole AI debate, as interesting as it may be, does not get you very far in practice.

In my view it is best to start now with small experiments like these and to learn.

My recommendations to companies:

• Buy yourselves a few Mac Minis or set up a server, install the Hermes AI agent locally (I know this sounds strange. I am from Germany and here is open source a mainstream topic)

• Use models that are permitted in your industry, hosted or local

• Ask the entire workforce who would enjoy doing a few experiments, INCLUDING people with non-technical backgrounds

• Let a few people try things out regularly during working hours

• Discuss the learnings together regularly

Why Do I Say This?

As this article and the previous one - and the articles of many other Substack authors - show, AI is not secret knowledge.

The knowledge is accessible to everyone. You don’t need a doctorate to apply AI.

Almost all AI consultants are also just getting started. Very few have been experts in AI for years.

And even if an AI consultant has experience, it does not mean they have seen your company and your processes in exactly the same way somewhere else before.

I have worked in almost 40 organizations (partly because I am not that young anymore and partly because I am self-employed) and every organization is different. Every single one.

There are patterns and principles that can be applied everywhere. But the details have to be rethought from scratch everywhere.

That means the best AI consultant also has to first understand how things are implemented at your company specifically.

Every company has countless tools, data, systems, processes, etc. The challenge is to somehow attach AI to all of that. And that has to be worked out anew for every use case.

So why not start learning and experimenting now, because I am convinced that ideas will come to you.

Perhaps you can also install test data or test systems on the hardware.

Think about which processes or workflows at your company are the most annoying, ask Hermes what could be simplified, and start understanding what the AI agent can do. If this happens on separate local hardware with local models, nothing can break.

But: you start learning and you know what questions you want to ask an AI consultant.

And besides, it is fun 🙂

All Well and Good, But How Does It Scale?

Perhaps you are already ten steps ahead and have real challenges scaling AI in your company.

My experience says:

Ok, there may already be ready-made solutions for standard use cases.

Perhaps there will also be more out-of-the-box solutions in the future.

But for a company with countless tools, scattered data and a complex system landscape with legacy, there are no shortcuts.

There is no way around learning and understanding where to start and how to then scale.

Everyone who is already further along in AI transformation reports the same experiences. Start small, bring one use case stably to production, then continue.

Anyone who claims otherwise is not trustworthy.

My Conviction

My goal is to pass on as much knowledge and understanding as possible, because I have had the experience that clients who have already gotten to grips with a topic want much more consulting from me than clients who say the consultant should handle everything alone.

The more companies engage with AI, the more ideas and potential emerge.

And it also makes it much easier to discuss things together. The client already has concrete questions and there is a shared basic understanding.

What’s Next?

In addition to articles like these where you can try things out yourself, I cover many other topics related to AI transformation. Here is an overview of what I still want to write.

So check back again, leave a like, comment, or recommend me to others.

Thank you very much and I look forward to the exchange!

there will also be an English version.

Lieber Leser,

dieser Artikel ist wieder modular aufgebaut. Du kannst einfach zu der Überschrift gehen, die Dich interessiert.

Hast du den autonomen KI-Agenten Hermes schon installiert? Wenn nicht, hier ist die Anleitung.

Erster Use Case für den Hermes Agenten: Wiki erstellen

Wir wollen einen kleinen Wiki erstellen, aus folgenden Gründen:

• Ein Wiki ist für Wissensarbeiter sehr nützlich. Es ersetzt Ordner und Dateien und ist durch die Verlinkung und Kategorisierung ein echter Mehrwert.

• Einen Wiki manuell anzulegen ist sehr zeitaufwändig und anstrengend. Ein KI-Agent macht in Minuten das, was der Mensch in Wochen schafft.

• Die dahinterliegende Struktur (Markdown Dateien, siehe weiter unten) ist für viele andere Anwendungsfälle wiederverwertbar.

Als Beispielthema nehmen wir den EU AI Act, aus folgenden Gründen:

• Das Thema ist neutral und trotzdem interessant.

• Es ist für LLMs leicht zu recherchieren und zu zerlegen, d.h. es geht nicht so viel schief.

Weitere Lernziele:

• wie ein autonomer KI-Agent arbeitet und welche Instruktionen er braucht

• was ein Markdown ist und wie man es mit Obsidian ansehen kann

• woraus der KI-Agent grob aufgebaut ist
  

Und am Ende des Artikels gehe ich noch darauf ein, was ich daraus für die KI Transformation in Unternehmen ableite.

Anleitung

Öffne ein Terminalfenster und gebe ein “hermes chat”.

Vorbesprechung

Besprich mit Hermes, was im Wiki drin sein soll.

Meine Tipps:

Nimm für den Probelauf erstmal ein leichtes Thema. Erstmal kleine Erfolge sehen, danach erweitern. Sozusagen agil nach Lehrbuch.

Überlege Dir auch vorab ein paar Killkriterien. Ich bin da rigoros. Wenn es länger als ein paar Minuten dauert, breche ich ab und wir setzen neu an. Ich will ja einen autonomen KI-Agenten und nicht stundenlang am Bildschirm sitzen. Es muss schnell was Greifbares zu sehen sein. Wenn das nicht der Fall ist, war mein Ansatz nicht optimal. Verenne Dich nicht.

Beispiel

Nach einigem hin und her, ist dieses hier entstanden. Ehrlich gesagt, weiß ich nicht ob das nun strenggenommen ein “skill” oder eine “instruction” oder ein “prompt” ist und ich muss sagen, es ist mir auch egal. Die Begriffe sind in meinen Augen eh nicht trennscharf, und wer weiß wie es in ein paar Monaten heißt. Auf jeden Fall ist das so eine Art Anweisung für den Agenten.

Das ganze hat Hermes geschrieben. Es ist bestimmt nicht perfekt. Passe es gerne für Deine Bedürfnisse an.

In dieser Phase habe ich noch nicht mit verschiedenen Sub-Agenten oder parallelen Agenten gearbeitet. Eins nach dem anderen.

---
name: eu-ai-act-wiki-construction
category: software-development
description: Workflow zur Erstellung eines atomaren Knowledge-Wikis über den EU AI Act, optimiert für Beratung deutscher Unternehmen (Anwender/Deployer).
---

# 🚀 EU AI Act Wiki - Master Construction Guide

## 1. Kontext & Ziel
Ziel ist der Aufbau einer "Single Source of Truth" in Markdown (Obsidian), die es ermöglicht, individuell auf Kundenbedürfnisse zugeschnittene Zusammenfassungen, Folien oder Web-Apps zu generieren. 
**Fokus:** Deutsche Unternehmen, die KI-Systeme einsetzen (Deployer).

### Zielgruppen (The First Movers)
1. **High-Risk Anwender:** HR, Gesundheitswesen, Finanzdienstleistungen, kritische Infrastruktur, Behörden.
2. **Enterprise-KI-Nutzer:** Große Firmen mit tiefer Integration von KI in Kernprozesse.
3. **Compliance-Verantwortliche:** Rechts- und IT-Abteilungen.

---

## 2. Der Erstellungsprozess (Iteration Cycle)

### Phase 1: Analyse & Mapping
- Identifikation relevanter Module des AI Acts.
- Erstellung einer Priorisierungsmatrix basierend auf regulatorischen Deadlines.

### Phase 2: Atomisierung (Markdown Erstellung)
Jeder Wissenspunkt wird als einzelne `.md` Datei angelegt (Zettelkasten-Prinzip).
- **Hub-Struktur:** Implementierung von Sektor-Landing-Pages.
- **Verknüpfungslogik:** Hub-Page $\rightarrow$ Use-Case Note $\rightarrow$ Pflichten-Note $\rightarrow$ Originalquelle.

### Phase 3: Vernetzung & Review
- Aufbau von Themenclustern.
- Validierung durch Berater.
- Iterative Verfeinerung basierend auf Feedback.

---

## 3. Operational Standards & Quality Assurance

### 🛡️ Das QS-Protokoll (Strikte Sequenz)
Jeder Use Case muss exakt in dieser Reihenfolge validiert werden:
1. **Syntax-Prüfung:** Abgleich mit Design-Templates, keine doppelten Leerzeilen, konsistente Labels.
2. **Pflichtfelder-Injection:** Prüfen von `**Compliance-Daten:**` (Alle / Aug 2026 / 01.08.24).
3. **Implementierungsseite-Initialisierung:** Anlegen von `[UC-Name]-Implementation.md`.
4. **Implementierungsseite-Befüllung:** Inhalte gemäß Template vervollständigen (Maßnahmen 1-4).
5. **Rückkopplung Use-Case:** Link zur Implementation setzen.
6. **Kategorisierung:** Korrekten `[[Sektor-Hub]]` an erste Stelle setzen.
7. **Navigations-Check:** Bidirektionalität (UC $\leftrightarrow$ Impl), Hierarchie (UC $\rightarrow$ Hub) und Index-Eintrag prüfen.

### 🚀 Batch-Processing Mode (Performance Optimierung)
Um sequentielle Bottlenecks zu vermeiden, wird folgender Modus genutzt:
- **Bulk-Read:** 10-15 Use-Cases gleichzeitig in den Kontext laden.
- **Analysis & Synthesis:** Lücken identifizieren und Inhalte im Batch formulieren.
- **Bulk-Write:** Massive Sequenz von `write_file` Calls.
- **Verification:** Post-Batch-Check aller aktualisierten Dateien.

### 🎯 Quality Requirements (Zero-Tolerance)
- **Sektor:** Muss zwingend auf den Hub verlinken.
- **Einstufung:** Explizite Angabe Hochrisiko vs. Transparenz (Annex III / Art. 50).
- **Umsetzung:** "Consultant-Grade" Praxisszenarien, keine generischen Zusammenfassungen.
- **Quellen:** Direkter Referenzzwang auf den Originaltext (z.B. Annex III).

---

## 4. Design-Templates

### 📋 Use-Case Seite
# [UC-Name]
**Sektor:** [[Hub-Name]]

**Einstufung:** [Risikoklasse] analog zu [[Hochrisiko-KI-Klassifizierung]], [Begründung].

**Compliance-Daten:**
- **Unternehmensgröße:** Alle (auch Kleinstunternehmen)
- **Timeline / Deadline:** August 2026 (Phase 3)
- **Inkrafttreten:** 01. August 2024

**Was bedeutet das konkret für dich als Mitarbeiter? (Umsetzung)**
1. **Transparenz:** [Beschreibung]
2. **Menschliche Aufsicht:** [Beschreibung] ([[Hochrisiko-KI-Pflichten-Deployer]])
3. **Bias-Check:** [Beschreibung]
4. **Dokumentation:** [Beschreibung]

**Implementierung:** [[UC-Name-Implementation]]

**Quellen:** [[EU-AI-Act-Originaltext]] (Annex III)

### 🛠️ Implementierungs-Seite
**Use-Case:** [[UC-Name]]

# [UC-Name]-Implementation

**Maßnahme 1: Transparenz**
- Beispiel: [Konkretes Umsetzungsszenario]

**Maßnahme 2: Human-in-the-Loop**
- Beispiel: [Konkretes Umsetzungsszenario]

**Maßnahme 3: Bias-Check**
- Beispiel: [Konkretes Umsetzungsszenario]

**Maßnahme 4: Dokumentation**
- Beispiel: [Konkretes Umsetzungsszenario]

---

## 5. Infrastruktur & Struktur

### Verzeichnisstruktur
- `/EU-AI-Act/`
    - `/Basis/` (Definitionen, Geltungsbereich, Zeitplan)
    - `/Risiko-Framework/` (Definitionen der Klassen & Pflichten)
    - `/Anwendungsfälle/` (Sektoral-Noten & Use-Cases)
    - `/Compliance-Check/` (Sanktionen, Fristen, Checklisten)
    - `/Archiv-Quellen/` (Rohquellen/Referenzen)

### Qualitätsstandards
- **Keine Zusammenfassungen:** Nur granulare Fakten.
- **Referenzpflicht:** Jede Behauptung muss belegt sein.
- **Berater-Perspektive:** Inhalte müssen direkt in Folien oder Trainings überführt werden können.

• Hermes hat die Datei dann als Markdown Datei mit der Endung .md gespeichert.

• Es empfiehlt sich mit Hermes auch festzulegen wo das Wiki gespeichert werden soll.

• Dann muss man nur noch sagen, lies es ein und lege los.

• Wenige Minuten später ist das Wiki fertig.

• Es werden aber beim ersten Durchlauf noch Fehler drin sein.

KI arbeitet anders als Software

LLMs arbeiten probabilitisch.

Das bedeutet: Wenn Du ihnen mehrmals den gleichen Befehl gibst, kommt jedesmal ein anderes Ergebnis.

Warum das so ist, dazu gibt es bereits viele Artikel. Es hat was mit mathematisch errechneten Wahrscheinlichkeiten zu tun. Man nennt es probabilistisch.

Für die KI Tranformation in Unternehmen heißt das: Man muss sich erst einmal daran gewöhnen.

Jahrelang hat man gelernt: Input → Processing → Output

Und nun ist es: Input → KI macht irgendwas → Output immer etwas anders

Warum nimmt man dann KI?

Die Stärke von KI ist es riesengroße Mengen an Text, Bildern und anderen Formaten in rasender Geschwindigkeit zu verarbeiten und daraus etwas Brauchbares zu generieren.

Oft brauchst Du aber was, was nach strengen Regeln arbeitet und korrekte Ergebnisse liefert. Das nennt man deterministisch. Dann nimmst Du Software.

Software wird es weiterhin geben.

Die Stärke von Software ist es: immer die gleichen Regeln anzuwenden und damit auch immer die gewünschten Ergebnisse liefern.

Für Wikierstellung KI nehmen

Der Use Case Wiki erstellen, wäre mit Software kaum umzusetzen, vor allem nicht, wenn Du große Recherchen machen würdest. Du müsstest vorab wissen wie das Recherchematerial aussieht, wie es verarbeitet werden soll etc. und das erstellen dieser Software wäre auch zeitaufwändig.

Der KI macht das nix aus, die macht das einfach und zwar schnell.

Ein paar Minuten nachdem Du Hermes die Instruktion gegeben hast einen Wiki zu EU AI Act zu erstellen, hast Du dann vielleicht sowas:

Wie schaut man den Wiki an?

Markdown Dateien sind nicht besonders schön zu lesen.

Als UI kannst Du Obsidian nehmen. Einfach runterladen:

https://obsidian.md/

Ich hatte erst versucht die Website von Obsidian zu lesen und zu verstehen, aber solche Seiten strengen mich an. Daher habe ich es gelassen. Ich habe es einach heruntergeladen und benutzt.

Es sieht dann so aus:

Mit Obsidian navigierst Du durch die Ordner und Dateien und klickst Dich von Seite zu Seite.

Du kannst auch direkt darin editieren.

Extrem praktisch.

Obsidian kann noch mehr, einfach ausprobieren. Ich will ja keine ausführlichen Tutorials schreiben, sondern zum lernen animieren und später Prinzipien ableiten.

Ein nettes Gimmick will ich aber noch zeigen. Der Knowledge Graph. Aber Obacht! Es ist kein ECHTER Knowledge Graph. Ein echter Knowledge Graph hätte zwischen den Knoten noch Beziehungsarten.

Das hier ist einfach nur eine vernetzte Visualisierung aller vorhandenen Wikiseiten:

Das schicke daran ist, wenn Du einen Knoten anklickst, sieht man farbig die verlinkten Seiten:

Ich kann mir vorstellen, dass mir das später sehr hilfreich sein wird.

Wie oben erwähnt, seit darauf gefasst, dass der erste Durchlauf nicht fehlerfrei sein wird. Mach dann mit Hermes eine QS. Sage Hermes, was zu beachten ist und dann legt er nochmal los.

Für große Recherchen und viel Material würde man aber ein Multi-Agenten-Setup bauen. Da bin ich gerade am Experimentieren wie das geht. Wenn es einer schon gemacht hat, bitte bei mir melden!

Weiter verwerten der Markdown Dateien

Die Markdown Dateien sind ideal für LLMs: sie sind ziemlich “roh”, bestehen aus nur wenigen Zeichen und haben trotzdem Struktur. Genau sowas lieben LLMs.

Sie müssen beim Einlesen von Markdown Dateien nicht so viele Zeichen verarbeiten und verbrauchen daher weniger Token, als wenn sie jedesmal PDFs, Word oder HTML Seiten lesen müssten.

Mit den Markdown Dateien kannst Du dann alles mögliche andere machen. Der Agent kann Vorschläge machen, er kann daraus aber auch Web Apps bauen, Präsentationen oder Templates erstellen, was auch immer Du benötigst.

Wann man KEIN Markdown verwendet

Markdown ist jetzt nicht das Format für alles.

Merksatz:

• Ist das, was ich haben will, eher ein Dokument oder ein MindMap? → Markdown

• Ist das, was ich haben will, eher wie eine Tabelle, weil ich etwas sortieren, filtern oder berechnen will? → Datenbank
  
  Es folgen noch Artikel was mit einem KI-Agenten und ner Datenbank machen kann, weil ich das selbst auch brauchen werde. Aber heute erstmal Basiswissen.
  

Woraus besteht der KI-Agent

Sehr erleuchtend fand ich zu verstehen, dass der KI-Agent einfach nur ein paar Ordner mit Dateien ist, die auf meiner Hardware liegen, hier ein Auszug:

Und ein LLM ist im Grunde auch nur Ordner und Dateien, hier mal ein Bild aus dem Internet:

Also ein Agent (Ordner und Dateien auf Deiner Hardware) verbindet sich mit einem LLM (wieder Dateien entweder lokal oder Cloud).

Relativ unspektakulär.

Alles, was agentische KI dann erst kompliziert und komplex macht, ist das ganze Software Engineering drum herum, evtl. noch Infrastruktur.

Also die Fragen:

• Wie kann man mehrere Agenten parallel laufen lassen?

• Wie stellt man sicher, dass sie in der richtigen Reihenfolge das richtige tun?

Technisch geschen sind es noch viel mehr Fragen. Mehr dazu in späteren Artikeln.

Worauf ich nur hier hinaus will: Das sind Software Engineering Fragen. Dafür braucht man keinen Doktortitel in Data Science. Da sind klasse Software Engineering Fragen und das ist alles machbar.

Auf die organisatorischen Fragen, die Arbeitsweisen, die Governance, die Daten, darauf gehe ich auch noch in späteren Artikeln ein.

Für heute will ich nur mal gesagt haben:

Für die allermeisten Anwendungsfälle, in denen man lediglich vorhandene Modelle benutzt, kann mit dem Wissen, was man schon hat über Software Engineering, Data Modelling & Engineering, die eigenen Definitionen, die eigenen Use Cases, die eigenen Prozesse usw. schon mal anfangen zu vertsehen und zu lernen.

KI Transformation wird eine lange Lernreise. Aber zum Anfangen benötigt man erstmal nur ganz viel Basiswissen.

Alles weitere muss dann nach und nach erarbeitet werden, denn es sind noch nicht so viele Firmen vollständig “AI first”, also stehen wir alle am Anfang.

Vielleicht seht Ihr schon durch diesen Artikel: Man lernt am besten durch Ausprobieren.

Was beduetet das für die KI Transformation

Meine Erkenntnis nach diesem kleinen Experiment: die ganze KI Debatte, so interessant sie auch sein mag, bringt einen in der Praxis nicht weiter.

In meinen Augen ist es am besten jetzt schon anzufangen mit kleinen Experimenten wie diesen, und zu lernen.

Meine Empfehlungen an Unternehmen:

• Kauft Euch ein paar Mac Minis oder stellt Euch einen Server hin, installiert den Hermes KI Agenten lokal

• Verwendet Modelle, die in Eurer Branche zulässig sind, EU-gehostet oder lokal

• Fragt die gesamte Belegschaft wer denn Spaß daran hätte ein paar Experimente zu machen, AUCH Leute, mit nicht-technischem Background

• Lasst ein paar Leute regelmäßig während der Arbeitszeit ausprobieren

• Besprecht regelmäßig gemeinsam die Learnings

Warum sage ich das

Wie der Artikel und der vorige - und die Artikel noch vieler anderer Substack Autoren zeigen - ist KI kein Geheimwissen.

Das Wissen ist jedem zugänglich. Man muss keinen Doktortitel haben um KI anzuwenden.

Fast alle KI-Berater fangen auch erst gerade an. Die wenigsten sind seit Jahren Experten in KI.

Und selbst wenn ein KI-Berater Erfahrung hat, ist es nicht gesagt, dass er Dein Unternehmen und Deine Prozesse alle schon mal woanders genau so gesehen hat.

Ich hab in fast 40 Organisationen gearbeitet (zum einen weil ich schon älter und zum anderen weil ich selbständig bin) und jede Organisation ist anders. Jede.

Es gibt Muster und Prinzipien, die kann man überall anwenden. Aber die Details muss man überall neu überlegen.

Das bedeutet, der beste KI-Berater muss auch erstmal sehen, wie man es bei Euch konkret umsetzt.

Jedes Unternehmen hat zig Tools, Daten, Systeme, Prozesse etc. Die Herausforderung ist, da irgendwie KI anzuflanschen. Und das muss in jedem Use Case neu erarbeitet werden.

Fangt doch schon mal an mit Lernen und Experimentieren, denn ich bin davon überzeugt, es kommen einem dann die Ideen.

Vielleicht könnt Ihr auf die Hardware noch Testdaten oder Testsysteme installieren.

Überlegt welche Prozesse oder Abläufe bei Euch am nervigsten sind, fragt Hermes, was man vereinfachen könnte und fangt an zu verstehen, was der KI-Agent kann. Wenn das auf lokaler separater Hardware mit lokalen Modellen geschieht, geht überhaupt nichts kaputt.

Aber: Ihr fangt an zu lernen und Ihr wisst welche Fragen Ihr einem KI-Berater stellen wollt.

Außerdem macht es Spaß 🙂

Schön und gut, aber wie skaliert das?

Vielleicht bist Du schon zehn Schritte weiter und hast richtige Probleme im Unternehmen KI zu skalieren.

Meine Erfahrung sagt:

Ok, es gibt vielleicht für Standard Use Cases bereits fertige Lösungen.

Vielleicht gibt es in Zukunft auch noch mehr out-of-the-box Lösungen.

Aber für ein Unternehmen mit zig Tools und komplexer Systemlandschaft mit Legacy gibt es keine Abkürzung.

Es führt kein Weg dran vorbei zu lernen und zu verstehen, wo man ansetzt und wie man es dann skaliert.

Alle, die schon weiter sind in der KI Transformation berichten die gleichen Erfahrungen. Klein anfangen, einen Use Case stabil nach Produktion bringen, dann weiter.

Jeder, der etwas anderes behauptet, ist nicht seriös.

Meine Überzeugung

Mein Ziel ist es so viel Wissen und Verständnis wie möglich weiter zu geben, weil ich die Erfahrung gemacht habe, dass die Kunden, die sich schon in ein Thema eingearbeit haben, viel mehr Beratungsleistung von mir wollen als die Kunden, die sagen, der Berater soll es alleine richten.

Je mehr sich die Firmen mit KI auseindersetzen, desto mehr Ideen und Potentiale entstehen.

Außerdem ist es dann auch viel einfacher etwas miteinander zu besprechen. Der Kunde hat dann schon konkrete Fragen und man hat ein gemeinsames Grundverständnis.

Wie geht’s weiter?

Neben Artikeln wie diesen wo man selbst was ausprobieren kann, decke ich noch viele weitere Themen ab, die mit einer KI Transformation zu tun haben. Hier eine Übersicht, was ich noch schreiben will.

Daher schaut wieder mal vorbei, hinterlasst ein Like, kommentiert oder empfehlt mich weiter.

Vielen Dank und ich freue mich auf den Austausch!

this article is modular, meaning you can jump straight to the headings that interest you and simply ignore anything that does not apply to you.

Always start with Why

Why do I even want an autonomous AI agent?

Over the course of my professional life, I have accumulated a great deal of knowledge and experience in my head that is written down nowhere and for which no books exist.

This knowledge is extremely valuable, especially when it comes to AI transformations.

The thought of writing it all down exhausts me. It overwhelms me cognitively and emotionally because it is because the sheer volume is overwhelming, and because I do not even know where to start.

This is why my first use case will be:

An AI agent shall independently write down my knowledge and experience in a wiki, and in the background it shall create a connected knowledge net.

The AI agent shall interview me, and when I go for a walk, I want to simply share my thoughts and talk with the AI agent via my phone, and it shall make something out of them.

The wiki serves multiple purposes:

• It becomes clear to me what the structure of my domain knowledge actually is

• The AI agent learns who I am and what I know

• My knowledge is neatly organized and clickable

• The wiki and the connected knowledge net in the background serve the AI agent as a “map” that it can “wander” through

• It serves as the foundation for digital products for my clients: instead of slides, I can have the AI agent create interactive web apps or online trainings based on the wiki

• It also serves the AI agent as context and thus saves time and costs. If I were to load all my knowledge completely into every new request (into every new chat), the AI agent would be very slow and consume many tokens. Through the wiki, it can navigate to the relevant parts

• The wiki is infinitely expandable and might even inspire me to come up with entirely different ideas

This is what a chat with Hermes looks like:

Based on my professional experience, the following points were important to me regarding AI agents

My setup must fulfill the following points:

Understanding and Learning

I want to understand what an AI agent consists of. I do not need to be able to develop LLMs myself, but I want to broadly understand what physical components an AI agent has, because in my experience it leads to a great many misunderstandings when, as a consultant, you do not understand what teams are actually doing. I was a software engineer myself once, and my technical understanding has helped me many times in my work as a consultant.

Long-term use while staying flexible

I want to use and build this AI agent long-term while remaining maximally flexible and independent in case a new technology becomes useful for me.

This means the setup must be modular and flexible. I want no vendor lock-in and I also do not want difficult migrations ahead of me when new technology becomes available.

That is why it was clear to me: hardware, model, and the “harness” of the AI agent must be separate. I want control over how I use the technology.

Sovereignty and Data Privacy

In German AI Sovereignty and Data Privacy is a mainstream topic. I want as much sovereignty and as much data privacy as possible. That is why it was clear from the start that I want to use open source wherever possible. I am starting small and may change my stack to fully local in the long run.

Low Cost

And I want to spend only a very small budget per month. Hermes is free. You can run models locally on your own hardware, which means no subscription or token costs. Or you choose a very affordable subscription.

My preliminary choice:

• Mac Mini as separate hardware on which the AI agent runs

• Hermes as an open source framework for an autonomous AI agent

• Ollama Cloud Subscription for models at 20 euros per month

Guide

Here is the guide. You can jump to the headings that apply to you.

Foreword

I am the type who never reads user manuals or instructions. I always just start and learn through experience and mistakes.

I made quite a few mistakes too, and in the end I reinstalled the Hermes agent several times. Now I understand pretty well what you need to watch out for.

Hardware Recommendations

I recommend separate hardware for the AI agent for several reasons:

• If there is nothing important on the separate hardware, the AI agent cannot change or delete anything important either. As long as you are still in the learning phase, it is, in my view, important to experiment without too many inhibitions.

• If the AI agent is used for professional purposes, it is on separate hardware, separated from the private domain.

• If the AI agent works around the clock, you do not get in each other’s way.

• If you accidentally make mistakes during installation, as I did, you can simply wipe the machine and no damage has been done.

• If you are thinking long-term about having a local model, the right hardware is a prerequisite for that.

I bought a Mac Mini because it meets my requirements and because it does not take up much space. My workspace at home is very small.

Preparation

If you cannot remember passwords and also have no other secure digital storage for passwords, it is advisable to have paper and pencil ready.

Setting Up the Mac

I did not take screenshots here because setting up a Mac is very easy, even if you have never used a Mac before.

Small tip: The @ symbol on a Mac is Alt + L

Increasing Security on the Mac

Once the Mac Mini is set up, you can take care of the following small things to increase security.

Fully update macOS

• Start the Mac Mini and log in to the administrator account.

• Open the Apple menu in the top left corner.

• Click on System Settings.

• Click on General on the left.

• Click on Software Update on the right. Install all updates and enable automatic updates.

Enable FileVault

• Stay in System Settings.

• Click on Privacy & Security on the left.

• Scroll down to FileVault. Click on FileVault. Enable FileVault.

Enable Firewall and Stealth Mode

• Open System Settings.

• Click on Network on the left.

• Click on Firewall on the right. Enable the Firewall.

• Then click on Options in the same area. Enable Stealth Mode.

Disable Remote Login and other sharing services

• Open System Settings.

• Click on General on the left.

• Click on Sharing on the right.

• Look for Remote Login (or Remote Management). It must be turned off.

• If other services are enabled in Sharing that you do not really need, turn them off as well. These include, for example, File Sharing or Screen Sharing. For this Mac Mini, as little as possible should be reachable from the outside.

Create a second user account just for Hermes

This is really highly recommended!

• You stay in the administrator account. Open System Settings.

• Click on Users & Groups.

• Click on Add User.

• Choose Standard as the account type. Give the account a clear name. Remember the account name.

• Then log out of the administrator account (via the Apple symbol, at the very bottom of the menu) and log in to the new Hermes standard account.

Where I was unsure is whether the account for Hermes also needs a different Apple account. If someone with knowledge on this topic reads this article, please do comment!

Switch to the Hermes account

From now on, you do almost everything in the Hermes account. You only need the admin account when macOS asks for a password or when you need to change something on the system itself.

Which Model, meaning LLM, should I choose?!?

There are very many models and also different ways to connect an AI agent to a model.

I do not want to go into all of them, but rather describe just the case where you have no idea what you want and no idea how it works.

The simplest option for me to start with

I simply created a free subscription at Nous Portal. This was the easiest route because during the Hermes installation, Nous Portal is available as a selection and Hermes automatically connects to Nous Portal if you are already logged into Nous Portal. It does not get any easier than this.

You can then tell Hermes via chat which other model it should connect to.

This has the advantage that you do not have to deal with how it works technically at all. Hermes simply takes care of it for you.

Installing Hermes

• Open a browser (on Mac, that is Safari)

• Enter “Hermes AI Agent” in a search engine

• Go to the Hermes website

• Right in the middle is the install command to copy

• Open a Terminal

• If you do not know where the Terminal is on a Mac, open Finder and go to Applications → Utilities, and there you will find the Terminal

• Once you have opened the Terminal, it will from now on always be visible in the bar at the bottom

• Copy the command from the website directly into the Terminal (preferably via right-click → Paste, because Ctrl + V does not work on Mac)

Screenshots

Here are a few screenshots. I do not have all of them because the rest is either self-explanatory or different for everyone.

The install command:

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Terminal

Entering the install command in the Terminal

The installation menu

I chose Quick Setup first and more or less always said “yes” and “next.”

You can change everything afterwards, with the help of Hermes, by chatting with it.

Model selection

As I said, I initially chose Nous Portal because it is the simplest and costs nothing. You can always change it afterwards.

If you are more technically experienced, you can also choose something else right away.

Hermes Home Screen

This is what it looks like when you have successfully installed Hermes!

This is the chat window of Hermes. You can always start it with “Hermes chat” in a terminal window:

That’s it!

Really?? Yes, really!!

What can go wrong and what to do about it

Docker, when you do not really know Docker

When installing Hermes, I initially started by setting up a Docker container to install Hermes inside it. I do know what Docker is and what it does, but I am not a DevOps engineer, meaning I quickly reached my limits.

Every additional communication channel with Hermes, every additional connection from Hermes to tools outside the container, requires “a way out” of the container, and I do not yet know how that works. Once I do, I might set one up again.

That is why I wiped the Hermes user account and started over from scratch.

Hermes suddenly “without a brain”

Once, do not ask me exactly how it happened, my Hermes suddenly had “no brain” anymore, meaning no model. When switching from the Nous subscription to the Ollama subscription, Hermes had apparently gotten some detail wrong.

As soon as you switch from one model to another, the switch only takes effect when you open a new terminal window. If something went wrong during setup beforehand, you are suddenly unable to act in the new terminal window because Hermes “can no longer think.”

But this is also not a problem. Here is what you do:

• Open a new terminal window

• Enter: Hermes setup

• Choose the Nous subscription and Hermes can think again.

• Once Hermes can think again, you “train“ it. This means: you do not just say “switch the model,” you also say “Test thoroughly beforehand whether the connection to the model works. Ask the model what the capital of Germany is and wait for the answer.”

Chat in the Terminal becomes slow

You can open a new terminal window at any time and start a new conversation with “Hermes chat.”

Do Not Be Afraid of the Terminal

If you are professionally more of a user than a pure techie, a terminal might feel somewhat intimidating.

But let me tell you: it is not that bad. It is the same principle as when you chat in a browser with an LLM, only the look is different.

It reminded me of my school days. In the computer science club in 1994, we also still worked with terminals in the computer room. Back then I wanted to become a hacker, and communicating with Hermes was therefore quite fun in a nostalgic sense 🙂

On the Topic of Security

The topic of security gave me a lot of headaches during the preliminary considerations. I do not know whether I have fully grasped or understood everything yet. Here is an overview of the insights I have gained so far.

Please help me explore this topic in more depth, because I am convinced that the better we understand it, the more we can use AI. If we are too afraid, the debate becomes too “mystical” and we experiment too little. But we should not be too reckless either. That is why we need a detailed examination.

That’s it!

Once you have managed to chat with Hermes, you can discuss all further questions directly with Hermes.

And what else??

Everything else you can do with Hermes will follow in many more articles, so I would be happy if you stop by again 🙂

Your opinion!

Please also comment right here if you have important pointers for me or questions that I did not cover. I look forward to the exchange!

this article will soon be available in English. This is the German version for my German community.

Lieber Leser,

dieser Artikel ist modular aufgebaut, d.h. Du kannst auch gleich zu den Überschriften springen, die Dich interessieren und alles, was Dich nicht betrifft, einfach ignorieren.

Always start with Why

Warum will ich überhaupt einen autonomen KI-Agenten?

Ich habe im Laufe meines Beruflebens sehr viel Wissen und Erfahrung in meinem Kopf angehäuft, dass nirgends aufgeschrieben ist und zu dem es auch keine Bücher gibt.

Dieses Wissen ist extrem wertvoll, vor allem wenn es um KI Transformationen geht.

Der Gedanke nun alles aufzuschreiben ermüdet mich. Das überfordert mich kognitiv und emotional, weil es so ein riesiger Berg ist, und weil ich gar nicht weiß wo ich anfangen soll.

Daher wird mein erster Use Case dieser sein:

Ein KI Agent soll selbständig mein Wissen und meine Erfahrung aufschreiben und zwar in einem Wiki und im Hintergrund soll er ein verknüpftes Wissensnetz anfertigen.

Der KI Agent soll mich interviewen, und wenn ich Spazieren gehe, will ich meine Gedanken einfach über mein Handy dem KI Agenten mitteilen und er soll was daraus machen.

Das Wiki dient für mehrere Zwecke:

• Mir selbst wird klar, was die Struktur meines Domänenwissens eigentlich ist

• Der KI Agent lernt wer ich bin und was ich weiß

• Mein Wissen ist schön sortiert und klickbar

• Das Wiki und das verknüpfte Wissensnetz im Hintergund dient dem KI Agenten als “Landkarte”, er kann durch das Netz “wandern”

• Es dient als Grundlage für digitale Produkte für meine Kunden: anstelle von Folien kann ich mit dem KI Agenten anhand des Wikis interaktive Web Apps oder Online Trainings erstellen lassen

• Es dient dem KI Agenten auch als Kontext und spart somit Zeit und Kosten. Würde ich all mein Wissen jedesmal vollständig in die neue Anfrage (in den neuen Chat) laden, wäre der KI Agent sehr langsam und würde viele Tokens verbrauchen. Durch das Wiki kann er zu den relevanten Stellen navigieren.

• Das Wiki ist beliebig erweiterbar und inspiriert mich vielleicht noch zu ganz anderen Ideen

So sieht ein Chat mit Hermes aus:

Aufgrund meiner Berufserfahrung waren mir folgende Punkte bei KI Agenten wichtig

Mein Setup muss folgende Punkte erfüllen:

Verstehen und Lernen

Ich will verstehen aus was ein KI Agent besteht. Ich muss nicht selbst in der Lage sein LLMs zu entwickeln, aber ich will im Großen und Ganzen verstehen welche physischen Bestandteile ein KI Agent hat, da es meiner Erfahrung nach zu sehr vielen Missverständnissen führt, wenn man als Berater nicht versteht, was Teams eigentlich tun. Ich war selbst mal Software Engineer und mein technisches Verständnis hat mir schon oft geholfen in meiner Arbeit als Berater.

Langfristig nutzen aber flexibel bleiben

Ich will diesen KI Agenten langfristig nutzen und aufbauen und aber trotzdem maximal flexibel und unabhängig sein, falls es eine neue Technologie gibt, die nützlich für mich ist.

Das bedeutet, der Aufbau muss modular und flexibel sein. Ich will keinen Vendor lock-in und ich will auch keine schwierigen Migrationen vor mich haben, wenn neue Technologie verfügbar ist.

Daher war für mich klar: Hardware, Model und “Gerüst” des KI Agenten müssen separat sein. Ich will die Kontrolle darüber wie ich die Technologie nutze.

Souveränität und Datenschutz

Ich will so viel Souveränität und so viel Datenschutz wie möglich. Daher war von Anfang an klar, dass ich Open Source verwenden will wo es nur geht. Ich fange erstmal klein an und evtl. verändere ich meinen Stack langfristig auf voll lokal.

Kostengünstig

Und ich will nur ein ganz kleines Budget pro Monat ausgeben. Hermes ist kostenlos. Man kann Modelle lokal auf der eigenen Hardware betreiben, dann kostet es auch keine Subscription oder Tokens. Oder man wählt eine sehr günstige Subscription.

Meine vorläufige Wahl:

• Mac Mini als separate Hardware auf dem der KI Agent läuft

• Hermes als Open Source Framework für einen autonomen KI Agenten

• Ollama Cloud Subscription für Modelle für 20 Euro pro Monat

Anleitung

Hier nun die Anleitung. Man kann zu den Überschriften springen, die einen betreffen.

Vorwort

Ich bin der Typ, der nie Benutzerhandbücher oder Anleitungen liest. Ich fang immer erst mal an und lerne durch Erfahrung und Fehler.

Mir sind auch einige Fehler unterlaufen und am Ende habe ich den Hermes Agenten mehrmals neu installiert. Jetzt verstehe ich ziemlich gut, worauf man achten muss.

Empfehlungen zur Hardware

Ich empfehle eine separte Hardware für den KI Agenten aus mehreren Gründen:

• Wenn auf der separaten Hardware nichts Wichtiges drauf ist, kann der KI Agent auch nichts Wichtiges verändern oder löschen. So lange man noch in der Lernphase ist, ist es meiner Ansicht nach wichtig zu experimentieren und dabei nicht so viele Hemmungen zu haben.

• Wenn der KI Agent für berufliche Zwecke verwendet wird, ist er auf einer separaten Hardware getrennt vom privaten Bereich.

• Wenn der KI Agent rund um die Uhr arbeitet, kommt man sich nicht gegenseitig in die Quere.

• Wenn man beim Installieren - so wie ich - aus Versehen Fehler macht, kann man ganz einfach die Kiste wieder platt machen und es ist kein Schaden entstanden.

• Wenn man langfristig mit dem Gedanken spielt ein lokales Modell zu haben, ist die richtige Hardware eine Voraussetzung dafür.

Ich hab einen Mac Mini gekauft, weil er meine Anforderungen erfüllt und weil er auch nicht viel Platz einnimmt. Mein Arbeitsplatz zuhause ist sehr klein.

Vorbereitung

Wenn man sich Passwörter nicht merken kann und auch sonst keine sichere digitale Ablage für Passwörter hat, empfiehlt es sich Papier und Bleistift bereitlegen.

Einrichten Mac

Hier habe ich keine Screenshots gemacht, denn das Einrichten eines Macs ist sehr einfach, selbst wenn man zuvor nie Mac verwendet hat.

Kleiner Tipp: Das @ Zeichen ist beim Mac Alt + L

Sicherheit auf dem Mac erhöhen

Sobald der Mac Mini eingerichtet ist, kann man noch folgende kleinen Dinge erledigen, um die Sicherheit zu erhöhen.

macOS vollständig aktualisieren

• Starte den Mac Mini und melde dich im Administratorkonto an.

• Öffne oben links das Apple-Menü.

• Klicke auf Systemeinstellungen.

• Klicke links auf Allgemein.

• Klicke rechts auf Softwareupdate. Mache alle Updates und schalte automatische Updates ein.

FileVault einschalten

• Bleibe in den Systemeinstellungen.

• Klicke links auf Datenschutz & Sicherheit.

• Scrolle nach unten zu FileVault. Klicke auf FileVault. Schalte FileVault ein.

Firewall und Tarnmodus einschalten

• Öffne Systemeinstellungen.

• Klicke links auf Netzwerk.

• Klicke rechts auf Firewall. Schalte die Firewall ein.

• Klicke danach im gleichen Bereich auf Optionen. Aktiviere den Tarnmodus.

Remote Login und andere Freigaben ausschalten

• Öffne Systemeinstellungen.

• Klicke links auf Allgemein.

• Klicke rechts auf Freigaben.

• Suche dort nach Remote Login (oder Fernsteuerung). Es muss ausgeschaltet sein.

• Wenn in Freigaben andere Dienste eingeschaltet sind, die du nicht wirklich brauchst, lässt du sie ebenfalls aus. Dazu zählen zum Beispiel Dateifreigabe oder Bildschirmfreigabe. Für diesen Mac Mini soll möglichst wenig von außen erreichbar sein.

Zweites Benutzerkonto nur für Hermes anlegen

Das ist wirklich sehr empfehlenswert!

• Du bleibst im Administratorkonto. Öffne Systemeinstellungen.

• Klicke auf Benutzer:innen & Gruppen.

• Klicke auf Benutzer:in hinzufügen.

• Wähle als Kontotyp Standard. Gib dem Konto einen klaren Namen. Merke dir den Account-Namen.

• Melde dich danach vom Administratorkonto ab (über Apfel Symbol, ganz unten im Menü) und im neuen Hermes-Standardkonto an.

Wo ich mir unsicher war, ist, ob das Konto für Hermes auch ein anderes Apple Konto benötigt. Falls jemand mit Wissen zu diesem Thema diesen Artikel liest, bitte unbedingt kommentieren!

Wechsel ins Konto für Hermes

Ab jetzt machst du fast alles im Hermes-Konto. Das Admin-Konto brauchst du nur noch, wenn macOS nach einem Passwort fragt oder du etwas am System selbst ändern musst.

Welches Modell - also LLM - soll ich nehmen?!?

Es gibt sehr viele Modelle und jeweils auch unterschiedliche Arten wie man einen KI Agenten mit einem Modell verbindet.

Ich will nicht auf alle eingehen, sondern hier mal nur den Fall schildern, dass man gar nicht weiß, was man will und gar nicht weiß wie es geht.

Die allereinfachste Variante für mich für den Start

Ich hab einfach mal bei Nous Portal eine kostenlose Subscription gemacht. Das war deshalb der einfachste Weg, weil während der Hermes Installation Nous Portal als Auswahl zur Verfügung steht und Hermes sich autoamtisch mit Nous Portal verbindet, wenn man schon in Nous Portal eingeloggt ist. Einfacher geht es nicht.

Man kann im Anschluss Hermes per Chat mitteilen, mit welchem anderen Modell er sich verbinden soll.

Das hat den Vorteil, dass man sich überhaupt nicht damit beschäftigen muss wie das technisch geht, Hermes erldigt es einfach für einen.

Hermes installieren

• Öffne einen Browser (auf Mac ist das Safari)

• Gebe in einer Suchmaschine “Hermes AI Agent” ein (nicht KI, denn die Website von Hermes ist Englisch)

• Gehe dann auf die Website von Hermes

• Gleich in der Mitte ist der install Befehl zum kopieren

• Öffne ein Terminal

• Wenn Du nicht weißt wo ein Terminal auf dem Mac ist, öffnest Du den Finder und gehst zu Programme → Dienstprogramme und da ist dann das Terminal

• Sobald Du das Terminal einmal geöffnet hast, wird es ab sofort immer in der Leiste unten zu sehen sein

• Kopiere den Befehl von der Website direkt ins Terminal (am besten über Maustaste Rechtsklick → Einsetzen, denn Strg + v funktioniert auf dem Mac nicht)
  
  

Screenshots

Hier ein paar Screenshots. Ich habe nicht alles dabei, denn der Rest ist entweder selbsterklärend oder bei jedem unterschiedlich.

Der Install Befehl:

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Terminal

Installbefehl im Terminal eingeben

Das Menü der Installation

Ich hab erst mal Quick Setup genommen und mehr oder weniger immer “ja” und “weiter” gesagt.

Man kann im Nachgang alles nochmal ändern und zwar mit der Hilfe von Hermes, indem man mit ihm chattet.

Modellwahl

Hier habe ich wie gesagt erstmal Nous Portal genommen, weil es am allereinfachsten ist und nichts kostet. Man kann es hinterher immer noch ändern.

Wer technisch versierter ist, kann auch gleich etwas anderes wählen.

Startseite von Hermes

So sieht es aus, wenn Du Hermes erfolgreich installiert hast!

Das ist das Chatfenster von Hermes. Du kannst es immer mit “Hermes chat” in einem Terminalfenster starten:

Das war’s schon!

Wirklich?? Ja, wirklich!!

Was alles so schief gehen kann und was man dann macht

Docker, wenn man Docker nicht wirklich beherrscht

Bei der Installation von Hermes hab ich zunächst angefangen einen Docker Container aufzusetzen um darin Hermes zu installieren. Ich weiß zwar was Docker ist und was es macht, aber ich bin kein DevOps Engineer, d.h. ich kam schnell an meine Grenzen.

Jeder zusätzlicher Kommunikationskanal mit Hermes, jede zusätzliche Verbindung von Hermes zu Tools außerhalb des Containers, benötigen “einen Weg raus” aus dem Container und ich weiß noch nicht wie das geht. Sobald ich das weiß, errichte ich vielleicht wieder einen.

Deshalb hab ich das Benuzerkonto für Hermes einmal platt gemacht und wieder von vorne angefangen.

Hermes auf einmal “ohne Gehirn”

Einmal - fragt mich nicht wie es im Detail passiert ist - hatte mein Hermes auf einmal “kein Gehirn” mehr, also kein Modell. Beim Wechsel von der Nous Subscription zur Ollama Subscription hatte Hermes wohl irgendein Detail falsch gemacht.

Sobald man von einem Modell zum anderen wechselt, wird der Wechsel erst mit dem Öffnen eines neuen Terminalfensters wirksam. Wenn dann vorher beim Einrichten was fehlerhaft war, ist man im neuen Terminalfenster auf einmal handlungsunfähig, weil Hermes “nicht mehr denken kann”.

Aber auch das ist kein Problem. Du machst dann folgendes:

• Öffne eine neues Terminalfenster

• Gebe ein: Hermes setup

• Wähle die Nous Subscription und schon denkt Hermes wieder.

• Sobald Hermes wieder denken kann, “erziehst” du ihn.
  Das bedeutet: Du sagst nicht nur “wechsel das Modell”, sondern Du sagst auch “Teste vorab ausführlich ob die Verbindung zu Modell funktioniert. Frage das Modell, was die Hauptstadt von Deutschland ist und warte auf die Antwort”.

Chat im Terminal wird langsam

Du kannst jederzeit ein neues Terminalfenster öffnen und mit “Hermes chat” ein neues Gespräch anfangen.

Keine Angst vor Terminal

Wenn man beruflich eher Anwender als reiner Techie ist, mag ein Terminal irgendwie abschreckend sein.

Aber ich will Euch sagen: Es ist halb so wild. Es ist das gleiche Prinzip als wie wenn Du einen Chat im Browser mit einem LLM führst, nur dass die Optik eine andere ist.

Er erinnerte mich an meine Schulzeit. In der Informatik AG im Jahr 1994 arbeiteten wir im Computerraum auch mit noch mit Terminals. Damals wollte ich Hacker werden und die Kommunikation mit Hermes war daher in einem nostalgischen Sinne ziemlich spaßig 🙂

Zum Thema Sicherheit

Das Thema Sicherheit hat mir in den Vorüberlegungen viele Kopfschmerzen bereitet. Ich weiß nicht, ob ich schon alles durchdrungen oder verstanden habe. Hier einmal eine Übersicht, was ich bisher an Erkenntnissen gewonnen habe.

Bitte helft mit das Thema tiefer zu legen, denn ich bin davon überzeugt, je besser wir das verstehen, desto mehr können wir KI nutzen. Wenn man zu viel Angst hat, wird die Debatte zu “mystisch” und man experimentiert zu wenig. Zu leichtsinnig sollte man auch nicht sein. Daher brauchen wir eine detaillierte Betrachtung.

So, das war’s schon!

Sobald Du es geschafft hast mit Hermes zu chatten, kannst Du alle weiteren Fragen direkt mit Hermes besprechen.

Und sonst??

Alles, was man sonst noch so mit Hermes machen kann, folgt in vielen weiteren Artikeln, daher würde ich mich freuen, wenn Du wieder mal hier reinschaust 🙂

Eure Meinung!

Bitte kommentiere auch direkt hier, falls Du wichtige Hinweise für mich hast oder Fragen, auf die ich nicht eingegangen bin. Ich freue mich auf den Austausch!

Dear reader,

this is an overview what this Substack is about. I write for those who want to proactivley shape AI transformations.

There are quite some topics I want to cover and I won’t limit it to just one topic. Maybe I will add or remove topics in future.

Some are available in English and German.

I won’t publish weekly or regularly. There will be a long social media summer break, too. Digital detox is important for a healthy life.

The articles are free. They show how I work and think.

Topics

1. AI Transformation

2. Use Cases and real world examples

3. Workflows

4. AI Agent Example

5. Architecture layers of agentic AI stacks

6. How we think about people

7. Leadership

8. Teamwork

9. Philosophical Thoughts

10. Methods

11. Culture
    

1. AI Transformation

This article is a collaborative article with a VP Finance Data & AI Office of a large US bank. What really made me happy was, that my experience of transformation is very much in sync with her experience of transformation.:

As of now, this is my understanding of AI transformation:

AI transformation - my point of view

KI Transformation - meine Sicht

2. Use Cases

In this section I explain the use cases I built myself. My first use case was building a personal knowledge net, in German called “Luhmannscher Zettelkasten”.

Soon I will publish a collaborative article with a lawyer for EU AI Act where we look at another use case of mine and which laws are affected.

Another topic I want to cover is, how to make your own website bookable for other AI agents.

Many more to come!

Articles:

• English: Personal knowledge net

• Deutsch: Persönliches Wissensnetz

3. Workflows

Consulting on AI transformation or organizational design must understand:

• what a workflow actually is

• where to start with AI agents first

• how to optimize this step by step

• according to which criteria to optimize the workflow

  • simplify it

  • customer oriented

  • outcome oriented

  • in the tension between speed, cost, quality

• what this means technically in terms of AI:

  • which model for what,

  • frontier or local,

  • where only automation, where reasoning,

  • which data, which context, in which order is given to the AI agent,

  • who can even figure out which context is relevant at which point,

  • how to prepare the data

  • and how to digitize it (no, not a process map on a Miro board),

  • how AI can help at every step,

  • who then brings it into the runtime environment of the AI agent (data and software engineering),

  • how it is persisted, versioned etc.

• how to set up teams and leadership structures along the workflow

• how to implement incentivization along the workflow

• how to start the change in ways of working small and then scale it without burning millions

• how to create a learning cadence to become a learning organization

Which articles I will publish:

This will be a whole series of articles. I will focus on business workflows.

4. AI Agent example

I use a local open source AI Agent called Hermes.

You can run it with a local model or with a decent cloud subscription.

Articles:

• Step by step guide on how to install and build an AI agent like mine, in English

• Installationsanleitung auf Deutsch

5. Architecture layers of agentic AI stacks

Understanding the layers of agentic AI stacks and the different types of agentic AI stacks is the basis for developing about the operating model.

6. How we think about people

How we think about people influences everything:

• how we cut teams

• how we define leadership roles

• who we hire

• how we define the way of working

• how we design the organization

It all starts in the head, with the mindset.

And it is quite different from country to country, from culture to culture, from organization to organization!

What this means for AI transformation or organizational design

Your transformation will be a nightmare when you think that you or others are more clever then the rest. People will block, they will resist, you miss the best ideas, you prevent real collaboration with the wrong mindset.

Which articles I will publish:

There will be many articles on this. If we do not thoroughly examine this topic, we will unconsciously go down paths that will make our work and our lives harder later on.

7. Leadership

Leadership will change radically through AI.

Have you been:

• in situations where highly qualified engineers were simply frustrated, because a lot of money was burnt for very little outcome

• in situations where all kinds of unnecessary and avoidable conflicts arose

• in situations where workflows and processes became too complicated

• in situations where hours were spent talking about unimportant things and not at all about important things

• in situations where you could fill a room with over 30 people who want to discuss decisions and nobody in the room actually is accountable for the consequences of the decisions

• in situations that felt like group therapy, where nobody was really mentally ill and most people wondered what they had done wrong in their career to end up here (ok that is perhaps a very German perspective)

What this means for AI transformation or organizational design

Leadership and all leadership consultants need to reposition themselves. The old recipes will only partially survive.

• AI is so fast that people are not able to hide bad leadership anymore

• AI is so fast that people are not able to cover anymore what bad leadership missed

• AI agents are in a way more like humans then like machine, which makes good leadership a prerequisite

• AI makes new business possible and needs multiple departments for this, so the old leadership structure in functions breaks

• AI makes bottlenecks in complicated processes and workflows visible, so the question comes up: does any leader feel responsible for the end-2-end-process?

• AI can execute, but who owns the decision and the consequences?
  

Articles:

These articles are based on my experience in previous transformations:

Performance comes from Boundaries

More to come!

8. Teamwork

Finally teamwork & culture.

Teamwork needs to be redefined:

• What is a team

• Who is on the team

• How does teamwork with people and AI agents work

• What is true teamwork, what are practical examples and how can you learn it

• and what are just empty phrases

The AI transformation will be a team sport. At a large tech expo in Frankfurt there will be a keynote from professional soccer players and what that means for AI transformation. European Football is very important in Germany, I use many metaphors from soccer.

But you can also use other sports.

What this means for AI transformation or organizational design

Your AI transformation will be much easier when you understand how culture can support you in a very practical way.

Which articles I will publish:

More detailed examples of how to establish culture with simple means. I already published one, but I will cover one topic per article in the future.

9. Philosophical Thoughts

I think that some philosophical thoughts will help us in work and in AI transformations.

In this section I will also curate articles from other authors that I like.

This one did help a lot during my career:

10. Methods

Methods are actually my area of expertise. This section will be filled up over time.

Simplify your AI life:

• German

• English

11. Culture

Culture needs to be understood:

• What are the elements of a positive culture

• How can you implement a culture

• How can you keep it alive

Culture eats strategy for breakfast. We all know that. But not many of us know how to make culture happen.

This one is based on analyzing my own folk culture:

Many articles will follow and I hope that you all join the discussion, because this Substack is meant to become an exchange that moves us all forward.

I look forward to your comments!

Yours, Bianca

In this article I lay out a system that works well in my experience. I have seen it in practice in several organizations. It was very successful and people liked it, it was motivating and also kind of cool. It also works in large enterprises with a lot of complexity and legacy. In one such enterprise I was part of the leadership team (three of us) and we were responsible for seven teams.

Much of what I am about to describe is commonly known. Some of it I developed myself, some of it has been known for years. It is a mix of both. I keep meeting people for whom all of this is new, hence this article.

Think first, then act

In this article I try to present and explain principles. It is important not to copy the ideas and examples one by one.

Every organization is different and every organization has different people. And then there is the market, the customers, the outside world, the available capital, partner companies, unions, affiliated institutions, laws, regulations, there are so many different factors that force you to make trade-offs every day.

Engage with the principles and decide case by case specifically whether and to what extent you can and want to apply them.

If after reading this article you are inspired to implement it, talk openly with your teams about what you want to implement, what you intentionally do differently or not at all. We are all adults. Everyone understands that reality is messy and no one will have a problem with that.

Full transparency

Even if you consciously reject something, everyone will accept it more than if you say nothing about it at all.

I have been able to observe this often in agile transformations. When a leader says, we are doing agile now, and then everything that is agile was rejected and only a piece of Scrum theater was performed, when those leaders kept loudly saying how agile they are, there were three different reactions.

Most people think the leader is stupid. He does not get it. He is too dumb to understand what agile is.

Others think the leader is devious. He claims something externally while internally doing the exact opposite.

And some think: the leader is weak. He wants to be agile but does not dare to implement it properly.

But when the leader says: listen, it is not possible because… and gives reasons, no one has a problem with it.

Gut feeling explicitly welcome!

It is also ok to say that your gut feeling is against it and you cannot explain exactly why. People accept that.

That is mature and wise in my eyes.

What is immature and dangerous is buying some framework including a vendor and rolling it out without having your own opinion.

That is exactly why you are a leader. Because you carry the responsibility and people expect you to deal with difficult situations. Listen to your gut and work with others to figure out where the feeling comes from.

My experience is: when I have a weird feeling, at least two other people in the organization also have a weird feeling.

When I do not understand something, at least one other person does not understand it either.

That is why I am a big fan of leadership teams that discuss exactly these topics.

Fictional example

The fictional chocolate manufactory is developing a new vegan recipe. An AI model evaluates historical recipes, customer feedback and raw material data and suggests ingredient combinations that are promising in terms of taste. A small interdisciplinary team works in short cycles: every week a test batch is produced, tasted and evaluated. An AI agent handles parts of the procurement.

It is intentionally a somewhat far-fetched example. You can imagine what it means, but it is unrealistic enough that you cannot copy it one to one. That is on purpose. You should really think about what your end-2-end team looks like. Here is a guide.

Building an end-2-end team

The team of the chocolate manufacturer consists of Food Product Developer, Production Process Engineer, Machine Operator, Procurement / Raw Material Sourcing, Data Engineer, Machine Learning Engineer, DevOps Engineer, Quality and Regulatory Specialist, Sensory and Consumer Insights Specialist.

It consists of all the skills needed to produce a small sample of the new chocolate recipe and the chocolate itself. If someone from the chocolate industry is reading this and throwing their hands up, it is just an example to illustrate how to make cross-functional teams.

How do you do it in your organization?

Imagine the customer at one end and the deepest backend infrastructure at the other end. If you work in a large enterprise, there is so much in between that you do not even know what all of it is. Legacy stuff, strange manual processes, a piece of AI somewhere, data, who knows what. You do not have to pull all people from all departments into your team. It is enough to find people who are capable of driving changes in the surrounding systems.

But it has to be the full chain. Why? You need this focus and the view of the whole, because otherwise you will never figure out what you can cut and eliminate. Wherever functional teams are in place, there is always too much of a good thing. It is in the nature of things. Things grow, things expand, and they do so until you limit them. You need a meaningful focus and that is the customer.

If you are a SaaS with extremely many customers, then your end is someone who knows or understands the customer very well. If you are a pharmaceutical company, then your customer might be someone who knows all the sales representatives. If you are a machine manufacturer and your data and AI solution is used for machine maintenance, then your customer might be the machine operator.

You have to figure out who your customer is yourself. But be ambitious. Taking only the business colleague as customer is often too short of a stretch. Who does the business colleague have as a customer? Stretch yourself and be ambitious to make the stretch as long as possible towards the customer, but also be realistic. Start with what you can actually implement soon.

Brief note on central things like central data platforms or central infrastructure elements: there is always a central remainder that has to stay central. So do not be dogmatic. This is more about the principle. Very mature organizations are able to build their central functions in a way that teams can still work autonomously, by encapsulating them well and building them towards a service model. More on this in a later article.

The team must be small so that real and true teamwork emerges. Therefore multiple people in the team must cover multiple skills. Or have the willingness to learn them.

The team contains no managers or other general manager roles. Otherwise there will be too many people and no one should rest on the assumption that the manager will somehow manage it.

Make a colorfully mixed team. Everyone as equals.

Building a Leadership Team

Important: the direct supervisors of the team members must stay out of the teamwork. The team and the team members do not report to their direct supervisors. They report to the board, supported by a leadership team.

What is the leadership team?

Everyone who normally works around teams as a leader in various functions gets redistributed.

The people responsibility, the direct supervisor: this function must become maximally unimportant. This person should eventually in the long run only be responsible for administrative matters. Why? It is about breaking up career paths. Career growth no longer means climbing the org chart. It means taking on more responsibility and accountability along the value stream.

Therefore leadership is split into different dimensions:

To prevent extremes, each person gets two or more dimensions.

The leadership team meets regularly to discuss the results of the team and to clarify governance questions. Whoever is not there carries the decision of those present.

Making strategy actionable

The leadership team has to do preparatory work before the team starts. The more thorough the preparation, the better the result of the teamwork. It has to be thoroughly thought through how the strategy can become actionable.

In my experience, the best way to execute a strategy is this: formulate goals that are short and punchy, that everyone understands, that are easy to remember, not too many of them, start with maximum five. Then create measurable KPIs for each goal.

Present it to the teams, listen to their feedback, refine if necessary.

Then give the team autonomy, everything it needs and tight boundaries.

Give the team recognition for performance and be consistent in keeping commitments, including killing initiatives when the results show it was the wrong path.

The teams will become high performers and your strategy will be executed without a problem. People love challenges for the same reasons they love competitive sports.

Setting tight boundaries

The expectations for the team are: Every Friday a sample of the new vegan chocolate must be ready for tasting. In the review, a test customer, the leadership team and the board taste the chocolate. The chocolate is evaluated against the defined KPIs. Likewise, the other KPIs regarding budget, sustainability, availability of ingredients, scalability to mass production etc. are evaluated.

Afterwards, learnings are discussed and a new plan for the coming week is set up.

The team has six weeks to come up with a recipe that truly meets the requirements. If that is not achieved, the topic gets killed and you start again with new ideas later, or not. This is how you protect budgets. This is how you make sure you do not burn millions. Set a budget for learning. Decide what budget you are willing to burn with learning as the only outcome. That is the time within which something must be production ready.

Be consistent. If it does not work, it is over. Everyone has to know that from the beginning. And then it has to be followed through.

Starting again later is allowed, but with different parameters. Learn from the failures.

If it works, production gets rolled out in line.

Boundaries: the budget for ingredients is tight and must not be exceeded. Even if the teams ask you to. Changing the boundaries may only happen when it truly makes no sense the way it was defined. For this the entire team has to talk with the entire leadership team. Together.

You see, the leadership team has to have a lot of time available quite often. But because the team has much more freedom than before, many leadership tasks fall away. Therefore the leadership team can also comfortably do nothing and simply be on call. There are many professions where that is normal. I consider this very important. You have to be immediately ready when you are needed. A fully booked calendar is no longer an option.

Not delivering a sample is unacceptable. The team must be clear on what is at stake. The review has to be embarrassing for them if they deliver nothing. Why? They could have said something earlier. You know a few days before that there is a problem. Then maybe something could have been salvaged. If that happened and the chocolate is still inedible, then in the review the mistakes are analyzed together.

Managers do not interfere in the teamwork. The team resolves conflicts among themselves. Real teamwork can only emerge when the team goes through highs and lows together. If something really bad happens, the team will speak up.

Brief note on decision architecture

The previous sections were about what preparatory work has to be done before teams can even act autonomously.

You have to formulate and make explicitly available everything that you as a leadership team want, so that others can act autonomously without asking back. At the same time you have to regularly review the results with the teams, or you can trust that the team will speak up when something unexpected and not clarified yet occurs. Ideally, leaders are available daily on an ad hoc basis for exactly such cases.

You would have to proceed similarly if you want to set up a decision architecture for agentic AI. I will go into more detail in later articles, here just some remarks:

Test the principle with humans first. If my article contains a lot that is new to you, you have to first try with humans whether it even works in your organization.

And: reconsider the term architecture. The probability that you get everything right on the first try is low. You will have to constantly rework it, so it is constantly in motion, therefore the term architecture creates false expectations.

Ultimately: introducing a decision architecture into a system that is not yet lean and customer-oriented will only amplify the existing ineffective and inefficient ways of working. First set up the organization along the value stream properly and start with a single team.

Rethinking incentives

How people tick. It is actually quite simple. You want meaningful work where you grow beyond yourself. You want recognition, you want to be seen, you want to be part of something bigger, you want to move forward and achieve more. For me it starts with an event, a review, but completely different from what you are used to.

Back to our example: At the reviews the board is present: you are seen! Performance is recognized. As soon as the chocolate goes into series production, there is a bonus.

Whenever possible make reviews hybrid. The people who can be there in person should feel it. Those who are dialed in remotely should be able to see the review well.

The leadership team that supports the team is also seen.

Keep the review SHORT! Taste chocolate, have it evaluated against the criteria, discuss problems. Briefly check budget compliance and other important governance topics. Done.

The reviews should be COOL. Everyone standing, except the board. It should be the opposite of a 30-person workshop with PowerPoint slides. Think beforehand with a few insiders about what cool even means in your organization. This is about an event. The room should fit, the way it is moderated, the way the team presents itself, all of this influences whether this establishes itself as a way of working, or not.

It should feel like you would miss something if you did not go.

Therefore no blah blah, no slides. Taste chocolate, evaluate, hard criticism, no sugarcoating, no softening.

When there is success to celebrate you can always throw a party afterwards.

The review is open to everyone, meaning interested people can be present as listeners or observers. This is important because it makes other departments want something like this too. I have experienced this many times. When the review gets really cool, when truly extremely awesome things are shown that no one in the organization EVER thought could be built in such a short time, then everyone else wants that too. That is the best engine for a transformation. Success! And being seen having success! And having fun doing it! And feeling like the best version of yourself! That is unbeatable.

To keep it cool, problems have to be discussed openly and hard. People who have been working in corporate for a long time sense within the shortest time whether something is fake or serious. If you want change, it has to be serious. The chocolate has to be finished. The product has to be in production or close to production. No discussion, no softening of standards. That would be the ultimate trust and motivation killer.

The leadership team also receives recognition from the board.

Making career then means: more responsibility and accountability in these dimensions INSTEAD OF team lead, department head etc.

Dissolving teams that do not perform must be transparent and priced in from the beginning.

I have seen organizations that actually go through with this. It is of course still frustrating for the team members. But I compare it to the FIFA World Cup (I am from Germany, here this is an important event). If you do not make it past the group stage, you are out. It is incredibly frustrating for the players when they are eliminated, strong men cry, BUT: it does not diminish the fascination of the game and it does not in any way reduce the appeal of participating. Quite the opposite.

Learning journey

Once you have managed with one team to roll out a good solution into production and increased the KPIs, you are ready to scale the new way of working to multiple teams. The leadership team also becomes more solid and begins to understand how the organization would need to change. The org chart becomes less and less important.

However: organizations learn slowly, it will be a long learning journey. In this article I have started to present some principles and possibilities. It is just the beginning and it is far from over. We still have to learn how to set up hypotheses, define experiments, measure and learn. We still have to learn how to orchestrate learning in the organization, how to establish a cadence, where work in progress limits are needed, how to reduce waste and much more. Many more articles will follow.

All articles will always be free, I will not do paid subscriptions. But I am very happy when you recommend the articles, especially to those who need exactly this kind of support. I work for organizations and use my Substack articles to present my work. Feel free to reach out, I would love to hear from you!

You know those meetings. Tons of participants, workshops with colorful slides about strategy, half the room asleep or doom scrolling through social media or just quietly working on something else. I’m telling you, people are done with this. They’re annoyed and bored.

In the companies where I was present when large-scale change actually happened with great success – and I’m talking about Global Fortune 500 – something entirely different took place.

Have you ever been in a room or meetings full of people, where suddenly everyone stops what they’re doing. Everyone looks at you. Nobody checks their phone. It’s dead silent. You could hear a pin drop. Because everyone in that room finally feels: Yes… That’s it! And something big is about to happen.

It’s the connection of feeling understood, sensing that there is a practical common sense and at the same time, there is a good story, a vision, a bigger picture, dreams… It’s the moment where you think: now it makes …SENSE!

It’s that exact blend of an inspiring vision and a connection to an origin story where magic happens. This is the starting point. How do create that? And how do you keep the magic going? And how do you make something big out of it?

I’ve seen this happen. I’ve been part of it. What I’m sharing here is one lens, not the only one. There are certainly many ways to explain what makes transformation work. This article offers mine – based on what I’ve observed, rooted in where I grew up.

I was thinking a lot about what the secret sauce is.

I spent some years abroad, and that distance made me think a lot about my own culture. I’m from Franconia, Bavaria, Germany. In this article we only focus on Franconian carinval. It has deep historical roots, but the way it's lived today is remarkably young. A small group of people started it, not long ago. It works from the population up. Thousands of volunteers dedicate their entire free time, year-round, unpaid. They inspire thousands more – and get them to join in.

So let me take you on a journey. I’ll say it bluntly: Don’t restructure your org chart. Don’t launch a project. Don’t do change management. Don’t bring in a consulting firm. Don’t do group therapy. Don’t.

Instead, start very small. A handful of people. And create that magic moment.

At a glance:

• Large-scale transformation that begins from a small nucleus that creates something people can recognize, feel, and join, are more likely to be successful.

• What carries transformation is not a single lever, but a combination of elements, see the table below.

• Together, they create the conditions under which people begin to carry the change themselves.

• How the first team is set up and what boundaries are put in place is decisive. I'll cover that in a separate article.

• Through the work and the outcomes of the team, you learn how the organization needs to change. It happens through experience and learning, not through planning and strategy.

What does that look like in practice? In the companies where I saw this work, the pattern was always the same: A small group of people starts. External advice in small doses. The majority are internal. No frameworks imposed from above – principle-based work instead. That small group needs the magic spark. And from there, they build something new.

The organizational change that was firmly established years later grew out of hands-on experience with a small example that was then scaled up. Not top down. But from a grassroots movement.

Franconian carnival is a good example of how to win hearts and minds. And that's the foundation for AI at scale – because you need many different departments on board. Nobody really knows yet how everything works in detail with AI. The org chart doesn't quite fit anymore, but we do not yet know how exactly it will look like in five years.

Instead of rushing to commit resources in the wrong places, I want to show you principles that help. In the large-scale transformations I was part of, these principles were applied. We didn't talk about carnival back then. But I think a good metaphor helps more than colorful strategy slides.

Here’s what I’ll do: First, the characteristics of Franconian culture, abstracted. Then, a brief look at how these were applied in the companies. And after that, my interpretation.

The characteristics of Francian carnival are these. I extracted them from personal observation, not from a paper or a book. This doesn't claim to be an academic paper. It's simply my personal observation. These may apply certainly to other cultures, too.

1. Strong narrative embedding

2. Transcending through a shared vision

3. Year-round preparation

4. Cooperation with governmental/municipal structures

5. Strong communal experience and social mixing

6. Active participation of non-experts

7. Transformation of public space

8. Symbolic forms

9. Temporary suspension of everyday norms

10. Regular rituals

11. Specific food and drink, often with symbolism

12. Music and dance as central forms of expression

13. Economic significance for local communities

14. Cyclical recurrence

15. Inter-generational passing down of tradition

Here’s an overview of what these elements look like in carnival, how they were lived in the companies, and what I derive from them:

The organization and the org chart will change. But what that will look like in your company – you can’t know yet. And neither can any vendor or strategy consultant.

Only through experience and learning from hands-on implementation will it gradually become clear how you need to change your organization.

Strategies often have the problem that they’re neither rooted in the company’s history nor backed by an inspiring vision. That’s why they lack connection and power.

People want things to make sense. They want to be part of something bigger. AI can only be one piece in that bigger picture.

Let your work be guided by principles. Which principles to apply when setting up the core team – I’ll cover that in the next articles.

In the globally known enterprises where I was part of the transformation, the teams delivered measurable value. Major luxury end-user devices were shipped with new technology. Customer-oriented full automation of processes saved measurable costs. First steps with AI led to sustainably more efficient ways of working with happier employees.

I’ve also been part of large strategy projects where literally millions were burned. I’ve thought long and hard about what makes the difference – because the individuals involved were all highly qualified and wanted nothing but the best.

It’s the way you set up systems.

One thing is already clear: for AI at scale, you don’t just need the data or AI department. You need business, and probably other areas too – legal, HR, others.

If you’re a data or AI lead, the question is: how do you get everyone on board?

Mapped onto my Discipline Net, your organization might be right here. The business value is understood, the end-to-end chain is clear. Now it’s about mobilization – and the orange disciplines are up next:

For all of these areas, an awake, motivated core team – that is then scaled the right way – is the best foundation for a successful transformation.

Now relax and think about chocolate. I’m taking you on an innovation journey. By the end of this article, you’ll have a selection of methods to apply to your actual problem. And if you’re still unsure exactly how to go about it, write to me, I’d love to hear from you.

But for now: chocolate. Schokolade in German. Handcrafted.

Imagine a small chocolate manufactory. Bean-to-bar, everything handmade. The chocolatier knows every bean, every roast, every profile. Everyone is passionate, but times are getting tougher. Cocoa beans are getting more expensive, customers are buying less. They want to explore AI but don’t really know how. There are ideas and there are conflicts.

The chocolatier asks me for help1.

First, we put together a team: community manager, chocolatier, data engineer, AI engineer, vibe coder, confiseur, shop owner. Seven people – some understand customers, some understand data, one produces the samples, one sees the reactions at the shelf. No one on the team can solve the problem alone, but together they cover everything, from the cocoa bean to the customer review.

When you put together a team to solve complex problems innovatively – make it a colorful mix. Different domains, different skills, different ages, different genders, different opinions, different levels of experience. The more different, the better. Ideally, different hierarchy levels too.

Now let’s go.

The team comes together and the task is presented. There are tensions. People clash.

We need methods2 to help us deal with this. We start. The whole thing doesn’t happen in a single day.

The team discusses passionately. Emotions run high. There is tension and resistance. Above all: contradictions!

We write them down deliberately. Reality is always messy. The point is to accept this and not argue it away. The goal is to take the contradictions seriously and give the team the chance to go deeper, to find the valuable within the paradox – but that’s not going to happen today. Good things take time.

Method: Wicked Questions

A Wicked Question makes a paradox visible – two things that are simultaneously true and seemingly contradict each other. It’s not about answers, but about seeing the tensions in which the problem moves.

The mood in the team improves. People feel a little more understood, and a little exhausted. But nowhere near the point where the real work can begin. Everyone still has too much on their mind and too much on their desk. But they want to move forward, so where does the energy come from?

Method: Ecocycle Planning

The team places all existing activities on a figure eight – the Ecocycle. This makes visible where energy is tied up and where it could be freed.

The team is amazed – seeing things laid out like this helps enormously. It opens up room for action. Everyone thinks: We don’t have to do everything the same way forever! Things have a cycle, just like in nature. Movement comes into the group, things start happening.

Until the discussions start again. One killer argument after another. But suppressing the discussion wouldn’t help either. We keep going.

We need to understand more. All the discussion points sit on different levels.

Method: Panarchy

Panarchy makes visible that every problem is embedded in a multi-level system – from micro to macro. The levels influence each other, and that’s exactly where the blind spots are.

A big aha moment! A bit more clarity again – but wait: we don’t know what the future holds! Discouragement is the next feeling.

What we need now are strategies that don’t just prepare for one possible future, but for several:

Method: Critical Uncertainties

The team identifies the two uncertainties that could change everything and builds four scenarios from them. The goal is a strategy that doesn’t bet on a single future.

It helps! Everyone is glad things are getting realistic. The mood now swings between hope and fear of failure. How do we move forward?

We define failure:

Method: TRIZ

TRIZ cleans house – via the detour of failure. The trick: it’s psychologically easier to say what’s guaranteed to go wrong than to look directly for your own mistakes.

Ok, the worst part is over! Everyone wants to finally get started, there’s enough energy now.

We begin with:

Design Thinking

Now we build and test – not into the void, but on the foundation of the five previous methods. Design Thinking is not a linear process, the team jumps back, discards, rebuilds.

First, understand real chocolate lovers – not what we assume they want, but what they actually care about. Then, formulate the problem sharply: the manufactory is fighting for survival, needs to win the customer and be efficient at the same time. Generate solution ideas. Quickly build something tangible. Test it with real users and feed the feedback back into the model. This takes days to weeks.

Is that it and everything will be fine? The answer is a clear: No.

You’ve put the team together, you’ve done the workshops, you’re in the design thinking process or something similar – and feelings go up and down.

In all the teams I’ve been part of, I saw similar patterns.

Imagine an inventor building a device. Tinkering away on his own. He takes something apart, puts something together, then takes it apart again, puts it together differently. It goes back and forth constantly. He’s euphoric in between, then desperate again. Phases of confusion come, and he goes in circles. He questions the entire mission, wants to throw it all away and yet can’t let go. Days come when he feels paralyzed. Days come full of hyperactivity. Suddenly he knows it! Then again the simplest things escape him – back to square one! Until unexpectedly the breakthrough comes.

It’s not a linear process. It’s highly emotional.

The good news: my experience is that, the more loops the team goes through, the more confusion there is in between, the more drafts get discarded – the better the result.

Maybe you’re thinking now: ok, what we’re doing isn’t really innovation. And I’m telling you: even if you’re not inventing anything new, the moment you’re facing tasks where the path to the solution isn’t clearly known, where maybe not even the target is clear, you’re touching the sphere of innovation.

Step in and don’t be afraid. Even if it’s hard.

The moment the target is unclear and the path to get there even more so, fears set in. Our society has also become more and more anxious over the past decades. I’ll write a separate article about that.

Can you allow this process, or do you panic and start managing?

Our work often moves in the intangible. But it closely resembles what the inventor does: taking apart and putting back together, being confused and starting over again.

Are you ready for this journey?

© 2026 Bianca J. Schulz. All rights reserved.

The people there are qualified, they’re cool, they’re nice, they have track records to show for it.

In both companies, large important initiatives are underway, involving data and more (this was before AI).

The leaders in both companies are genuinely nice people. They’ve all been through many leadership training. You get along well with them. Both companies also have excellent processes, everything is perfectly organized when it comes to on-boarding and things like that. Both companies have outstanding HR departments.

One company blew several million euros on a data platform project. The other company successfully ran a program consisting of 10 teams, and afterward an entire ecosystem of data, software, and hardware was up and running. I unfortunately can’t go into too much detail, otherwise you’d be able to guess which companies I’m talking about.

I worked in both as a freelancer. I’ve thought a lot about WHAT the actual difference is, when so much is really similar and especially the people in both companies were genuinely great. So it was definitely not about the individuals. I got along with everyone. But I also couldn’t prevent the waste of money in one of the companies. Why not?

Oh, and both were agile, so that wasn’t it either.

So what are the differences, you ask?

I have to emphasize it once more. It’s not the people. It’s not their qualifications. It’s also not the company in general, both companies are profitable.

It’s something that’s often overlooked. Something you don’t even think about. Something that’s not on your radar. There’s also no direct literature about it, only indirectly and on adjacent topics. I assume that the people who typically write about these kinds of topics professionally don’t have the opportunity to get these direct insights.

Both initiatives required multiple teams. We’re also not talking about scaled agile frameworks, because it wasn’t just software being delivered, but also infrastructure, platform, and hardware and more.

The difference between the two initiatives was the combination of goals, boundaries, recognition, performance, and career paths.

In the company that threw a lot of money out the window, goals were vague, boundaries were arbitrary, recognition was based on personal likability, performance was irrelevant, and the career path was hierarchical.

In the very successful company, goals were razor-sharp and crystal clear, boundaries were extremely tight, recognition came exclusively for performance from the very top directly to the team member, performance was a criterion that decided whether you were in or out, and the career path ran along the value chain.

In the company that spent millions on nothing, there were hundreds of PowerPoint slides about the goals and dozens more Miro boards. It all sounded great, but you couldn’t sum it up in one sentence. The goals were the product of many external vendors and consultants. You’ve all seen this before. The anti-pattern: If you had woken someone up in the middle of the night and asked what the goal of the initiative was, everyone would have stammered something different. It was diffuse.

In the other company, it was exactly one sentence, and everyone knew it, understood it, and can still recite it years later.

In the company that spent millions on nothing, there were no boundaries. The scope was constantly expanded on a massive scale. Everything was coupled together. Then this was added, then that. Oh, and let’s also redo this while we’re at it. Financially, there were no limits at the beginning either. Wish for whatever you want.

In the other company, there were many strict constraints. Both at the strategic level and at the program level. There was clarity at every level. Tight financial constraints. Clear expectations for what’s required of everyone. Clear directives on how to work. The scope was easy to understand (and yet hard to execute – it was an entirely new field, something nobody had done before, absolute uncharted territory, not some run-of-the-mill topic, you had to talk to experts worldwide, but the WHAT was crystal clear). There were very strict rules about what had to be working at the end of the sprint (the results were integrated across all teams, and the outcome was tested in a running machine at the end of each sprint).

All features and bugs from every team were measured at the end of the sprint – specifically the ones reported by the end user of the machine, and when a user reported an error, the team had to take care of whatever was raised first. There was a very clear stance from leadership. Where the problem surfaces is where it gets fixed, and nobody wants to hear that the root cause lies with another team. There were rules for how retro results had to be made transparent, and there were rules for how learning happened across the entire program.

Vendors were kept on a tight leash, there was no stepping out of line, and the daily rates were extremely low. And yet it was a fierce competition to get in as a vendor, because everyone knew you’d learn an incredible amount there and it was worth it. It would go beyond the scope of this article to list every detail, and I also don’t want to give the company away, but there was a strict regiment – you have to understand that.

In the company that spent millions on nothing, there was no clear definition of what team performance was expected. They more or less expected tickets to be completed and the plan to be followed – a plan that kept changing. Recognition was given for being nice and likable. People who got along well with all stakeholders received recognition. But there was no systematic approach. It was more of a random occurrence.

In the other company, there were clear expectations: Teams must deliver working features every sprint. Performance was defined as: Solve problems together (there were many technical challenges). All teams work with each other. If one team builds central components for the other teams and it becomes a bottleneck, the other teams must contribute to building the central components. Features must increase every sprint. Bugs must be fixed.

Features must be demonstrated in a running machine during the review. Recognition comes from the board for teams and team members. For performance and results. Nothing else. The board regularly reviewed the results. You can surely imagine how uplifting that was for the engineers. They came from all over the world, were young, and they were happy and proud after a successful review.

It’s an incredible feeling when you’ve achieved something and the board sees it and acknowledges it. You are seen! And you’ve accomplished something big! It's like in sports – the joy of winning only exists because the rules are strict and everyone knows exactly what winning looks like!

This is perhaps the most important point. Career – how does it work? Does it go from team member to team lead? And then hierarchically upward from there? Maybe also at the project level – do you become a project manager, program manager, etc.?

Is the career path a different path from the value chain?

How many departments and teams in your org chart do you need for a data and AI initiative?

How is value created? Through the combination of business unit, data team, AI team, and maybe infrastructure/platform?

Okay, and how do you build a career with that combination?

The successful company has a different org chart than the hierarchical one we all know. There are very few levels of hierarchy, for one. On top of that, hierarchy was completely stripped of its significance. There are only people managers, each responsible for around 100 people. It’s purely about admin tasks. There are no more role titles either – they were abolished.

The entire hierarchy runs along the value chain. You advance through more recognition, more responsibility, more money, more visibility. No titles, no roles, no little fiefdoms – instead, a radical rethinking.

And we’re talking about something that happened over 10 years ago at this company. It’s not even new.

My firm conviction is: if you want to improve your business with data and AI at scale, you cannot get around learning these basics and aligning the entire organization to that goal.

The hierarchical org chart was not a mistake. It fit the world at the time. You had separate departments. If they worked well, the business ran well. So career advancement went hierarchically upward. That worked because it matched the reality of that era.

But if I now want to deploy AI at scale – to automate processes, to actually make money with business data – then I need at least one, if not all business units, all data teams, all AI teams, all infrastructure teams. That’s something that simply didn’t exist before. There was nothing like it.

That means: the org chart with its departments no longer fits what the future looks like. And the career logic embedded in it doesn’t either.

Career must orient itself around how value is created. And value is no longer created within a single department. It’s created in the combination – business, data, AI, infrastructure, together, toward one goal. So career logic must follow that same path.

If good performance is rewarded by making someone the lead of a small team of only engineers, that only increases the complexity of the initiative – you’re just adding more overhead, another person who wants to coordinate. If someone is rewarded for performance by being more visible, receiving more recognition, and above all being given a larger, cross-departmental scope of responsibility, then that supports exactly the kind of collaboration that creates value. Hierarchy then only serves to handle the old logic of contracts and vacation approvals.

My conviction is: Many organizations need to fundamentally reinvent how they’re set up, or they’ll be left behind. The complexity of what’s ahead demands radical simplicity in the organization and very tight boundaries in execution. Both must be in harmony with each other. Those still busy doing things the old way will be outpaced by those who operate with simplicity and discipline.

In Germany there is a card game for children called Black Peter. It is a simple game where you collect pairs, and whoever is left holding the Black Peter at the end has lost. Everyone here knows it. Nobody wants to have the Black Peter.

It is the same in teams.

Each of us has already engaged with teamwork, either in workshops, training or through books. Often it is a mandatory training for employees, even for juniors. Managers receive training on it, coaches, project managers too. And yet one point is consistently overlooked, with devastating consequences. I would even say: very few of us have ever truly worked in a real team. At least not in one like this:

Although we have all learned that teams go through different phases, we tend to forget it when it matters most. During my work I was part of many different teams, and one thing above all others distinguishes a high performing team from a ragtag bunch. I call it the Black Peter principle.

Sooner or later, teams reach a point where it gets hard. And I am not talking about obvious conflict. There does not have to be a fight, a difficult person, or a crisis. It is more of a feeling. Nothing particularly unusual has happened, but something is off. It is like standing in front of a really difficult task that you haven’t mentally worked through yet. A heavy, diffuse feeling. In German you call that the “inner pig-dog”, that voice of inner resistance. In teams, this exists too, only much, much stronger. I call this unknown something the Black Peter, that everyone wants to get rid off.

And now comes the decisive moment.

Teams want to get rid of it. That is natural. But what happens next is what separates the good teams from the great ones. The organizations that allow the Black Peter to leave the team, through a manager stepping in, or simply by allowing people to only stay loosely connected to the team, these organizations will never have high performing teams. The relief is real. But so is the missed opportunity.

I compare it to a marriage. As soon as difficulties arise, and it doesn’t even have to be a fight, it can simply be something unspoken hanging between you, and then you bring in a third party. That never ends well. It takes on a new dynamic that sometimes even worsens the situation. The issue doesn’t get resolved. It gets a life on its own. The Black Peter.

I have seen teams that managed this well. Those teams couldn’t bring in anyone from the outside at all, because they were fully empowered and authorized, with senior leaders inside the team. That was in several large organizations. So it is absolutely possible. Those teams learned to sit with the discomfort, work through it together, and they delivered outstanding results.

And I have seen the other kind. All managers outside the team, authority never delegated, individuals pulled in different directions by people above them. The Black Peter just wanders through the entire organization until it is eventually dropped. And with it, the chance to grow together is gone.

The structure of the organization around the team matters just as much as the team itself. A team is not a team just because you put people in a room and give them a name.

When it comes to scaling AI across a company with large amounts of data, this is not a nice-to-have insight. It becomes the difference between transformation and expensive stagnation.

The challenge in Data and AI is even more complex, more daunting, more unclear and bigger than in a pure software development team. There is no simple roadmap you follow step by step and everything will work out.

That is exactly why building teams that truly function becomes even more important.

AI is new. We are all still learning. Maybe you are sitting on a pile of legacy data systems, or some roll-out that is only half finished. Maybe you have no real overview at all, maybe your systems are not even talking to each other yet. Maybe nobody involved fully understands the end-to-end process. Maybe it is completely unclear how the data should be used or how the whole thing should be structured. Even figuring out where to start is a challenge in itself.

The task is enormous. And it needs teams that are not afraid of Black Peter.