Wie wir versehentlich angefangen haben, ein Human-Agent-Unternehmen aufzubauen

Wir haben das nicht geplant.

Es gab kein Meeting, in dem jemand gesagt hätte: Ab heute bauen wir eine agentenbasierte Organisation auf. Wir haben keine dreijährige KI-Transformation entworfen und keine Zielarchitektur für das Unternehmen skizziert. An verschiedenen Stellen sind einfach spezialisierte Agenten entstanden.

Einer kennt ein bestimmtes Projekt in- und auswendig. Ein anderer ist auf eine bestimmte Technologie spezialisiert. Auf der Growth-Seite läuft ein Agent, der Google Ads analysiert, daneben ein SEO-Agent und ein weiterer für E-Commerce. Jeder davon ist aus einem anderen Grund entstanden. Gebaut von verschiedenen Leuten. Nicht nach einem zentralen Plan, sondern dort, wo jemand ein Problem gut genug kannte, um zu wissen, was er von so einem System braucht. Und wahrscheinlich habe ich deshalb eine Weile nicht gesehen, was da eigentlich passiert. Irgendwann wurde mir klar: Unser Unternehmen hat allmählich mehr Spezialisten als Mitarbeiter. Nicht im buchhalterischen Sinne. Ein Agent ist kein Mitarbeiter, und ich werde nicht so tun, als wäre er einer.

Es geht um Rollen.

Jahrelang war die Zahl der Spezialisierungen, die ein Unternehmen tatsächlich entwickeln konnte, direkt an die Zahl der Mitarbeiter gekoppelt. Wenn wir in einer bestimmten Technologie stärker werden wollten, brauchten wir jemanden, der sie gut beherrscht. Wenn wir SEO ausbauen wollten, brauchten wir einen SEO-Spezialisten. Eine gründlichere Analyse der Werbung bedeutete weitere Stunden in verschiedenen Systemen, Datenvergleiche und das Erinnern daran, warum wir vor zwei Wochen eine bestimmte Entscheidung getroffen haben. Wir brauchen nach wie vor Menschen mit unterschiedlichen Kompetenzen. Das hat sich nicht geändert. Etwas anderes schon.

Ein guter Spezialist kann heute eine zusätzliche Ebene der Spezialisierung um sich herum aufbauen. Ein Entwickler kann einen Agenten haben, der ein konkretes Projekt kennt, und einen zweiten, der auf die eingesetzte Technologie spezialisiert ist. Eine für Wachstum verantwortliche Person kann mit einem Ads-Agenten, einem SEO-Agenten und einem E-Commerce-Agenten zusammenarbeiten. Ein Designer könnte irgendwann ein System neben sich haben, das laufende Websites beobachtet, Daten sammelt, UX-Veränderungen verfolgt und an Entscheidungen erinnert, die vor Monaten gefallen sind.

Der Mensch wird dadurch nicht weniger wichtig. Er muss nur nicht mehr alles allein machen.

Lange Zeit haben wir KI einfach nur benutzt

Ich selbst habe lange genauso gearbeitet wie die meisten Menschen.

Ich hatte ein Problem, also öffnete ich ein Modell. Beschrieb die Situation, fügte Daten ein, bekam eine Antwort. Manchmal eine großartige. Manchmal eine mittelmäßige. Manchmal eine sehr überzeugende und völlig falsche. Danach schloss ich das Chatfenster und machte weiter.

KI war ein gutes Werkzeug, aber der eigentliche Kontext blieb immer bei mir. Ich war derjenige, der wusste, was letzte Woche passiert war. Ich wusste, warum wir etwas geändert hatten. Ich erinnerte mich daran, dass wir eine ähnliche Idee schon einmal ausprobiert hatten und was dabei herauskam. Bei jedem neuen Gespräch musste ich wieder von vorn erklären, womit sich die Firma beschäftigt, wie das Projekt funktioniert, was wichtig ist und was man nicht anfassen darf. So kann man schneller arbeiten, aber ein Organisationsgedächtnis baut man so nicht auf.

Der erste echte Wandel kam, als wir aufhörten, jedes Gespräch bei Null zu beginnen. Statt allgemeiner KI entstanden spezialisierte Rollen.

• Kein Programmier-Agent, sondern ein Agent, der ein bestimmtes Projekt kennt.
• Keine Marketing-KI, sondern ein System, das für Google Ads zuständig ist.
• Kein SEO-Chatbot, sondern ein Agent mit eigenen Datenquellen, eigenem Gedächtnis und einem klar definierten Arbeitsbereich.

Ab diesem Punkt war KI nicht mehr nur ein Werkzeug, das man startet, wenn man etwas braucht. Sie bekam einen festen Platz in der Arbeitsweise des Unternehmens.

Das Modell ist wahrscheinlich der uninteressanteste Teil eines Agenten

Es ist heute leicht, etwas zu bauen, das wie ein Agent aussieht. Ein Modell, ein guter Prompt, ein paar Tools, ein einfaches Interface. Je länger wir das aber machen, desto weniger interessiert mich das Modell selbst. Ein System kann auf Claude laufen, ein anderes auf ChatGPT oder DeepSeek. In einem Jahr wird ein Teil davon vermutlich etwas völlig anderes nutzen.

Das Modell lässt sich immer austauschen. Viel schwieriger ist es, alles drumherum aufzubauen - die Rolle, den Kontext, das Wissen, das Gedächtnis, die Werkzeuge, die Handlungsregeln, die Einschränkungen und die Geschichte vergangener Entscheidungen. In unseren Frameworks gibt es bereits einen fertigen Knowledge Layer. Er sammelt und strukturiert Projektinformationen, die Daten fließen in eine gemeinsame Datenbank. Dadurch kann ein Projekt seine eigene Wissensschicht haben. Ein Agent kann darauf zugreifen, und später kann man einen weiteren Spezialisten mit einer ganz anderen Rolle an denselben Kontext anschließen. Einer kennt das Projekt. Ein anderer kennt die Technologie besser. Ein dritter könnte irgendwann für Qualität, Sicherheit oder Dokumentation zuständig sein. Man muss nicht jedes Mal von einem leeren Fenster aus die ganze Welt neu erklären.

Das ist für mich deutlich wichtiger als der Name des Modells, das gerade darunter läuft.

Das Unternehmen entwickelt eine zweite Ebene

Heute sehe ich unsere Organisation ungefähr so:

                         GRUPA INSIGHT

                          MENSCHEN
                               │
            ┌──────────────────┼──────────────────┐
            │                  │                  │
            ▼                  ▼                  ▼

       DEVELOPMENT           GROWTH           DESIGN / UX

        Mensch               Mensch              Mensch
          +                     +                  +
   Projekt-Agenten         Ads-Agent           UX-Agent
   Technologie-Agenten     SEO-Agent           nächste Phase
                           E-Commerce-Agent

            │                  │                  │
            └──────────────────┼──────────────────┘
                               ▼

                ZWEITE ORGANISATIONSEBENE

                  Wissen • Gedächtnis • Tools
                Entscheidungen • Historie • Ergebnisse

Nicht alle diese Systeme sind über ein zentrales Gedächtnis verbunden. Und das sollen sie auch nicht sein. Ein Agent, der den Code eines Projekts kennt, braucht keinen Zugriff auf Werbedaten. Das Ads-System muss die Anwendungsarchitektur nicht kennen. Aber das Muster wiederholt sich.

• Ein Mensch hat eigene digitale Spezialisten.
• Ein Projekt hat eigenes Wissen.
• Ein ganzer Unternehmensbereich kann ein System haben, das ihn kontinuierlich beobachtet.

Und erst jetzt kommen wir zum wirklich spannenden Problem: Wie organisiert man all diese Rollen?

Am deutlichsten haben wir das beim Aufbau des Ads-Agenten gesehen

Am Anfang schien die Aufgabe einfach. Das System sollte Kampagnen analysieren und Schlüsse ziehen. Die Analyse selbst erwies sich aber schnell als der uninteressanteste Teil. Der Agent musste wissen, für welches Unternehmen er arbeitet. Frühere Empfehlungen kennen. Sich merken, was genehmigt, was abgelehnt und was bereits umgesetzt wurde. Er musste verschiedene Datenquellen nutzen und erkennen, wenn diese völlig unterschiedliche Geschichten erzählen.

Wenn Google Ads ein Bild zeigt und GA4 ein ganz anderes, darf er nicht einfach die Zahl wählen, die am besten zu seiner Geschichte passt. Er muss zuerst das Problem erkennen und seine Bedeutung verstehen. Manchmal muss er zum Schluss kommen, dass er auf Basis der verfügbaren Daten eine bestimmte Entscheidung nicht treffen sollte. Aus einer einfachen Idee für ein Werbeanalyse-System ist also eine deutlich größere Architektur geworden.

Grob vereinfacht sieht sie so aus:

                      EINZELNER AGENT

                    CONTEXT BOOTSTRAP
                             ↓
                       AGENT PLANNER
                             ↓
                         TOOL LAYER
                             ↓
                    CONFIDENCE ENGINE
                             ↓
                   CAPABILITY POLICY
                             ↓
                     REASONING LOOP
                             ↓
                      ACTION ENGINE
                             ↓
               DETERMINISTIC GUARDRAILS
                             ↓
                   HUMAN IN THE LOOP
                             ↓
                         OUTCOME
                             ↓
                          MEMORY
                             ↺

Das Modell ist nur ein Teil dieses Gefüges. Alles andere entscheidet darüber, ob man es mit einem Chatbot zu tun hat oder mit einem System, dem man echte Verantwortung übertragen kann. Der Agent muss zunächst wissen, wo er arbeitet. Ein Mensch beginnt nicht jeden Tag damit, das Unternehmen neu kennenzulernen. Er erinnert sich an Kunden, kennt die Projektgeschichte, weiß, warum vor einer Woche eine bestimmte Entscheidung gefallen ist. Ein Agent ohne Kontext hat nichts davon.

Deshalb lädt er vor der eigentlichen Arbeit das Wissen über seine Umgebung. Beim Ads-System sind das Kontoinformationen, Geschäftskontext, frühere Berichte und die Empfehlungshistorie. Ein Projekt-Agent braucht etwas völlig anderes - Architektur, Dokumentation, Entscheidungshistorie, systemspezifische Regeln. Das ist nicht der spektakulärste Teil des Ganzen. Es ist viel einfacher, in einer Demo ein Modell zu zeigen, das blitzschnell Fragen beantwortet. Aber ohne diese Schicht bleibt jeder Agent ein Berater, dem man jeden Morgen das Unternehmen von Grund auf erklären muss.

Dann kommen Werkzeuge und Planung dazu. Ein klassisches Skript bekommt eine Anweisung: Hole diese Daten, berechne diese Kennzahlen, erstelle einen Bericht. Ein Agent bekommt ein Problem. Wenn auf Kampagnenebene etwas schlecht aussieht, kann er tiefer gehen. Keywords prüfen, dann Suchbegriffe, Ads mit Analytics vergleichen, in die Search Console schauen, nachsehen, ob ein ähnliches Problem schon einmal aufgetreten ist. Es geht nicht darum, alles abzurufen. Es geht darum, die Belege zu sammeln, die in einer konkreten Situation gebraucht werden. Erst dann kann man von Reasoning sprechen.

Ein guter Agent muss auch sagen können: Ich weiß es nicht

Das ist eines der Dinge, die mir bei frühen KI-Systemen am meisten gefehlt haben. Modelle können sehr gut antworten. Deutlich schlechter können sie im richtigen Moment aufhören. Mit unvollständigen Daten kann ein Agent durchaus offensichtliche Budgetverschwendung oder ein klares Problem erkennen. Er sollte aber nicht so tun, als könnte er zuverlässig Umsätze prognostizieren. Deshalb gibt es in unseren Systemen Confidence- und Capability-Policy-Schichten. Der Agent bewertet nicht nur, wie sicher er sich seiner Antwort ist. Er muss auch wissen, woher die Unsicherheit kommt und was er bei dieser Datenqualität überhaupt tun darf. Das ist ein feiner, aber wichtiger Unterschied. Es reicht nicht, dem Modell zu sagen, es solle vorsichtig sein. Wenn etwas wirklich nicht passieren darf, sollte Code es verhindern - nicht ein Prompt. Daher die deterministischen Guardrails und der Mensch, der Aktionen nach wie vor genehmigt oder ablehnt.

Autonomie an sich ist für mich kein Ziel - besseres Funktionieren des Unternehmens schon.

Eine Empfehlung braucht ihre eigene Geschichte

Ein klassischer Bericht lebt nicht lange. Eine E-Mail kommt, wir lesen sie, vielleicht ändern wir etwas. Eine Woche später kommt die nächste. Nach einem Monat weiß kaum noch jemand genau, warum wir das Budget gekürzt haben, wie die Daten damals aussahen oder ob das Ergebnis den Erwartungen entsprach.

Ein Agent sollte nicht so arbeiten. Eine Empfehlung hat ihren eigenen Lebenszyklus. Sie kann eingereicht, genehmigt, abgelehnt oder zurückgestellt werden. Später kann sie zur Neubewertung zurückkommen. Manchmal wird sie zurückgezogen. Deshalb gibt es in unserem System Status wie REASSESS und WITHDRAWN.

Am meisten interessiert mich der Moment, in dem ein Agent zu seinem eigenen früheren Schluss zurückkehrt und feststellt, dass er vor zwei Wochen Sinn ergab, aber neue Daten die Lage verändert haben. Oder das Gegenteil - er steht weiterhin dahinter. Ein Unternehmen funktioniert nicht in einem einzelnen Prompt. Es funktioniert über Entscheidungen, deren Konsequenzen und nachfolgende Entscheidungen, die im Licht des Geschehenen getroffen werden. Wenn ein Agent Teil einer Organisation sein soll, braucht er seine eigene Geschichte.

Dann kam SEO neben Ads dazu

Und dann wurde es richtig spannend. Als nur der Ads-Agent lief, konnte man ihn noch als eigenständige Spezialisierung betrachten. Jetzt arbeitet ein SEO-Agent daneben. Und ein E-Commerce-Agent. Jeder schaut auf einen anderen Ausschnitt desselben Geschäfts.

• KI-Ads sieht Kampagnen, Kosten, Suchanfragen und Conversions.
• KI-SEO beobachtet Sichtbarkeit, Seitenstruktur, Inhalte, technische Probleme und Search-Console-Signale.
• KI-E-Commerce betrachtet Sortiment, Produkte, Kategorien, Nutzerverhalten und Verkäufe.

Und es zeigt sich sehr schnell, dass sich diese Welten nicht wirklich trennen lassen.

Ein Thema, das in der Werbung schlecht abschneidet, kann für SEO strategisch wichtig sein. Kampagnendaten können zeigen, welche Botschaften wirklich bei den Menschen ankommen. SEO kann eine Nachfrageverschiebung erkennen. E-Commerce kann zeigen, dass Traffic, den ein System als schwach eingestuft hat, den Umsatz tatsächlich auf einem anderen Weg beeinflusst. Wir brauchen also keinen einzelnen Super-Agenten, der vorgibt, alles zu können - wir brauchen verschiedene Spezialisten.

Aber irgendwann reichen die Spezialisten allein nicht mehr aus, weil jemand das Gesamtbild sehen muss. Wenn KI-Ads eine Budgetkürzung empfiehlt, KI-SEO ein strategisches Thema erkennt und KI-E-Commerce feststellt, dass Nutzer in diesem Bereich einen längeren Weg zum Kauf haben - dann reichen drei getrennte Berichte nicht. Es braucht eine Schicht, die erkennt, dass gerade ein Konflikt entstanden ist.

Bei uns beginnt diese Rolle der Orchestrator zu übernehmen. Er soll kein weiterer Ads-, SEO- oder E-Commerce-Spezialist sein. Seine Aufgabe ist es nicht, die anderen Agenten zu überstimmen. Er überwacht den gesamten Prozess - weiß aber, welcher Agent sich um ein bestimmtes Problem kümmern sollte. Er kann Kontext weitergeben, den ein anderer Spezialist gesammelt hat. Wenn er widersprüchliche Empfehlungen sieht, wählt er nicht automatisch eine davon. Er sammelt Belege, identifiziert Lücken und entscheidet, ob eine weitere Analyse, ein Experiment oder eine menschliche Entscheidung nötig ist.

Erst hier entsteht etwas, das wirklich einer Organisation ähnelt. Spezialisten betrachten das Geschäft aus ihrer jeweiligen Perspektive. Der Orchestrator sorgt dafür, dass sie nicht arbeiten, als gäbe es die anderen nicht. Darunter liegt eine gemeinsame Beweis- und Gedächtnisschicht. Das bedeutet nicht, dass jeder Agent alles sieht. Verschiedene Rollen haben nach wie vor unterschiedliche Zugriffsrechte und Verantwortungsbereiche. Es geht um etwas anderes.

Wenn zwei Systeme zu unterschiedlichen Schlüssen kommen, sollte die Organisation wissen, warum sie sich unterscheiden. Die Aufgabe des Orchestrators ist es, aus dieser Meinungsverschiedenheit einen Entscheidungsprozess zu machen - und nicht drei weitere Berichte zum Lesen.

In der Entwicklung passiert etwas Ähnliches

Entwicklungs-Agenten haben andere Ziele, aber das Muster ist dasselbe. Wir haben Systeme, die für bestimmte Projekte gebaut wurden. Sie haben eine eigene Wissensschicht und starten nicht aus einem leeren Kontext. Die vom Framework gesammelten Informationen fließen in eine Datenbank und werden zur Grundlage für weitere Spezialisierungen.

Ein Agent kann ein Projekt gut kennen. Ein anderer eine bestimmte Technologie. Mit der Zeit können weitere Rollen hinzukommen - Qualität, Sicherheit, Dokumentation. Wir wollen keine Agenten produzieren, nur weil man sie bauen kann.

Ein Agent macht Sinn, wenn ein dauerhaftes Problem existiert. Wiederkehrende Arbeit. Große Mengen an Kontext. Viele Datenquellen. Die Notwendigkeit, sich an frühere Entscheidungen zu erinnern. Oder ein Bereich, den ein Mensch einfach nicht ständig im Blick behalten kann.

Der nächste natürliche Bereich ist UX

Ich meine keinen Agenten, der selbständig Websites gestaltet. Das wäre die uninteressanteste Anwendung. Viel spannender ist ein Spezialist, der neben dem Designer arbeitet. Er kann das Projekt kennen und sich an frühere Entscheidungen erinnern. Die laufende Website analysieren, Signale erkennen, Inkonsistenzen aufzeigen, Lösungsansätze verfolgen, die in guten Produkten auftauchen. Er kann einen Bereich entdecken, der es wert ist, getestet zu werden. Daran erinnern, dass eine ähnliche Idee einmal verworfen wurde. Etwas aus den Daten herausziehen, das der Designer nicht regelmäßig beobachten konnte.

Der Designer gestaltet weiterhin. Er ist derjenige, der die Marke versteht und das große Ganze sieht. Aber er muss nicht die einzige Person sein, die sich an alles erinnert, alles beobachtet und alles im Griff behält. Und genau hier sehe ich den wichtigsten Wandel.

Ein Human-Agent-Unternehmen bedeutet nicht, dass Agenten alles machen. Es bedeutet, dass Menschen in ihren Spezialisierungen nicht mehr allein sind.

Die Mitarbeiterzahl beschreibt nicht mehr alle Kompetenzen eines Unternehmens

Grupa Insight bietet seit Jahren ein breites Leistungsspektrum an. Software. E-Commerce. SEO. Ads. UX. Design. KI. Für einen Außenstehenden liegt die Frage nahe, wie ein Unternehmen dieser Größe so viele Spezialisierungen ernsthaft entwickeln kann. Bis vor Kurzem war die Antwort einfach. Heute ergibt sich der Spezialisierungsumfang eines Unternehmens jedoch nicht mehr allein aus der Teamgröße. Die Systeme und digitalen Spezialisten, die um die Arbeit der Menschen herum entstehen, gewinnen zunehmend an Bedeutung.

Ein guter Entwickler wird nicht weniger wichtig, weil ein Agent sein Projekt kennt. Er hört einfach auf, Zeit mit dem ständigen Wiederaufbau von Kontext zu verschwenden.

Ein SEO-Spezialist verschwindet nicht, weil ein SEO-Agent existiert. Er kann weniger Zeit mit dem Sammeln von Daten verbringen und mehr mit den Dingen, die wirklich seinen Kopf brauchen.

Ein Designer wird nicht überflüssig, weil irgendwann ein UX-Agent neben ihm auftaucht. Er bekommt mehr Zeit für den wichtigsten Teil seiner Arbeit - gute Entscheidungen.

KI muss das Team nicht verkleinern. Sie kann die Zahl der Spezialisierungen vergrößern, die demselben Team zur Verfügung stehen.

Ein Unternehmen mit einem Dutzend Mitarbeitern kann anfangen, so zu arbeiten, als hätte es eine zusätzliche Schicht sehr eng spezialisierter Experten neben sich. Keine Menschen, die Maschinen spielen. Keine Maschinen, die Menschen spielen. Einfach neue Rollen.

Vielleicht ist das ein Human-Agent-Unternehmen

Ich weiß noch nicht, ob dieser Name bei uns bleiben wird. Im Moment beschreibt er gut, was ich sehe. Ein Unternehmen aus Menschen und einer zweiten Ebene spezialisierter Systeme. Entwickler haben eigene digitale Spezialisten. Projekte haben eigenes Wissen. Marketing hat Agenten, die verschiedene Bereiche beobachten. E-Commerce hat ein eigenes System. Mit der Zeit wird eine ähnliche Schicht beim UX und wahrscheinlich auch in anderen Unternehmensbereichen entstehen. Jeder Agent hat eine andere Rolle, einen anderen Kontext, andere Werkzeuge und andere Berechtigungen.

Das ist der unwichtigste Teil. Modelle werden sich ändern. Rollen, Wissen, Gedächtnis und Prozesse werden bleiben. Und die Menschen, die verstehen, warum diese Systeme überhaupt existieren, werden weiterhin der wichtigste Teil der Organisation sein. In den letzten Jahren wurde viel darüber gesprochen, wie viele Menschen KI ersetzen wird. Diese Frage interessiert mich immer weniger.

Viel spannender finde ich die Frage, was mit einem Unternehmen passiert, in dem jeder gute Spezialist sein eigenes Team digitaler Spezialisten um sich herum aufbauen kann.

Ich glaube, wir fangen gerade an, das herauszufinden. Nicht durch Präsentationen und nicht durch Theorie. Wir haben einfach eines Tages festgestellt, dass unser Unternehmen mehr Spezialisten als Mitarbeiter hat.