Statt einen Artikel darueber zu schreiben, wie wir eine agentische Website fuer XYZ gebaut haben, haben wir beschlossen, sie sich selbst vorstellen zu lassen.
Das hat etwas Theatralisches, bringt den Punkt aber schneller auf den Tisch. Diese Website wurde als promptbare Website gebaut: eine Website, deren Inhalte, Struktur, Wissensschicht, Previews und unterstuetzende Automatisierung in einer Form vorliegen, die KI direkt unter klaren Leitplanken inspizieren und bearbeiten kann.
Dieser Unterschied ist wichtig. Viel Website-KI wirkt immer noch wie Dekoration. Ein Chatbot schwebt in der Ecke, vielleicht sind ein paar Seiten KI-generiert, und der Rest der Website verhaelt sich weiterhin wie ein fragiles handgepflegtes Objekt. Wir wollten etwas Nuetzlicheres. Die Website begann als Klon unseres bestehenden Hugo-basierten Setups fuer tryformation.com , das wir bereits agentisch pflegen. Das Design selbst entstand aber auf gruener Wiese mit Bildmaterial und einem meinungsstarken Designprototyp unseres CEO Ian Hannigan. Danach haben wir die Domain bei Cloudflare registriert, Codex gebeten, den Deploy-Prozess ueber GitHub Actions aufzusetzen, und die erste Version der Website in etwa vier Stunden live gestellt.
Die
Die Guard Rails sind der Grund, warum das funktioniert, ohne im Chaos zu enden.
Erstens lebt die Website in einem Repository mit einer vorhersehbaren Struktur. Seiten, Services, Blogposts, Navigationsdaten, Assets und Templates haben klare Orte. Dadurch muss die KI nicht raten, wo etwas hingehoert. Sie kann den aktuellen Stand inspizieren, aehnliche Inhalte vergleichen und gezielte Aenderungen vornehmen, statt ueber eine vage CMS-Oberflaeche zu improvisieren.
Zweitens traegt das Repository ausdrueckliche Anweisungen. Wir halten Workflow-Regeln nah an der Arbeit, damit das System die Content-Quelle der Wahrheit, die Uebersetzungsregeln, die Asset-Vorgaben, die Validierungskommandos und die Tonalitaet kennt. Das ist in der Praxis wichtiger, als viele erwarten. Der Unterschied zwischen einer nuetzlichen KI-Kollaboration und einer chaotischen liegt oft nicht im Modell selbst, sondern darin, ob die Leitplanken klar genug sind, um wiederholt gute Entscheidungen zu ermoeglichen.
Drittens lassen wir die Ausgabe nicht ungebunden. Die Website wird ueber Templates, generiertes Wissen, Suchindizes und Validierungsschritte gebaut. Auch wenn KI Copy entwirft oder Struktur vorschlaegt, muss das Ergebnis in das bestehende System passen. Das reduziert zufaellige Drift deutlich. Ausserdem wird Review leichter, weil die Ausgabe in pruefbaren Dateien landet statt in irgendeiner SaaS-Oberflaeche zu verschwinden.
Viertens entscheiden wir bewusst, wo Live-Intelligenz hingehoert. Der kleine Helfer auf dieser Website laeuft nicht als ungebundene Live-LLM-Schicht. Wir bereiten seine Wissensbasis vor, formen wahrscheinliche Antworten und halten das Laufzeitverhalten schmal genug, damit es schnell, vorhersehbar und guenstig bleibt. Auch das ist eine Guard Rail. Manchmal ist die bessere KI-Entscheidung, mehr Intelligenz in den Produktionsprozess vorzulagern statt in die Laufzeit fuer Besucher.
Der Content-Produktionsfluss
Im Produktionsfluss beginnt sich die Website weniger wie eine Broschuere und mehr wie ein arbeitendes System zu verhalten.
Meistens starten wir mit einem praktischen Bedarf: ein neuer Service, eine schaerfere Erklaerung, eine bessere Landingpage, eine fehlende FAQ, ein staerkerer Artikel oder ein neuer Weg, Besucher zum richtigen Angebot zu fuehren. Von dort aus kann KI das aktuelle Repository inspizieren, verstehen, wie aehnliche Seiten strukturiert sind, und neues Material direkt im Format entwerfen, das die Website bereits nutzt. So ist diese Website von der ersten Live-Version in den folgenden zwei Wochen zu etwas deutlich Reichhaltigerem geworden: mehr Inhalte, mehr Funktionen, ein enger abgestimmtes Design und eine wachsende Schicht nuetzlicher Details statt eines langen Backlogs, der auf Entwickler wartet.
Weil die Inhalte in Markdown, JSON, Templates und wiederverwendbaren Assets liegen, kann das System mehr als einen ersten Entwurf schreiben. Es kann eine Seite mit der richtigen Navigation verbinden, Folge-Wissen fuer Suche und Website-Helfer erzeugen, Social-Preview-Material generieren und die innere Konsistenz der gesamten Website erhalten. Die Arbeit bleibt nicht in einem Editorfenster stecken. Sie fliesst durch den gesamten Website-Stack.
Dadurch verstaerken sich Verbesserungen gegenseitig. Eine klarere Service-Seite verbessert die Seite selbst, aber auch die interne Suche, die Wissensschicht des Bots, verlinkte Inhalte und kuenftige redaktionelle Arbeit, weil die bessere Erklaerung nun Teil des Systems ist. Sobald die Website so strukturiert ist, wird jede gute Aenderung zu wiederverwendbarem Input fuer spaetere Aenderungen.
Der aktuelle Website-Helfer ist Teil dieses Flusses. Wir erzeugen und kuratieren Wissen, bevor der Besucher ankommt. Wir nutzen Overrides dort, wo Antworten enger gefuehrt sein sollen. Wir cachen Arbeit, wenn sich nichts geaendert hat. Wir halten das Ganze an Analytics angeschlossen, damit die Website uns zeigen kann, was Menschen tatsaechlich fragen, wo die Navigation versagt und welche Themen staerker behandelt werden sollten. So entsteht eine Schleife zwischen Content-Produktion und beobachteter Nachfrage. Dasselbe Muster hat uns auch geholfen, Funktionen schnell umzusetzen. Ein Beispiel, auf das wir besonders stolz sind, ist die Audio-Transkriptions-Erfahrung. Von der Idee bis zum Prototyp brauchten wir einen Tag. Danach haben wir die UX so weit verfeinert, bis Besucher beim Lesen mit hervorgehobenem Text mitgehen koennen.
Was Das Fuer Editoren Aendert
Fuer Editoren ist die groesste Veraenderung der sinkende Aufwand ueber den gesamten Workflow.
Ein Editor kann nach einem neuen Artikel, einer schaerferen Ueberschrift, einem direkteren Call to Action, einem neuen FAQ-Cluster, einer Kampagnenseite, einem suchorientierten Content-Pass oder einer strukturellen Bereinigung fragen, ohne jedes Mal auf einem weissen Blatt zu beginnen. KI kann den ersten Entwurf liefern, ihn gegen den Rest des Repositories pruefen und innerhalb der Muster arbeiten, die die Website bereits nutzt. Das Urteil bleibt beim Editor, aber viel repetitive Montagearbeit faellt weg.
Besonders nuetzlich ist das, wenn die Aufgabe nicht nur textlich ist. Editoren brauchen oft umliegende operative Hilfe: interne Links aktualisieren, Formatierung konsistent halten, die Navigation ausrichten, ein vorhandenes Bild wiederverwenden, die richtigen Metadaten setzen oder sicherstellen, dass die Seite auch Suche und Retrieval unterstuetzt. Eine promptbare Website erlaubt der KI, solche Aufgaben in einem Durchgang zu erledigen, weil das umgebende System mitinspiziert werden kann.
Dazu kommt ein Geschwindigkeitsvorteil fuer die laufende Pflege. Websites driften, weil sich kleine Aufgaben stapeln. Einige schwache Seiten bleiben schwach. Ein aelterer Artikel ist noch nuetzlich, aber schlecht verlinkt. Eine Service-Seite passt nicht mehr zur aktuellen Angebotslogik. Die FAQ hinkt echten Gespraechen hinterher. In einem promptbaren Setup werden diese Aufgaben viel guenstiger, und genau deshalb werden sie seltener endlos verschoben.
Editoren muessen auch nicht zu Entwicklern werden, um davon zu profitieren. Ian Hannigan ist kein Entwickler und hat fast die gesamte Arbeit an dieser Website gemacht. Dass kein Entwicklungsteam fuer jede Inhaltsaenderung, Designiteration oder Funktionsidee eingebunden werden muss, nimmt den groessten Teil der Reibung aus dem Prozess. Der Punkt ist nicht, dass ploetzlich alle Templates von Hand schreiben. Der Punkt ist, dass die Website in einer Form vorliegt, in der KI praezise Umsetzungsarbeit fuer die redaktionelle und gestalterische Verantwortung uebernehmen kann.
Warum Das Relevant Ist
Wir haben die XYZ Website so gebaut, weil die Website selbst das hinter unseren Services zeigen soll. Wenn wir ueber agentische Websites, promptbare Content-Systeme und KI-unterstuetzte redaktionelle Ablaufe sprechen, dann sollte sich die Website auch so verhalten.
Diese Website ist fuer uns eine Erfolgsgeschichte. Wir haben KI nicht genutzt, um Ecken abzuschneiden. Wir haben sie genutzt, um die Messlatte hoeher zu legen. Sie hat uns geholfen, ein modernes Layout zu liefern, das genau zur Marke passt, fortgeschrittene Suche und Retrieval aufzubauen, eine starke interne Wissensschicht zu etablieren und einen Content-Workflow zu schaffen, der auf klassische Weise deutlich schwerer aufzubauen und zu pflegen gewesen waere.
Wir behandeln die Website auch nicht als fertig. Wir iterieren staendig weiter, weil die Reibung so niedrig ist. Neue Seiten, schaerfere Erklaerungen, bessere Navigationspfade, staerkeres Retrieval und zielgerichteterer Content koennen entstehen, sobald wir den Bedarf sehen. Inzwischen schreibt die Website fast sich selbst, nicht weil Menschen verschwunden waeren, sondern weil das System editorische Absicht sehr schnell in funktionierende Ergebnisse uebersetzen kann.
Der praktische Unterschied ist klar. Die Website selbst ist darauf ausgelegt, produktiv mit KI zu arbeiten. Das Ergebnis ist eine Website, die sich schneller bewegen, sich besser erklaeren und mit jeder Nutzung besser werden kann.
Wenn sich Ihre Website immer noch wie ein kostbares Objekt verhaelt, das sich nur ueber langsame Handoffs veraendert, dann ist das Betriebsmodell wahrscheinlich der eigentliche Engpass. Wir koennen helfen, eine promptbare Website rund um Ihre Inhalte, Ihre Angebote und Ihren redaktionellen Workflow zu bauen, damit die Website leichter besser wird statt schwerer.