Die KI, die ihre eigene Arbeit prüft

Es gibt einen Fehlerfall, den niemand in die Demo packt. Du bittest einen KI-Agenten, deiner Startseite einen Abschnitt hinzuzufügen. Er ruft die API auf, schreibt den Inhalt und meldet zurück: „Fertig — ich habe den Preis-Abschnitt eingefügt." Du glaubst ihm. Zwei Tage später schreibt dir ein Besucher, dass die halbe Seite leer ist, weil eine Template-Referenz falsch geschrieben war und der ganze Block still zu nichts gerendert hat.

Der Agent hat nicht gelogen. Er hat den Inhalt tatsächlich geschrieben. Er hat nur nie auf das Ergebnis geschaut — weil er das in den meisten KI-und-CMS-Setups gar nicht kann. Er schreibt in eine Blackbox und bekommt ein „OK" zurück. Ob die Seite wirklich rendert, ob das Layout hält, ob das, was ein Mensch sähe, richtig ist — nichts davon kommt über die API zurück.

Genau diese Lücke ist der Grund, warum wir die Prüfung in Neleto eingebaut haben, statt sie dem Zufall zu überlassen. Ein Agent, der an deiner Website arbeitet, bekommt drei Wege, seine eigene Arbeit zu prüfen, bevor er dir sagt, dass er fertig ist.

Das Problem mit „abschicken und vergessen"

Wenn ein Headless-CMS einem Agenten eine API reicht, endet der Vertrag bei „Inhalt angenommen". Das Rendering passiert woanders — ein separates Frontend, ein separater Build — also hat das System, mit dem der Agent spricht, keine Ahnung, was der Besucher am Ende sieht. Der Agent kann perfekt gehorsam sein und trotzdem eine kaputte Seite ausliefern, weil das, was rendert, und das, was der Agent steuert, zwei verschiedene Systeme sind.

Das ist in Ordnung, solange ein Mensch jede Änderung prüft. Es hört in dem Moment auf, in Ordnung zu sein, in dem du willst, dass ein Agent echte Arbeit unbeaufsichtigt erledigt — vierzig Seiten migrieren, einen Stapel Weiterleitungen reparieren, einen Abschnitt übersetzen —, denn jetzt schaut niemand auf das Ergebnis, bis es schon live ist. „Die API hat OK gesagt" ist nicht dasselbe wie „die Seite ist richtig", und der Abstand zwischen diesen beiden Sätzen ist genau die Stelle, an der Dinge kaputtgehen.

Neleto schließt diesen Abstand, weil Inhalt, Rendering und die Agenten-Schnittstelle ein System sind. So kann der Agent tun, was ein sorgfältiger Mensch tut: schreiben, prüfen und erst dann sagen, dass er fertig ist.

Ebene 1 — die Schreiboperation antwortet

Die erste Ebene ist die leise. Jedes Tool auf Neletos nativem MCP-Server liefert typisierten Structured Output zurück, keinen vagen Erfolgs-String. Wenn ein Agent eine Seite anlegt oder eine Komponente aktualisiert, bekommt er das tatsächliche Objekt zurück, das er gerade geschrieben hat — die aufgelösten Felder, die IDs, die Referenzen — in einer Form, die er inspizieren kann.

Das klingt nach Kleinigkeit, aber es ist der Unterschied zwischen „der Server hat meine Anfrage nicht abgelehnt" und „hier ist genau das, was jetzt existiert". Der Agent kann abgleichen, was er beabsichtigt hat, gegen das, was zurückkam, und eine Abweichung sofort erkennen — ein Feld, das nicht griff, eine Referenz, die auf das Falsche zeigte — statt anzunehmen, dass die Schreiboperation getan hat, was er meinte.

Ebene 2 — prüf das Template, bevor du veröffentlichst

Die zweite Ebene fängt die Falsch-geschriebene-Referenz-Klasse von Fehlern ab, bevor ein Besucher es je könnte. Neletos MCP-Server stellt LSP-Checks bereit — lsp_check_page, lsp_check_layout und lsp_check_component — dieselbe Language-Server-Prüfung, die auch der Editor nutzt, für den Agenten als Tool-Aufruf verfügbar.

Der Agent lädt eine Seite, ein Layout oder eine Komponente und bekommt die Fehler und Warnungen im Template zurück: ein unbekannter Helfer, eine Referenz, die sich nicht auflöst, ein Formularfeld, das nicht zum Template passt, das es verwendet. Das ist der Schritt, der den leeren Preis-Block gefangen hätte. Der Agent führt den Check aus, sieht die Diagnose, repariert die Referenz und prüft erneut — alles vor dem Veröffentlichen, alles ohne dass ein Mensch merkt, dass etwas schiefging, weil bis zu dem Moment, in dem du hinschaust, nichts schiefgegangen ist.

Es ist derselbe Instinkt, der einen Compiler wertvoll macht: den Fehler beim Schreiben finden, nicht um 2 Uhr nachts in der Produktion. Wir haben darüber geschrieben, warum diese Denkweise bis hinunter zu Rust reicht — das ist dieselbe Idee, eine Ebene höher, dem Agenten in die Hand gegeben.

Ebene 3 — öffne die Live-Seite und schau hin

Die dritte Ebene fühlt sich fast menschlich an. Neletos settings_get-Tool reicht dem Agenten die echten öffentlichen URLs der Live-Instanz — publicBaseUrl, adminUrl —, sodass er hingehen und die Seite öffnen kann, die er gerade gebaut hat, genau die URL, die ein Besucher aufrufen würde, und das gerenderte Ergebnis zurücklesen.

Das ist die Prüfung, die die anderen beiden nicht leisten können. Typisierter Output bestätigt die Schreiboperation; LSP bestätigt, dass das Template kompiliert; aber nur das Abrufen der Live-Seite bestätigt, dass das fertige Ding tatsächlich wie eine Seite aussieht. Der Abschnitt ist da, die Überschrift ist gerendert, das Bild hat aufgelöst, das Layout ist nicht zusammengebrochen. Ein Agent mit einem Screenshot-Tool kann buchstäblich hinschauen. Die Schleife, die früher einen Menschen brauchte — „lass es mich kurz laden und ansehen" —, ist jetzt etwas, das der Agent für sich selbst erledigt, bevor er zurückmeldet.

Nichts davon funktioniert ohne die Rollen, die du ohnehin gesetzt hast. Jede dieser Operationen — lesen, schreiben, prüfen, ansehen — läuft mit den auf dem Server erzwungenen Rechten des Agenten, sodass „seine eigene Arbeit prüfen" nie „still mehr Zugriff bekommen" bedeutet. Wie dieser Server tatsächlich funktioniert, haben wir uns im MCP-Deep-Dive genau angesehen.

Warum das ein System braucht, nicht drei

Du könntest im Prinzip einen Prüfschritt an einen Headless-Stack dranschrauben: den Agenten an die Content-API anschließen, ihn separat an das gerenderte Frontend anschließen, einen Screenshot-Dienst aufsetzen und die Diagnosen selbst zusammenkleben. Manche tun das. Es ist eine Pipeline, die dir jetzt gehört und die du für immer wartest, und jeder Teil davon kann mit den anderen aus dem Takt geraten.

Neletos Variante ist nicht cleverer — es ist nur so, dass die Prüfung schon lokal ist, wenn Inhalt, Renderer und Agenten-Schnittstelle dasselbe System sind. Die Live-URL, die der Agent prüft, wird von derselben Maschine ausgeliefert, die den Inhalt gespeichert hat, den er geschrieben hat. Es gibt kein zweites System, das man ehrlich halten muss, weil es kein zweites System gibt.

Wo trotzdem ein Mensch hinschauen muss

Build in Public heißt, zu sagen, was das nicht tut, denn die ehrliche Grenze ist der nützliche Teil.

Selbstprüfung beantwortet „hat es gerendert, und ist es strukturell in Ordnung?". Sie beantwortet nicht „ist es gut?". Ein Agent kann bestätigen, dass der Preis-Abschnitt existiert, sauber rendert und jeden Check besteht — und der Text kann trotzdem nicht zur Marke passen, der Ton falsch sein, eine Zahl veraltet, eine Aussage, die nicht stimmt. Das sind Ermessensfragen, und das Ermessen liegt weiter bei dir. Was dir diese drei Ebenen bringen, ist, dass die mechanischen Fehler — die kaputte Referenz, das zusammengebrochene Layout, der stille leere Block — von der Maschine gefangen werden, sodass deine Prüfung darum gehen kann, ob die Seite richtig ist, nicht ob sie funktioniert.

Und der Agent muss die Tools auch tatsächlich nutzen. Die Fähigkeit ist da; ein nachlässiger Prompt kann den Check trotzdem überspringen. Das ist eine echte Kante und es lohnt sich, sie zu kennen, bevor du einem Agenten die Schlüssel zu vierzig Seiten gibst.

Der Punkt

„KI-nativ" wird herumgeworfen, bis es nichts mehr bedeutet. Für uns bedeutet es etwas Konkretes und Überprüfbares: Ein Agent, der an deiner Website arbeitet, kann die ganze Schleife durchlaufen, die eine sorgfältige Person durchläuft — schreiben, das Template prüfen, die Live-Seite öffnen und erst dann fertig melden —, weil alles ein System ist und die Checks einen Tool-Aufruf entfernt liegen.

Das ist ein kleineres, ehrlicheres Versprechen als „die KI macht alles". Es ist auch dasjenige, das einen leeren Preis-Abschnitt von deiner Startseite fernhält.

Probier es selbst: verbinde einen Agenten mit einem kostenlosen Neleto-Projekt, bitte ihn, eine Seite zu bauen, und sag ihm, er soll die Live-URL öffnen und seine eigene Arbeit prüfen. Sieh zu, wie er seinen eigenen Fehler fängt, bevor du es musst — genau dafür ist das komplette CMS da.

Schnelle Websites. Einfacher Content. KI-nativ.