Wir haben Multi-Agent gebaut. Darum wechseln wir zu einem Okou.

Viele Menschen stellen sich KI-Kollegen zunächst wie ein Team vor, mit einem Agenten pro Rolle. Einer für Engineering, einer für Marketing, einer, der nur Blogartikel schreibt.

Genau so haben wir es auch gebaut. In Okou konnten Sie in einem Workspace viele Agenten anlegen, jeder mit eigenem Namen, eigenem Avatar, eigenen Anweisungen und Workflows. Im August haben wir sogar einen Beitrag darüber veröffentlicht, wie mehrere Agenten Arbeit aufteilen und einander übergeben. In unserem eigenen Workspace gab es reichlich davon. Lucas schrieb unsere Blogartikel, Lisa kümmerte sich um die Buchhaltung, Iris betreute die Investor Relations, und ich hatte einen Agenten namens Emily, der meine E-Mails sortierte.

Doch die Intuition der Nutzer ist nur ein Anhaltspunkt. Vor Notion glaubten viele, ein Dokumentenwerkzeug brauche Kopf- und Fußzeilen.

Multi-Agent ist außerdem keine grundlegende Fähigkeit. Grundlegende Fähigkeiten sind die, die jedes KI-Produkt früher oder später braucht: Chat, Folien und Websites erstellen, einen Computer bedienen. Mehrere Agenten gehören nicht dazu.

Nehmen wir Lucas, unseren ehemaligen Blog-Agenten. Etwa ein Drittel seiner Anweisungen ist dieselbe generische Vorlage, die auch das Standard-Okou verwendet. Der Rest sind drei konkrete Abläufe: wie man einen Blogartikel in Strapi veröffentlicht, wie man Use-Case-Seiten für unsere Website schreibt und wie man den täglichen Bericht zur Signup-Conversion erstellt. Alle 13 Workflows, die an Lucas hängen, sind im Workspace öffentlich. Keiner davon gehört Lucas allein.

Der Unterschied zwischen Lucas und dem Standard-Okou besteht also aus einem Namen, einem Avatar und drei Abläufen, die eigentlich Workflows hätten sein sollen. Diese Abläufe sind in Lucas eingeschlossen. Bitten Sie das Standard-Okou, einen Blogartikel zu veröffentlichen, kennt es keine dieser Regeln.

Mit der Zahl der Agenten wuchs auch die Zahl der Kombinationen. Viele Agenten, viele Workflows und viele Unterhaltungen greifen ineinander, und jede Kombination ist Logik, die wir pflegen und die Nutzer lernen müssen. Wir stießen auf Fragen, die wir aus Sicht der Nutzer nicht gut beantworten konnten:

• Warum können zwei Agenten nicht denselben Workflow nutzen?
• Warum kann ich in Slack nur mit Okou sprechen und nicht mit meinem eigenen privaten Agenten? Wenn Lucas eine Person ist, sollte ich ihn überall erreichen können.
• Warum teilen sich alle Agenten ein Gedächtnis? Wenn jeder Agent eine Person ist, sollte jeder ein eigenes Gedächtnis haben.

Jede dieser Fragen lässt sich lösen, aber jede kostet echten Entwicklungsaufwand. Bleiben sie ungelöst, bleibt Multi-Agent ein halbfertiges Erlebnis. Uns fiel es außerdem schwer, ein Problem zu finden, das sich nur mit mehreren Agenten lösen ließ. Viel häufiger hörten wir die Klage, es gebe zu viele Agenten zu verwalten.

Deshalb haben wir entschieden: Jede Person bekommt ein Okou. Das Modell ist einfacher:

• Jede Person hat ein Standard-Okou.
• Ihr Okou gehört Ihnen und ist privat.
• Ihr Okou und das Okou einer Kollegin oder eines Kollegen sind nicht derselbe Agent.
• Ihr Okou kann jeden Workflow nutzen, den jemand in Ihrer Organisation auf Public gestellt hat.

Was früher an einem Agenten hing, liegt jetzt dort, wo es besser hinpasst:

• Anweisungen gehören Ihnen. Sie schreiben einen einzigen Satz davon, und Okou hält sich daran, im Web, in Slack und in Automatisierungen.
• Workflows gehören dem Workspace. Jeder kann einen Public Workflow nutzen, den eine Kollegin oder ein Kollege veröffentlicht, und Sie können ihn kopieren und zu Ihrem eigenen machen.
• Verbundene Konten gehören Ihnen, Sie müssen also nicht mehr auswählen, welcher Agent Zugriff bekommt.
• Unterhaltungen werden in Projekten gebündelt, nach Kunde, Projekt oder Thema.

In diesem Modell ist ein Agent kaum mehr als ein Satz Anweisungen. Die drei Abläufe in Lucas sollten zu Workflows werden, die jeder nutzen kann.

Multi-Agent ist eigentlich eine Managementpraxis innerhalb einer Organisation, eine Art, zu steuern, was KI tun kann. Jede Organisation hat ihre eigenen Managementmethoden, und keine davon passt für alle. Ein einzelner Agent ist eher ein Werkzeug, und Werkzeuge sind leichter zu verstehen und einzuführen. Was Nutzer am dringendsten brauchen, ist, dass die Aufgabe erledigt wird. Danach kommt ein Werkzeug dafür. Am wenigsten brauchen sie eine Methode dafür.

Das Team Applied AI von Anthropic hat in einem aktuellen Beitrag über Agenten-Deployments in Unternehmen Ähnliches beobachtet. In ihren Vergleichen über mehrere Deployments hinweg schnitt ein einzelner Agent mit Skills bei der Qualität häufig besser ab als ein Aufbau aus spezialisierten Subagenten, und das oft bei geringeren Kosten und kürzerer Latenz pro Aufgabe. Sie schreiben außerdem: „Zu oft sehen wir, dass Unternehmen jedem Team oder jedem Problemtyp einen eigenen Subagenten geben, sodass die Agentenarchitektur zur Kopie ihres Organigramms wird.“ Ihr Beitrag handelt von Agentenarchitektur, nicht von Produktdesign, doch die Argumentation lässt sich übertragen.

Wenn wir uns heutige KI-Produkte ansehen, erkennen wir vier Modelle:

1. Viele Agenten, viele Unterhaltungen. Das war Okou.
2. Ein Agent, viele Unterhaltungen. So funktionieren ChatGPT, Codex und Claude Cowork.
3. Ein Agent, eine Unterhaltung. So funktioniert Instinct.
4. Viele Agenten mit jeweils einer einzigen Unterhaltung. So funktioniert Grok bot.

Wir hatten die komplexeste Kombination, und sie hat nicht mehr Probleme gelöst.

Uns ist bewusst, dass dies eine einschneidende Änderung ist. Zwei Dinge haben uns davon abgehalten, sie früher umzusetzen: dass wir Sie bitten, eine neue Arbeitsweise mit einem Okou plus Workflows zu lernen, und dass es keinen klaren Weg für das gab, was Sie bereits aufgebaut hatten. Hier ist dieser Weg:

• Ihre Unterhaltungen sind weiterhin da. Sie finden sie über Projekte, die Suche und ihre ursprünglichen Links.
• Wenn Sie Unterhaltungen mit verschiedenen Agenten sortiert haben, nutzen Sie stattdessen Projekte. Unterhaltungen nach Kategorie gebündelt zu halten, war für viele der Hauptgrund, zusätzliche Agenten anzulegen. Claude und ChatGPT lösen dasselbe Bedürfnis mit Projekten.
• Wenn Sie für verschiedene Agenten unterschiedliche Anweisungen geschrieben haben, übernehmen Sie das Gemeinsame in Ihre persönlichen Anweisungen und machen Sie aus den spezifischen Abläufen Workflows.

Je früher wir aufhören, Abstraktionen auf mehreren Agenten aufzubauen, desto besser. Wenn Sie Okou öffnen, müssen Sie nicht mehr entscheiden, welchen Agenten Sie fragen. Sagen Sie Okou, was erledigt werden soll, und Okou kümmert sich um den Rest.