Einfachheit bedeutet nicht weniger Tools — sondern die richtige Ebene

Das effektivste System, das ich je gebaut habe, ist von außen auch das unscheinbarste. Kein glänzendes Multi-Agenten-Dashboard. Keine zwölf Integrationen auf einer Einstellungsseite. Nur eine einzige Sache, die alles kennt — mit Agenten, die darauf aufbauen, wenn ich sie brauche.

Dorthin bin ich auf die harte Tour gelangt — indem ich zuerst die komplizierte Version gebaut habe.

Drei Tools, drei Brücken, ein Chaos

Vor ein paar Monaten liefen bei mir drei separate Tools parallel. Ein CRM, das ich selbst gebaut hatte. Einen E-Mail-Agenten, der mein Postfach sortierte, Kontakte und Datenpunkte extrahierte und mir ermöglichte, auf E-Mails zu reagieren, ohne jede einzelne zu öffnen. Und eine LinkedIn-Chrome-Erweiterung, die Kontakte, Unternehmen und Nachrichten mit einem Klick direkt aus LinkedIn speicherte.

Jedes einzelne davon funktionierte. Das war das Problem.

Weil sie alle isoliert funktionierten, musste ich Brücken bauen. Der E-Mail-Agent brauchte eine Brücke zum CRM, damit extrahierte Kontakte irgendwo landen konnten, wo sie nützlich sind. Die LinkedIn-Erweiterung brauchte eine Brücke, damit gespeicherte Unternehmen und Personen nicht in einem Silo verschwanden. Und jede Brücke bedeutete eine neue Sache zum Warten, einen neuen Ort, an dem Daten veralten konnten, einen neuen Moment, in dem ich in einem System nachschlagen musste, um in einem anderen etwas zu tun.

Klingt logisch, oder? Drei Quellen, ein Ort, an dem alles landen soll — natürlich verbindet man sie. Aber „verbunden" ist nicht dasselbe wie „nativ". Und ich lebte jeden einzelnen Tag in der Lücke zwischen diesen beiden Dingen.

Was ich wirklich getan habe — und was sich verändert hat

Ich habe aufgehört, den E-Mail-Agenten und die LinkedIn-Erweiterung als separate Produkte zu behandeln, die mit dem CRM kommunizieren. Ich habe sie zum Teil des CRM gemacht.

E-Mail-Entitäten leben jetzt als erstklassige Konstrukte im CRM. Es gibt Input-Worker, die E-Mails hereinholen, und Output-Worker, die sie rausschicken. Der E-Mail-Agent tut immer noch alles, was er vorher getan hat — sortieren, extrahieren, aufzeigen, was ich bearbeiten muss — aber jetzt läuft er nativ. Eine E-Mail wird gespeichert und ist automatisch mit der richtigen Person, dem richtigen Unternehmen, dem richtigen Ereignis verknüpft. Kein manuelles Taggen. Kein Kopieren von Kontaktdaten.

Wenn ich eine E-Mail verschicke, trägt sie bereits Kontext aus dem Datensatz dieser Person im CRM. Die E-Mail weiß, wer die Person ist, weil das System, in dem sie lebt, weiß, wer sie ist.

LinkedIn-Kontakte werden jetzt beim Speichern automatisch dedupliziert und mit vorhandenen Daten zusammengeführt. Wenn jemand bereits im CRM ist, entsteht durch das Speichern aus LinkedIn kein Duplikat — es ergänzt nur, was schon da ist. Neue Kontakte kommen sauber rein.

Agenten starten per Slack oder Web auf Abruf. Ich habe kein Dashboard, in das ich jeden Morgen einlogge, um zu prüfen, welches System was hat. Ich frage einfach, oder ich handle — und das Richtige passiert.

Weniger Klicken. Weniger Nachschlagen. Weniger Kopieren und Einfügen. Wirklich — ich merke, dass es fehlt. Diese unterschwellige Reibung, die ich immer mit mir getragen habe, ist einfach weg.

Dann war ich beim pf1-Launch

Letzte Woche war ich beim Launch-Event von pf1, Paperflites Plattform für AI-Agenten. Was sie demonstrierten, war ein Knowledge-Graph-Agent (zu sehen unter pf1.ai/agents/knowledge) — er zieht aus jedem System, das ein Unternehmen nutzt: Dropbox, Drive, Gesprächsaufzeichnungen, was auch immer, und baut daraus eine einheitliche Wissensebene. Geschriebenes Wissen, ungeschriebenes Wissen, das implizite Zeug wie Verkaufsmuster und Frameworks, die Leute praktizieren, aber niemand jemals wirklich aufzeichnet.

Ihr Framing war „eine einzige Quelle der Wahrheit für jeden Rep und jeden Agenten." Die Idee: Sobald man diese Ebene hat, kann man jeden Agenten darauf setzen — und dieser Agent kennt sofort alles, ohne dass man ihn manuell mit zwölf verschiedenen Quellen verkabeln muss.

Ich schaute auf die Demo und hatte diesen ganz bestimmten Moment des Wiedererkennens. Nicht „oh, interessantes Konzept." Eher „das ist genau dasselbe, was ich gerade gemacht habe — nur für ein ganzes Unternehmen."

Das Muster ist identisch. Wissen ist über Systeme verteilt. Tools kennen jeweils einen Teil davon. Man baut Brücken, um Informationen zwischen ihnen zu verschieben — es ist lästig und fragil. Also hört man auf zu brücken und fängt an zu konsolidieren: eine Ebene darunter, flexible Agenten darüber.

Einfachheit ist kein Minimalismus

Ich möchte das präzise formulieren, weil ich denke, dass man hier leicht falsch liegen kann.

Einfachheit bedeutet nicht, weniger Dinge zu haben. Ich habe immer noch einen E-Mail-Agenten. Ich habe immer noch LinkedIn-Kontakterfassung. Ich habe immer noch ein CRM. Die Funktionalität ist nicht geschrumpft — sie ist gewachsen. Ich kann jetzt mehr tun, nicht weniger.

Was sich verändert hat, ist die Architektur darunter. Die Infrastruktur ist schlanker und nativer geworden. Statt drei Dinge, die sich durch fragile Konnektoren miteinander unterhalten, habe ich eine Sache mit mehreren Modi. Die Komplexität ist nicht verschwunden — sie sickert nur nicht mehr zu mir durch.

Das ist die Unterscheidung, zu der ich immer wieder zurückkomme. Komplexität, die durchsickert, ist das Problem. Man spürt sie als Reibung. Man spürt sie als „warte, wo ist dieser Kontakt? Hat er synchronisiert? Warum gibt es ein Duplikat? Lass mich den anderen Tab öffnen." Das ist Komplexität, die man nicht tragen sollte. Sie gehört ins System.

Und Agenten sind darin wirklich gut, sie zu tragen — wenn die Infrastruktur, auf der sie sitzen, solide ist. Wenn alles nativ und verbunden ist, kann ein Agent Kontext abrufen, ohne dass man ihm sagen muss, wo er suchen soll. Er weiß es bereits. Weil das System es weiß.

Was das bedeutet, wenn man etwas Ähnliches baut

Der Instinkt beim Bauen von Tools ist, sie separat zu bauen und später zu verbinden. Das ist als Ausgangspunkt in Ordnung — so findet man heraus, was jedes Teil wirklich tun muss. Ich bereue es nicht, die drei separaten Tools zuerst gebaut zu haben. Ich musste jedes einzelne verstehen, bevor ich sie konsolidieren konnte.

Aber irgendwann muss man die Entscheidung treffen: Ist das „verbunden" oder ist das „nativ"? Arbeiten meine Agenten auf einer einheitlichen Ebene, oder tut jeder sein eigenes Ding und ich manage manuell die Verbindungen?

Wenn man Zeit damit verbringt, zwischen Systemen hin- und herzukopieren — das ist das Signal. Wenn man drei Quellen mit denselben Kontaktinformationen pflegt — das ist das Signal. Wenn das Starten eines neuen Agenten bedeutet, dass man Kontext neu erklären muss, den er eigentlich schon haben sollte — das ist das Signal.

Der Umbau ist lästig. Es hat mich echte Zeit gekostet, die E-Mail- und LinkedIn-Funktionalität richtig ins CRM zu integrieren statt sie nur zu überbrücken. Aber die Stunden, die ich seitdem gespart habe, sind nicht mal annähernd vergleichbar. Und mehr als die Zeit — ich denke einfach klarer, wenn ich arbeite. Der Overhead ist weg.

Baut die richtige Ebene einmal. Dann setzt darauf, welche Agenten auch immer nötig sind. Das ist die Version, die skaliert, ohne dass man das Gefühl hat, ständig seine eigenen Tools zu verwalten statt sie zu nutzen.

Diese Woche: Wenn drei oder mehr Tools vorhanden sind, die Daten über manuelle Exporte, Copy-Paste oder Zapier-ähnliche Automationen teilen — eines davon nehmen und fragen, ob es eigentlich nativ in einem anderen leben sollte. Nicht verbunden mit. Darin. Die Antwort ist wahrscheinlich öfter Ja, als man denkt.