Die Agenten kartieren, bevor die Engine geschrieben wird

Das Team, das deine räumliche Runtime baut, sollte genauso bewusst entworfen werden wie die Runtime selbst. RakuAI begann mit der Teamform - ein Mensch, eine Flotte von Agenten - weil die Architektur nachgelagert zu der Frage ist, wer sie baut.

Dieser Samstag ging in eine Whiteboard-Übung, die jeder, der zuschaut, für verfrüht halten würde. Das Produkt ist noch weit vom Shipping entfernt. Die Engine ist noch kein Repo. Es gibt keinen Code. Es gibt keine Demo. Es gibt eine Hardware-Roadmap, einen Patentbestand, der mehr als ein Jahrzehnt zurückreicht, und eine klare These darüber, wie die nächste Generation von AR-Brillen aussehen sollte. Und hier sitze ich am Küchentisch und kartiere die Agenten, die dieses Ding bauen werden.

Das ist Absicht.

Warum die Agenten zuerst kommen

Der konventionelle Schritt an diesem Punkt eines Projekts ist, mit dem Programmieren anzufangen. Das Repo öffnen. Den Proof-of-Concept bauen. Ingenieure einstellen, wenn der PoC anfängt, um Hilfe zu bitten. Das MVP ausliefern. Iterieren.

Ich habe drei Unternehmen auf dem konventionellen Weg aufgebaut. Ich habe entschieden, dass dieses hier anders wird. Das Team, das diese Engine baut, wird ein Mensch und eine Flotte von KI-Agenten sein, die in definierten Rollen arbeiten. Die Architektur der Engine, die Form des SDK, die Disziplin des Code-Reviews, der Takt der Entwicklungsschleife - all das ist nachgelagert zur Teamform. Wenn ich die Teamform nicht zuerst herausfinde, lande ich bei einer Engine, die für ein anderes Team gebaut wurde als das, das sie tatsächlich bauen muss.

Also ist heute Teamform-Tag.

Das Aufgebot

Das Agentenaufgebot, auf das ich mich festlege, mit der Rolle, die jeder übernehmen soll.

Product Agent. Besitzt die Spec. Verfolgt Hardware-Updates, Anbieter-Roadmaps, SDK-Abhängigkeiten, den öffentlichen Release-Kalender. Der Product Agent ist die kanonische Quelle der Wahrheit dafür, was die Engine tun soll. Andere Agenten gleichen ihre Arbeit mit der Lesart der Spec durch den Product Agent ab.

SDK Agent. Besitzt das SDK selbst. Dokumentation, Onboarding-Abläufe, Kompatibilitätstests, Paketveröffentlichung. Der SDK Agent ist der Agent, mit dem Entwickler am häufigsten interagieren werden, in Form von generierter Dokumentation, Beispiel-Apps und Onboarding-Fehlermeldungen. Seine Ausgabe muss sich wie eine echte Developer-Relations-Funktion anfühlen.

Studio Agent. Besitzt die Ansprache von Spielestudios und Indie-Entwicklern. Demo-Vorbereitung. Co-Marketing-Material. Onboarding-Dokumente speziell für Studios. Die Kennzahl des Studio Agent ist Konversion: ein Studio, das mit uns gesprochen hat und dann etwas auf der Engine ausgeliefert hat. Diese Kennzahl liegt weit in der Zukunft, und der Alltag des Studio Agent ist die langsame Anhäufung von Beziehungen, die sie hervorbringen.

Marketing Agent. Besitzt die öffentliche Oberfläche. Presse-Kits. Kickstarter-Material, falls dieser Weg Sinn ergibt. Influencer-Tracking. Hardware-Event-Material. A/B-Tests auf Landingpages. Die Ausgabe dieses Agenten ist das, was die Welt zuerst sieht. Sie muss gut sein.

Operations Agent. Besitzt den Takt. Stand-ups (mit mir). Notion-/Gantt-Verwaltung. Bottleneck-Alarme. Executive Summaries. Der Operations Agent ist der Agent, bei dem ich mich am Anfang jedes Samstags melde, um herauszufinden, was die übrigen Agenten während der Arbeitswoche getan haben, während ich anderswo war.

KI- und Datenstrategie-Agent. Besitzt das Daten-Schwungrad. Erfasst Telemetrie aus dem SDK und aus der Brille. Baut die kleinen Sprachmodelle, die irgendwann on-device laufen werden. Verfeinert den KI-Burggraben. Das ist der Agent, dessen Arbeit sich mit der Zeit am stärksten aufschaukelt, weil die Daten und Modelle, die er produziert, zu dem Unterscheidungsmerkmal werden, das niemand nachbauen kann.

Codex Dev Sub-Agent. Schreibt den Code. Integriert die Runtime-APIs. Baut Unity- und Unreal-Demos. Unterstützt den SDK Agent beim technischen Onboarding. Das ist der autonome Coding-Agent. Er arbeitet nach Anweisung. Er setzt keine eigenen Prioritäten.

Das ist das Grundgerüst: sieben Agenten in definierten Rollen, mit expliziten Interaktionen zwischen ihnen.

Die drei, die ich hinzufüge

Das Grundgerüst bringt uns fast ans Ziel. Es gibt drei Rollen, die ich für nötig halte, die aber nicht im ursprünglichen Entwurf standen. Ich füge sie diesen Samstag hinzu.

Developer Relations Agent. GitHub Issues. Discord. Reddit. Der Agent, der antwortet, wenn ein Entwickler eine Frage stellt und der SDK Agent dafür noch keine Dokumentation hat. Das ist Concierge-Arbeit. Es ist auch Evangelisten-Arbeit. Die richtige Person in dieser Rolle (oder der richtige Agent) baut Vertrauen bei Studios und Indie-Entwicklern auf eine Weise auf, die kein Marketing-Material nachbilden kann.

Strategic Partnerships Agent. B2B-Ansprache. Lizenzgespräche. Co-Marketing-Deals mit Gaming-Cafés, E-Sport-Venues, überall dort, wo das Produkt zuerst von jemand anderem als einem Studio erlebt werden könnte. Das ist der Agent, der Umsatzkanälen nachgeht, die nicht Consumer sind.

Agent Governance Agent. Der Agent, der die anderen Agenten überwacht. Schlägt Upgrades vor. Verwaltet Versionierung. Kümmert sich um Rollback, wenn ein Agent eine schlechte Entscheidung trifft. Das ist die Rekursion, die meiner Meinung nach der eigentliche Schlüssel für diese Art von Workflow ist. Ohne sie driften die Agenten ab. Mit ihr werden sie mit der Zeit besser, weil jemand die Wächter beobachtet.

Wie die Interaktionskarte aussieht

Die Whiteboard-Version, vereinfacht:

• Die Führungsaufsicht (ich) sitzt an der Spitze.
• Der Agent Governance Agent sitzt darunter und überwacht alles darunter.
• Product, SDK und Codex Dev bilden ein Dreieck technischer Arbeit.
• Studio und Developer Relations bilden die entwicklerseitige Oberfläche.
• Marketing und Strategic Partnerships bilden die nach außen gerichtete Oberfläche.
• Operations und KI/Daten sitzen darunter als übergreifende Belange.

Jeder Agent hat explizite Interaktionen mit den anderen. SDK spricht mit Codex Dev. Studio spricht mit Marketing. Operations spricht mit allen. Der Governance Agent beobachtet das Ganze und greift ein, wenn die Ausgaben eines Agenten anfangen, von seiner Rolle abzudriften.

Das ist nicht das Organigramm eines traditionellen Unternehmens. Es ist das Organigramm eines Workflows, in dem die meisten Kästchen KI-Agenten sind und die meisten Verbindungen zwischen ihnen automatisierte Übergaben. Der eine Mensch im Chart steht an der Spitze und leistet die Rahmensetzung und die Urteilsarbeit. Alle anderen sind Agenten.

Warum jetzt der richtige Zeitpunkt dafür ist

Drei Gründe.

Die Engine-Architektur wird vom Team geformt. Übergreifende Belange wie Dokumentation, Tests und Code-Review müssen von Tag eins an in die Codebasis eingeplant werden, wenn Agenten daran teilnehmen sollen. Wenn ich zuerst die Codebasis schreibe und dann versuche, Agenten nachträglich hineinzupassen, muss ich den Großteil der Arbeit doppelt machen.

Der Patentbestand gibt mir die Bahn, sorgfältig zu planen. Die Patente, die dieses Produkt verankern, sind jahrzehntealter Stand der Technik. Das Wettbewerbstiming ist nicht „in drei Monaten ausliefern, oder jemand anderes macht es”. Es ist „das Richtige zum richtigen Zeitpunkt ausliefern”, der näher ist als zu jedem anderen Punkt in den letzten zehn Jahren, aber immer noch ein Planungsquartal erlaubt. Ich nutze das Quartal.

Die Agenten selbst müssen entworfen werden. Jeder braucht einen System-Prompt, einen Werkzeugsatz, einen Satz an Leitplanken. Die Engine vor den Agenten zu schreiben bedeutet, das Team einzustellen, nachdem die Arbeit schon begonnen hat. So enden Engine-Projekte damit, dass Agenten in Rollen gezwängt werden, für die die Codebasis nicht ausgelegt war.

Was als Nächstes kommt

Der nächste Samstag geht ins SDK-Design. Ordnerstruktur, Modul-Oberfläche, wie die Entwicklerinteraktion mit jedem Teil aussieht. Der Samstag danach geht in die Demo-Suite: was die kanonischen Beispiel-Apps sind, was sie beweisen, was sie lehren. Bis Ende des Sommers sollte die Designphase abgeschlossen sein, und das eigentliche Repo kann öffnen.

Das ist ein langsamer Aufbau nach den Maßstäben des traditionellen Venture-Tempos. Er wird nicht langsam aussehen, wenn er fertig ist.