KI als Nervensystem, nicht KI als Fabrik

„KI-nativ" ist das am stärksten verwässerte Wort im Engine-Markt von 2026. Hier ist die architektonische Trennlinie, die ein Chat-Panel von einer Runtime unterscheidet, in der das Modell in jedem Frame im Kreislauf mitläuft – die Linie, auf der RakuAI gebaut ist.

Die meisten Game-Engines und Spatial-Computing-Runtimes, die sich 2026 „KI-nativ” nennen, meinen ungefähr dasselbe. Irgendwo im Editor gibt es ein Chat-Panel. Es gibt einen Knopf, der ein entferntes Modell bittet, ein Asset zu generieren. Das Modell produziert ein Ding. Das Ding wird in ein Projekt eingefügt. Die Runtime, die es schon gab, bevor KI auftauchte, führt das Ding aus.

Das ist das Fabrikmuster. Eine Anfrage geht raus. Ein Artefakt kommt zurück. Die Engine ist der Konsument.

RakuAI ist nicht so gebaut. KI ist keine Station am Fließband. Sie ist ein Grundbaustein in der Runtime. Vom Geist her näher an einem Nervensystem als an einer Fabrik. Kontinuierlich präsent, im Kreislauf bei jedem Frame, beobachtend, entscheidend, reagierend. Sie zu entfernen entfernt kein Feature. Es entfernt das, was den Rest der Engine überhaupt sinnvoll macht.

Wenn Sie nur einen Beitrag darüber lesen, was „KI-nativ” auf der Architekturebene tatsächlich bedeutet, soll es dieser hier sein.

Zwei Muster, ausgebreitet

Hier ist das Fabrikmuster, verdichtet auf sein ehrliches Minimum:

# Factory: AI produces artifacts. The runtime consumes them.
def author_session(prompt: str) -> Asset:
    response = remote_model.generate(prompt)
    asset = parse(response)
    save_to_project(asset)
    return asset

Der Lebenszyklus ist einfach. Der Mensch tippt. Das Modell produziert. Eine Datei landet auf dem Datenträger. Die Runtime lädt die Datei später. Das Modell ist ein Inhaltslieferant. Die Runtime spricht nie wieder mit ihm, nachdem das Artefakt geliefert wurde. Geht das Modell offline, hat man trotzdem eine funktionierende Engine. Man hat nur eine Bezugsquelle für Assets weniger.

Jetzt hier das Nervensystem-Muster:

# Nervous system: AI is wired into the simulation step itself.
def step(world, agents, dt):
    for agent in agents:
        observation = agent.senses.gather(world)        # what is around me
        intent      = agent.brain.observe(observation)  # AI is in the loop
        action      = agent.policy.choose(intent, dt)   # constrained by deterministic rules
        world.apply(action)
    return world

Ein anderer Lebenszyklus. Bei jedem Frame, bei jedem Agenten trägt das Modell zum nächsten Zustand der Welt bei. Das Modell ist kein Lieferant. Es ist ein Teilnehmer. Entfernt man es, hört die Simulation auf, interessant zu sein, und zwar auf eine Weise, die keine Asset-Bibliothek überdecken kann.

Das sind zwei völlig verschiedene Architekturen. Die Wahl, die man auf dieser Ebene trifft, begrenzt alles darüber.

Was das Fabrikmuster einbringt

Ehrlichkeit zuerst. Das Fabrikmuster ist real, nützlich und wird heute ausgeliefert. Es bringt vier Dinge ein.

Es bringt Geschwindigkeit bei Inhalten. Einen Baum generieren, ein Gebäude, ein Level-Layout, eine Dialogzeile. Echte Produktivitätsgewinne, und das Artefakt-auf-Datenträger-Muster ist der einfachste Weg, sie zu bekommen.

Es bringt Anbieterunabhängigkeit. Weil das Artefakt auf dem Datenträger liegt, kann man austauschen, welches Modell es verfasst hat, ohne die Runtime zu ändern. Eine Absicherung, die sich lohnt.

Es bringt deterministische Wiedergabe. Das Artefakt ist fixiert, sobald es geschrieben ist. Zwei Spieler im selben Level sehen dasselbe Level.

Es bringt einen sauberen Fehlerfall. Ist das Modell nicht verfügbar, läuft die Engine trotzdem. Man verfasst nur weniger.

Das sind echte Gewinne. Wenn Ihr Produkt „Tools, die Menschen helfen, Spiele zu machen” ist, ist das Fabrikmuster wahrscheinlich die richtige Wahl. Die Kosten sind versteckt. Sie zeigen sich erst, wenn man versucht, etwas zu tun, das das Fabrikmuster nicht kann.

Was das Fabrikmuster nicht kann

Das Fabrikmuster kann keine Welt erzeugen, die auf den Spieler auf Weisen reagiert, die der Autor nicht vorhergesehen hat. Konstruktionsbedingt wurde jedes Artefakt in einer Fabrikmuster-Engine verfasst, bevor der Spieler ankam. Der Raum der Verhaltensweisen ist das kartesische Produkt aus der Artefakt-Bibliothek und der skriptgesteuerten Logik der Engine. Ein großer Raum, aber begrenzt. Die Grenzen sind im Spiel innerhalb einer Stunde sichtbar.

Das Fabrikmuster kann keine NPCs liefern, die sinnvoll über eine Welt nachdenken, in die sie nicht vorab geskriptet wurden. Steckt man ein LLM-gesteuertes Dialogsystem ein, bekommt man eine Art von Konversation, die lokal überzeugend und global träge ist. Der NPC wird neue Dinge sagen. Die Welt ändert sich nicht als Reaktion darauf. Das Dialogsystem und die Simulation sind zwei Züge auf parallelen Gleisen. Sie treffen sich nie.

Das Fabrikmuster kann die Erfahrung nicht an die tatsächlichen GPS-Koordinaten des tatsächlichen Nutzers anpassen, der an einem tatsächlichen physischen Ort steht. Dieser letzte Punkt ist der, der mich am meisten interessiert. Wenn man real-world-verankertes XR baut, bei dem die Erfahrung an einem bestimmten Punkt auf der Erde stattfindet, kann man nicht jede mögliche Interaktion vorab verfassen. Die Welt ist zu groß. Die Kontexte zu vielfältig. Der Weg des Spielers zu unvorhersehbar. Entweder man reagiert im Kreislauf, oder man liefert eine Reisebroschüre aus.

Das ist der strukturelle Grund, warum RakuAI keine Fabrik ist.

Was „Nervensystem” konkret einbringt

Drei Dinge, in der Reihenfolge, wie interessant sie werden.

Eins: NPCs, die beobachten, bevor sie sprechen. Wenn das Gehirn eines Agenten bei jedem Frame läuft, die Welt sieht, in der der Spieler sich tatsächlich befindet, und aufgrund dessen entscheidet, was zu tun ist, ist das Ergebnis qualitativ anders als ein Dialogbaum mit einem angeflanschten LLM. Der Agent kann auf den Regen reagieren. Auf die Tageszeit. Auf die Tatsache, dass der Spieler seit neunzig Sekunden vor ihm steht, ohne etwas zu tun. Nichts davon steht im Dialog. All das steckt in der Simulation, und das Modell liest die Simulation direkt.

Zwei: Erfahrungen, die sich um den Ort formen, an dem sie stattfinden. Die Engine selbst fragt das Modell ab. Gegeben dieses Gelände, dieses Wetter, diese Tageszeit, diese Menge an nahen Points of Interest – wie sollte die nächste Begegnung aussehen. Die Erfahrung ist keine Aufzeichnung mehr. Sie ist eine Funktion des tatsächlichen Kontexts des Spielers. Zwei Spieler in verschiedenen Städten, die dieselbe .raku-Erfahrung spielen, bekommen unterschiedliche Spielsitzungen, und beide sind stimmig.

Drei: Verhaltensweisen, die aus der Architektur entstehen. Das ist diejenige, die mich überrascht hat, als sie anfing aufzutauchen. Wenn KI ein Grundbaustein ist, wenn jedes System in der Engine sie aufrufen kann und seine Entscheidungen von ihr geformt werden, fangen die Systeme an, auf Weisen zu interagieren, die kein einzelner Subsystem-Autor entworfen hat. Ein Agent, der Gelände beobachtet, beeinflusst das Pathing-System. Pathing beeinflusst das Verhalten von Menschenmengen. Das Verhalten von Menschenmengen wird zum Input für die Beobachtung des nächsten Agenten. Schleifen entstehen. Manche davon sind interessant. Die interessanten sind der Grund, warum sich überhaupt jemand die Mühe mit dieser Architektur gemacht hat.

Der Preis, im Voraus bezahlt

Die Architektur hat einen Preis, und er ist nicht klein.

Man zahlt für Inferenz auf dem Gerät. KI, die auf dem kritischen Pfad der Simulation läuft, kann nicht bei jedem Frame einen Netzwerk-Roundtrip machen. Das bedeutet, Modellgewichte leben auf dem Gerät. Es bedeutet Quantisierung, Batching, sorgfältige Speicherbudgetierung und eine Deployment-Geschichte, die die Hardware des Spielers berücksichtigt. RakuAI ist um diese Beschränkung herum gebaut. Kleine Modelle, auf dem Gerät, nahe an der heißen Schleife. Die Beschränkung ist real und architektonisch.

Man zahlt für Zuverlässigkeitsdisziplin. Ein Modell, das innerhalb einer Content-Fabrik halluziniert, produziert einen seltsamen Baum. Ein Modell, das innerhalb des Simulationsschritts halluziniert, produziert eine seltsame Welt. Die Verträge zwischen der Modellschicht und der deterministischen Schicht müssen entworfen, validiert und geprüft werden. Das ist kein Nachgedanke. Das ist die Arbeit.

Man zahlt für Beobachtbarkeit, die man bei traditionellen Engines nicht umsonst bekommt. Wenn KI in jedem Frame ein Teilnehmer ist, muss man sehen, was sie tut, wann, mit welchen Eingaben, welche Ausgaben produzierend. Logging. Tracing. Replay. All die Dinge, die man für jedes verteilte System bauen würde, nur dass sie jetzt in der Simulationsschleife leben.

Diese Kosten sind der Grund, warum die meisten Engines das Fabrikmuster wählen. Das Fabrikmuster ist tatsächlich günstiger zu bauen. Es ist auch tatsächlich weniger interessant, auf eine Weise, die erst sichtbar wird, nachdem man Zeit in einer Engine verbracht hat, die die andere Wahl getroffen hat.

Wenn Sie ein Spiel, eine XR-Erfahrung oder ein anderes interaktives System bauen und sich fragen, ob die KI-Frage „welches Modell integriere ich” oder etwas Tieferes ist – die Antwort ist, dass es etwas Tieferes ist. Man spürt es beim ersten Versuch, das Fabrikmuster etwas tun zu lassen, wofür es nicht gebaut wurde.

Sonntagnachmittag, die Art von Beitrag, der aufgeschrieben werden wollte. Morgen zurück an die Engine.