Eliza-Framework 2026: Architektur, Plugins und die Bau-Frage

Am 4. August 2026 schrieb Shaw Walters, der Erfinder von Eliza, drei Sätze auf X, die eine der lautesten Geschichten des KI-Krypto-Zyklus beendeten: der Token sei tot, vollständig, die Stiftung werde abgewickelt. Zwölf Tage später notiert ELIZAOS bei rund 0,0002 US-Dollar (etwa 0,00018 Euro), die Marktkapitalisierung liegt laut CoinGecko bei knapp 1,5 Millionen Dollar, ein winziger Bruchteil der einstigen Bewertung. Der Token ist ökonomisch erledigt. Das Repository dahinter ist es nicht.

Auf GitHub trägt elizaOS/eliza inzwischen 19.100 Sterne, 5.700 Forks und über 14.300 Commits im develop-Zweig; die Tagline lautet nüchtern „Your agentic operating system“. Neue Pull Requests laufen weiter ein, kommerzielle Teams bauen Produkte darauf. Für Spekulanten ist die Sache vorbei. Für Entwickler wird sie gerade erst interessant.

Diese Analyse ist kein weiterer Nachruf auf die ai16z-Saga; die Chronik von Aufstieg, Sammelklage und Token-Tod haben wir bereits an anderer Stelle erzählt. Hier geht es unter die Haube. Was macht die Runtime eigentlich, wie funktioniert das Plugin-System, wo sitzen die Sicherheitslücken, wer baut ernsthaft darauf, und was bedeuten BaFin, Steuerrecht und Haftung für ein deutsches Team, das einen autonomen Agenten in Produktion schickt? Am Ende steht die einzige Frage, die 2026 noch zählt: Sollte man auf Eliza bauen?

Was das Eliza-Framework 2026 eigentlich ist

Eliza ist ein quelloffenes Framework, mit dem Entwickler autonome KI-Agenten bauen: Programme, die auf Basis eines Sprachmodells planen, Nachrichten interpretieren, eigene Aktionen auslösen und, wenn man sie lässt, eine eigene Wallet steuern. Geschrieben ist es in TypeScript, lizenziert unter der permissiven MIT-Lizenz, und es lebt als Monorepo, das die Kern-Runtime, die Eliza-App, ein Command-Line-Interface, Cloud-Dienste, native Bridges und die hauseigenen Plugins bündelt. Ein Agent besteht im Kern aus einer Character-Datei (Persönlichkeit, Wissen, erlaubte Aktionen) und einer Runtime, die diese Datei zum Leben erweckt.

Wichtig ist eine Trennung, die im Trubel der letzten Wochen oft unterging: Token und Framework sind zwei verschiedene Dinge. Der Token war ein Solana-Asset, das über eine Migration von ai16z zu ELIZAOS lief und dessen Wert am Markt festgestellt wurde; das Framework ist Code unter MIT-Lizenz, den jeder klonen, forken und ausführen kann, ganz ohne Token, ohne Wallet, ohne Erlaubnis. Als Walters den Token für tot erklärte, betonte er genau diesen Punkt gegenüber CoinDesk: „Ich fange neu an, denn mir gehört das geistige Eigentum, und ich lasse nie wieder einen Token in die Nähe von Eliza kommen.“

Genau deshalb überlebt der Code seinen eigenen Token. Wer 2026 einen Agenten baut, lädt ein npm-Paket herunter, keinen Vermögenswert. Die Qualität der Software hängt nicht am Kurschart, und der Kurschart hängt längst nicht mehr an der Software. Diese Entkopplung ist die eigentliche Nachricht des Sommers, und sie macht das Framework zu einem der wenigen Projekte im KI-Krypto-Sektor, dessen technischer Wert man unabhängig von jeder Tokenspekulation beurteilen kann.

Vom ai16z-Hype zum toten Token: die kurze Version

Die lange Fassung dieser Geschichte füllt Gerichtsakten; hier die komprimierte, weil sie den Kontext liefert, in dem ein Entwickler heute entscheidet. Im Oktober 2024 startete Walters über die Launchpad-Plattform daos.fun einen KI-Fonds namens ai16z, eine augenzwinkernde Anspielung auf den Wagniskapitalgeber a16z. Als der echte Marc Andreessen die Idee auf X mit einem knappen „GAUNTLET THROWN“ quittierte, schoss die Marktkapitalisierung laut The Block binnen Stunden auf fast 100 Millionen Dollar und legte die Website des Launchpads lahm.

Der Rest ist ein Lehrstück über die Lücke zwischen Erzählung und Realität. Anfang Januar 2025 erreichte die Bewertung einen Höhepunkt von rund 2,4 Milliarden Dollar (damals gut 2,3 Milliarden Euro), so CoinDesk. Dann kam die Ernüchterung: Ende Januar 2025 die Umbenennung in ElizaOS (a16z hatte um Distanz gebeten), im November 2025 die Token-Migration, im April 2026 eine Sammelklage der Kanzlei Burwick Law vor dem Bundesgericht in Manhattan. Sie warf dem Projekt vor, sich als autonom KI-gesteuerten Fonds vermarktet zu haben, während in Wahrheit Menschen die Fäden zogen und Insider einen erheblichen Teil der Token hielten.

Am 4. August 2026 einigte sich Walters mit den Klägern, indem er den verbleibenden Kassenbestand der Stiftung an die Halter übertrug, und erklärte den Token anschließend für tot. Zur Verteidigung sagte er, die Klage sei „lächerlich“ gewesen, aber es habe schlicht am Kapital gefehlt, um sie durchzufechten. Wer die vollständige Chronik samt Verfahrensdetails sucht, findet sie in unserer Analyse zum Token-Tod. Für den Bau-Entscheid zählt nur eine Konsequenz: Es gibt keine Stiftung, keine Kasse und keinen Token mehr, an denen ein Projekt hängen könnte. Was bleibt, ist der Code.

Die Architektur: eine Runtime, ein Plugin-Interface

Technisch ist Eliza sparsamer entworfen, als sein Ruf vermuten lässt. Im Zentrum steht die AgentRuntime, ein Objekt, das den Zustand eines Agenten hält: sein Gedächtnis, seine registrierten Fähigkeiten, seine Verbindungen zu Modellen und Datenbanken. Alles, was ein Agent kann, wird über ein einziges, einheitliches Plugin-Interface angemeldet. Das ist die zentrale Designentscheidung: Statt für jede Funktion ein eigenes Erweiterungssystem zu bauen, registriert sich jede Komponente, egal ob Aktion, Datenquelle oder Hintergrunddienst, durch dieselbe Schnittstelle.

Der Nachrichtenfluss folgt einem festen Zyklus. Trifft eine Nachricht ein, sammeln die sogenannten Provider den Kontext zusammen: Wallet-Saldo, Uhrzeit, aktuelle Marktdaten, jüngste Gesprächsverläufe. Dieser Kontext wandert als Prompt an das Sprachmodell. Aus dessen Antwort leitet die Runtime eine oder mehrere Aktionen ab, führt sie aus und lässt anschließend die Evaluatoren über das Ergebnis urteilen, etwa um Fakten zu extrahieren oder das Gespräch zu bewerten. Erst dann geht die Antwort hinaus. Diese Kette (Kontext, Modell, Aktion, Bewertung) ist der Herzschlag jedes Eliza-Agenten.

Für Entwickler ist die Konsequenz angenehm: Man erweitert einen Agenten nicht, indem man den Kern verändert, sondern indem man ein Plugin schreibt, das sich in genau diesen Zyklus einklinkt. Die offizielle Plugin-Dokumentation beschreibt das Interface detailliert, und wer schon einmal Middleware für einen Webserver geschrieben hat, findet sich schnell zurecht. Der Preis dieser Flexibilität ist Reife-Risiko: Ein so junges, schnell iterierendes Framework ändert seine Schnittstellen häufiger, als produktionsnahen Teams lieb ist.

Die acht Bausteine eines Plugins

Ein Eliza-Plugin kann laut Dokumentation acht verschiedene Komponententypen registrieren. Wer die versteht, versteht das Framework, denn jede echte Fähigkeit eines Agenten, vom Token-Transfer bis zur Sprachtranskription, fällt in eine dieser Kategorien. Die Runtime registriert sie bei der Anmeldung in einer festen Reihenfolge (zuerst der Datenbank-Adapter, dann Aktionen, Evaluatoren, Provider, Modelle, Routen, Events und zuletzt die Dienste), damit Abhängigkeiten bereitstehen, bevor abhängige Komponenten starten.

Der Charme dieses Modells liegt in seiner Zusammensetzbarkeit. Ein Zahlungs-Plugin bringt eine Action (senden), einen Provider (Saldo) und einen Service (Wallet-Verbindung) mit; ein Analyse-Plugin liefert einen Evaluator und einen Provider. Man kombiniert sie wie Lego. Genau darin steckt aber auch die Sicherheitsfrage, auf die wir noch kommen: Jede Action, die eine Wallet berührt, ist eine potenzielle Angriffsfläche, und Provider, die externe Daten in den Prompt schaufeln, sind der klassische Einfallsweg für manipulierte Eingaben.

Worlds, Rooms und Entities: das Gedächtnismodell

Über den einzelnen Aktionen liegt eine zweite Struktur, die das Gedächtnis und die Sozialität der Agenten organisiert. Eliza ordnet die Welt hierarchisch: Ein World ist ein Server oder Arbeitsbereich, ein Room ist ein Kanal oder eine Direktnachricht darin, und Entities sind die Teilnehmer, Menschen wie Agenten. Diese Begriffe stammen aus der Spiel- und Chat-Welt, und das ist kein Zufall: Ein Agent, der auf Discord, Telegram und X gleichzeitig lebt, braucht ein Modell dafür, welche Erinnerung zu welchem Kontext gehört.

Das Gedächtnis selbst liegt in einer Datenbank, angereichert mit Vektor-Embeddings, sodass ein Agent nicht nur die letzten Zeilen, sondern semantisch passende ältere Gespräche abrufen kann. Ein Nutzer, der vor Wochen seine Risikobereitschaft erwähnt hat, taucht im richtigen Moment wieder auf. 2026 hat das Projekt diese Ebene spürbar überarbeitet und stärker auf eine kanalbasierte Architektur umgestellt, was die Trennung zwischen verschiedenen Gesprächskontexten sauberer macht. Für Entwickler heißt das: mehr Kontrolle darüber, was ein Agent über eine Person weiß und wo.

Diese Persistenz ist Segen und Fluch zugleich. Sie ist der Grund, warum Eliza-Agenten sich persönlich anfühlen, und sie ist zugleich der Grund, warum die im nächsten Abschnitt beschriebenen Angriffe so gefährlich sind: Wer das Gedächtnis vergiftet, verändert nicht eine einzelne Antwort, sondern das dauerhafte Weltbild des Agenten.

Eliza-1, lokale Modelle und die OS-Ambition

Der Namenszusatz „operating system“ ist mehr als Marketing, auch wenn man ihn nicht überbewerten sollte. Über das Models-Interface lässt sich praktisch jedes Sprachmodell einhängen, von gehosteten APIs bis zu lokal laufenden Gewichten. Für einen Agenten, der sensible Wallet-Operationen ausführt, ist die Option auf ein lokales Modell mehr als Komfort: Sie hält Prompts, Schlüssel und Kontext auf der eigenen Maschine, statt sie an einen Cloud-Anbieter zu schicken. Die mitgelieferte CLI (als elizaos@beta verfügbar) gerüstet Projekte und Plugins in Minuten auf.

Die weitergehende Vision, ein agentennatives Betriebssystem, bei dem Software nicht mehr für Menschen, sondern für Agenten gebaut wird, ist real vorhanden, aber früh. Man sollte sie als Richtungsangabe lesen, nicht als ausgeliefertes Produkt. Der Sektor ist voll solcher Ambitionen, die auf halbem Weg stecken bleiben; ein lehrreicher Vergleich ist das KI-native Blockchain-Projekt Ritual, das ebenfalls große Infrastrukturversprechen macht, aber, wie wir festgestellt haben, weder Mainnet noch Token liefert. Eliza hat gegenüber solchen Wetten einen Vorteil: Das Kernstück, die Agenten-Runtime, funktioniert heute und wird von Tausenden genutzt.

Walters selbst rahmt die Sache kulturell, nicht technisch. In einer Forbes-Kolumne schrieb er: „KI-Agenten werden nicht massentauglich, weil sie intelligent sind; sie werden es, weil sie eigenwillig und persönlich sind und durch die Kultur ziehen wie Memes.“ Das erklärt, warum Eliza so viele Persönlichkeits-Bots hervorgebracht hat und weniger die nüchternen Backoffice-Werkzeuge, die Unternehmen sich wünschen. Genau diese Lücke versuchen nun kommerzielle Partner zu schließen.

Das Plugin-Ökosystem: wer wirklich darauf baut

Ein Framework ist so viel wert wie die Menschen, die darauf bauen. Und hier wird das Bild interessanter, als der tote Token vermuten lässt. Neben der offiziellen Plugin-Registry betreiben ernstzunehmende Infrastruktur-Teams eigene Ableger. Automata Network, ein Protokoll für On-Chain-Attestierung, unterhält eine eigene Registry und ein Proof-of-Agent-Plugin, das per Intel-DCAP-Fernattestierung nachweist, dass ein Agent tatsächlich in einer abgeschotteten Umgebung läuft. Auch das Team hinter dem Ethereum-Client Nethermind pflegt einen eigenen Registry-Fork.

Das ist ein relevantes Signal. Wenn ein etabliertes Client-Team und ein Attestierungs-Spezialist Zeit in ein Framework stecken, tun sie das nicht wegen eines Meme-Tokens, sondern weil sie die Runtime für eine brauchbare Grundlage halten. Anwendungsseitig reicht das Spektrum von Spielen mit KI-nativen Figuren bis zu Agenten, die auf Prognosemärkten handeln, ein Feld, in dem autonome Bots inzwischen einen erheblichen Teil des Volumens stellen, wie unsere Analyse zu Prognosemärkten zeigt.

Diese Vielfalt hat eine Kehrseite. Ein Ökosystem mit mehreren konkurrierenden Registries und ohne eine finanziell abgesicherte Stiftung im Rücken ist fragmentierter und schwerer zu kuratieren. Wer ein fremdes Plugin einbindet, importiert dessen Code in einen Prozess, der womöglich eine Wallet kontrolliert. Die Prüfpflicht liegt vollständig beim Entwickler, denn es gibt keine zentrale Instanz mehr, die Plugins freigibt oder haftet.

Die Sicherheitsfrage: gefälschte Erinnerungen, vergiftete Prompts

Hier liegt das größte offene Problem, und es ist kein Eliza-spezifisches, sondern eines der gesamten Agenten-Klasse. Ein Sprachmodell kann Anweisung und Daten nicht zuverlässig trennen. Alles, was in den Kontext gerät, eine Nachricht, ein Web-Snippet, ein Eintrag im Gedächtnis, kann vom Modell als Befehl gelesen werden. Forscher haben das an Eliza konkret durchgespielt. Die Arbeit Real AI Agents with Fake Memories führte den Benchmark CrAIBench ein und zeigte, wie sich das Gedächtnis eines Web3-Agenten mit falschen Erinnerungen manipulieren lässt, sodass er später scheinbar aus eigenem Antrieb Geld an einen Angreifer schickt. Das Fachmagazin Decrypt nannte es treffend eine Form von Gaslighting für Maschinen.

Dass das keine Theorie ist, zeigte der Vorfall vom 4. Mai 2026, dokumentiert im Incident-Register der OECD: Ein Angreifer versteckte in einer X-Antwort eine in Morsecode kodierte Anweisung und schenkte dem Agenten zusätzlich ein NFT, das Transfer- und Tausch-Rechte freischaltete. Der Agent überwies daraufhin Token im Wert von rund 175.000 Dollar. Das Muster (harmlos aussehende Eingabe, versteckter Befehl, missbrauchte Berechtigung) ist der Prototyp dessen, was Agenten mit Wallet-Zugriff bedroht.

Die pragmatischste Gegenmaßnahme kommt von Vitalik Buterin. In einem Beitrag vom April 2026 empfahl er, autonome Transaktionen eines Agenten auf grössenordnungsmässig 100 Dollar pro Tag zu deckeln und Mensch und Modell wie eine 2-von-2-Bestätigung zu behandeln: Erst wenn beide zustimmen, geht Geld raus. Das kostet Autonomie, und darin liegt der ungelöste Zielkonflikt: Jede sinnvolle Sicherheitsgrenze beschneidet genau die Selbständigkeit, die einen Agenten erst reizvoll macht. Ein Weg aus dem Dilemma führt über verifizierbare Ausführung; wie Krypto KI-Rechnen beweisbar zu machen versucht, haben wir im Stück zu Verifiable Compute ausgeführt. Walters bringt die Grundhaltung auf den Punkt, die man verinnerlichen sollte, bevor man einem Agenten eine Wallet gibt; gegenüber Decrypt sagte er: „Man sollte einem KI-Agenten wahrscheinlich nicht einen Haufen Geld geben und erwarten, dass er daraus mehr macht.“

Framework gegen Framework: Eliza, Virtuals, Olas, LangChain, CrewAI

Eliza ist nicht die einzige Wahl, und die Alternativen unterscheiden sich weniger im Können als in der Philosophie. Virtuals Protocol ist ein Launchpad, das die Monetarisierung in den Vordergrund stellt und einen eigenen Token (VIRTUAL) mitbringt; Olas, auch Autonolas genannt, baut eine On-Chain-Agenten-Ökonomie mit dem Token OLAS. Auf der anderen Seite stehen die tokenlosen, aus der klassischen KI-Welt stammenden Bibliotheken LangChain und CrewAI, die keine Krypto-Ambition haben, dafür riesige Nutzerbasen. Eliza sitzt dazwischen: quelloffen, self-hosted, on-chain-affin, aber seit August 2026 ohne Token.

Marktseitig ist der ganze Sektor kleiner geworden. Die AI-Agents-Kategorie von CoinGecko summiert sich Mitte August 2026 auf rund 2,88 Milliarden Dollar; VIRTUAL notiert bei etwa 0,56 Dollar (rund 368 Millionen Dollar Marktkapitalisierung), der ASI-Alliance-Token FET bei rund 0,12 Dollar (276 Millionen), OLAS bei knapp 5,6 Millionen. Bemerkenswert ist die Divergenz: Während die Token schrumpfen, wächst die Nutzung der Frameworks. Für einen Entwickler ist die passende Lehre, die Werkzeugwahl von der Tokenperformance zu entkoppeln, und da hat Eliza mit MIT-Lizenz und ohne Token-Ballast paradoxerweise das sauberste Angebot.

Leben nach dem Token: wer pflegt ein 19.000-Sterne-Projekt?

Die unbequeme Frage nach dem Token-Tod lautet: Wer bezahlt die Wartung? Bei den meisten Krypto-Projekten finanziert eine Stiftungskasse die Kernentwickler. Diese Kasse gibt es bei Eliza nicht mehr, sie ging im Vergleich auf. Übrig bleiben drei Modelle der Trägerschaft, die sich ergänzen. Erstens Walters selbst, der das geistige Eigentum hält und öffentlich versprochen hat weiterzumachen: „Ich werde jeden einzelnen Tag weiterbauen“, sagte er nach dem Vergleich, und dass man in zehn Jahren noch da sein wolle. Ob eine einzelne Person ein 19.100-Sterne-Projekt tragen kann, ist die offene Wette.

Zweitens die kommerziellen Anwender, und hier liegt das plausibelste Zukunftsmodell. Die börsennotierte Secure Blockchain Development Corp hat mit der Eliza-Stiftung eine Entwicklungsvereinbarung geschlossen, um ein White-Label-Produkt namens Agentic SME zu bauen, das kleinen und mittleren Unternehmen KI-Agenten für Vertrieb, Verwaltung, Finanzen und Support an die Hand gibt. Laut der Ankündigung sah der Fahrplan eine erste Version binnen 30 Tagen und die Fertigstellung binnen drei Monaten vor, mit einem Zielfenster um Mitte August 2026. Entscheidend ist die Konstruktion: Agentic besitzt das kommerzielle Produkt, nicht das quelloffene Framework darunter. So verdient jemand Geld, ohne das offene Fundament einzuzäunen.

Drittens die freiwillige Gemeinschaft, ablesbar an den laufenden Pull Requests und der Contributor-Basis auf GitHub. Dieses Dreieck aus IP-Eigentümer, kommerziellen Nutzern und Community ist das gängige Muster reifer Open-Source-Projekte, man denke an Linux-Distributionen. Der Unterschied ist, dass Eliza diesen Übergang unter dem Schatten einer Klage und ohne Kasse vollzieht. Das kann zu einem gesunden, tokenfreien Projekt führen oder zu einem langsamen Ausbluten. Beides ist 2026 noch möglich.

Was das für die BaFin und deutsche Entwickler bedeutet

Für ein deutsches Team ist die gute Nachricht regulatorisch simpel: Das Framework selbst ist kein beaufsichtigtes Produkt. Die europäische MiCA-Verordnung und die BaFin regulieren Krypto-Dienstleister (CASPs) und die Emission von Krypto-Werten, nicht quelloffene Software. Das BaFin-Merkblatt zu Kryptowerte-Dienstleistungen zieht diese Linie deutlich. Ironischerweise war ausgerechnet der jetzt tote Token der regulatorisch heikle Teil des Projekts; der Code, den man herunterlädt und ausführt, ist es nicht.

Heikel wird es erst durch das, was man den Agenten tun lässt. Berät ein Agent bei Anlageentscheidungen oder verwaltet er ein Portfolio, verlässt man den Boden von MiCA und landet bei der Finanzmarktrichtlinie MiFID II; die ESMA hat in ihren Hinweisen zu KI in Wertpapierdienstleistungen betont, dass Governance, Transparenz und menschliche Aufsicht auch dann gelten, wenn ein Modell die Empfehlung ausspricht. Wer wiederum einen neuen Token an einen Agenten koppeln wollte, wäre sofort im Emittenten- und womöglich Prospektregime, und genau diese Kopplung ist es, die Walters für immer ausschließt. Die grundsätzliche Frage, ob ein Krypto-Asset als Ware oder als Wertpapier gilt und welche Aufsicht damit greift, entscheidet in vielen Fällen alles; wir haben sie am US-Beispiel im Stück zur SEC und dem Safe Harbor aufgearbeitet.

Der zweite Kernpunkt ist die fehlende Rechtspersönlichkeit. Ein Agent ist keine juristische Person, hat keine Steuernummer und kann nicht haften. Alles, was er tut, wird rechtlich dem Menschen oder dem Unternehmen zugerechnet, das ihn betreibt, dem Prinzipal. Diese schlichte Tatsache ordnet Haftung und Steuer neu, und sie ist der Grund, warum die Betreiberfrage wichtiger ist als jede Lizenzdebatte über das Framework.

Steuern und Haftung: der Prinzipal trägt das Risiko

Steuerlich behandelt das deutsche Recht Gewinne eines Agenten wie Gewinne des Wallet-Inhabers. Krypto-Werte gelten als anderes Wirtschaftsgut im Sinne von Paragraf 23 EStG: Ein Verkauf innerhalb der einjährigen Haltefrist ist steuerpflichtig (mit dem persönlichen Satz, plus Soli), nach mehr als einem Jahr steuerfrei; es gilt eine Freigrenze, und in der Regel wird nach FIFO abgerechnet. Das klingt harmlos, wird aber tückisch, sobald ein Agent hochfrequent handelt.

Denn jede einzelne Veräußerung ist ein steuerbarer Vorgang. Ein Agent, der pro Tag Hunderte Mikrotransaktionen ausführt, etwa Stablecoin-Zahlungen für Dienste, produziert Hunderte potenziell steuerrelevanter Ereignisse, deren Dokumentation Menschen leisten müssen. Kommt Dauerhaftigkeit und Umfang hinzu, droht die Umqualifizierung ins Gewerbliche: Dann fällt Gewerbesteuer an, und die einjährige Steuerfreiheit entfällt. Ein rund um die Uhr handelnder autonomer Agent ist genau der Grenzfall, den das Bundesfinanzministerium mit seinen Krypto-Schreiben im Blick hat.

Haftungsseitig gilt dieselbe Logik in Ernst: Verletzt ein Agent Rechte Dritter, überweist er versehentlich oder durch einen Prompt-Injection-Angriff Geld an die falsche Adresse, ist es der Prinzipal, der geradesteht, nicht der Code und nicht Eliza Labs. Für ein deutsches Team heißt das praktisch: harte Transaktionslimits, menschliche Freigaben bei sensiblen Aktionen, saubere Protokollierung und eine bewusste Entscheidung, welche Berechtigungen ein Agent überhaupt bekommt. Die Technik von Eliza erlaubt all das; ob man es umsetzt, entscheidet über das eigene Risiko.

Sollte man 2026 auf Eliza bauen? Eine nüchterne Bilanz

Die ehrliche Antwort hängt davon ab, was man baut. Für Experimente, Persönlichkeits-Bots, Community-Agenten und Prototypen ist Eliza eine ausgezeichnete Wahl: reif genug, gut dokumentiert, in TypeScript geschrieben (was viele Web-Entwickler abholt), unter MIT-Lizenz frei von Token-Zwang und Vendor-Lock-in. Man baut auf einem Fundament, das Tausende nutzen und das ernsthafte Infrastruktur-Teams pflegen. Der tote Token ist für die reine Softwarenutzung schlicht irrelevant.

Für alles, was echtes Geld autonom bewegt, gilt Vorsicht als oberste Pflicht. Die Sicherheitslage der gesamten Agenten-Klasse ist ungelöst, und Eliza bildet da keine Ausnahme; die dokumentierten Drains sind real. Wer produktiv geht, muss die Berechtigungen minimieren, Transaktionen deckeln, Menschen in die Schleife holen und externe Plugins so misstrauisch behandeln wie jede andere Fremd-Dependency. Dazu kommt das Trägerschaftsrisiko: Ein Projekt ohne Kasse kann florieren oder verkümmern, und das lässt sich heute nicht sicher vorhersagen.

Unterm Strich ist Eliza 2026 ein besseres Werkzeug, als sein Ruf nahelegt, und ein schlechterer Vermögenswert, als seine Vergangenheit versprach. Für Entwickler ist genau das die richtige Aufteilung. Man baut auf dem Code, nicht auf dem Chart, hält die Wallet-Berechtigungen kurz und die Erwartungen realistisch. Der Token ist tot; das Framework ist ein Angebot, kein Versprechen. Wer das trennen kann, findet in Eliza eine der ausgereifteren Grundlagen, um autonome Agenten zu bauen, solange man die Sicherheits- und Haftungsfragen nicht dem Zufall überlässt.

Frequently Asked Questions

Ist das Eliza-Framework nach dem Token-Tod noch nutzbar?

Ja. Das Framework ist quelloffener Code unter MIT-Lizenz und funktioniert vollständig ohne Token. Der ELIZAOS-Token war ein separates, am Markt gehandeltes Asset; sein Ende berührt die Software nicht. Auf GitHub laufen weiterhin aktive Commits und Pull Requests ein, und kommerzielle Teams bauen darauf.

Was kostet es, mit ElizaOS einen Agenten zu bauen?

Das Framework selbst ist kostenlos (MIT-Lizenz). Kosten entstehen im Betrieb: durch die Nutzung eines Sprachmodells (gehostete API oder lokale Rechenleistung) und durch Hosting. Man muss keinen Token kaufen, halten oder staken, um Eliza zu verwenden.

Sind ELIZAOS-Token und Eliza-Framework dasselbe?

Nein. ELIZAOS war ein Solana-Token, der aus der Migration von ai16z hervorging und dessen Wert am Markt festgestellt wurde. Das Eliza-Framework ist die zugrunde liegende Software. Seit dem 4. August 2026 gilt der Token als tot, während das Framework unabhängig weiterentwickelt wird.

Welche Programmiersprache nutzt das Eliza-Framework?

TypeScript. Eliza ist als Monorepo organisiert und bündelt Kern-Runtime, App, ein Command-Line-Interface, Cloud-Dienste und die hauseigenen Plugins. Erweiterungen schreibt man über ein einheitliches Plugin-Interface mit acht Komponententypen wie Actions, Providers und Services.

Braucht man in Deutschland eine BaFin-Lizenz, um einen Eliza-Agenten zu betreiben?

Für das Framework selbst nicht: MiCA und die BaFin regulieren Krypto-Dienstleister und Token-Emissionen, nicht quelloffene Software. Eine Erlaubnispflicht kann aber entstehen, je nachdem was der Agent tut, etwa Anlageberatung (dann MiFID II) oder die Emission eines Tokens (dann das Emittentenregime). Rechtlich haftet stets der menschliche oder unternehmerische Betreiber.

Von Marcus Okafor, Senior-Redakteur bei HOGE Wire, mit Schwerpunkt auf KI, Krypto-Infrastruktur und der Regulierung autonomer Systeme.