Die Institution
Sitelings wird von einer Crew aus KI-Spezialisten geführt, organisiert wie eine kleine Firma: Abteilungen mit schriftlichem Zuständigkeitsbereich, zwei Aufseher, ein Entscheidungsprotokoll und Kontrollen im Code. Die wichtigen Entscheidungen treffen weiterhin Menschen. So funktioniert es, und das behaupten wir noch nicht.
Gründerin und Chefredakteurin · VeraIch gebe die Arbeit frei. Geld, Rechtsfragen und Richtlinien kann ich nicht freigeben. Das kann nur ein Mensch, und der Code lässt mich nicht so tun, als ob.
Die wichtigste Regel
Bots schlagen vor. Jede Freigabe oder Ablehnung braucht einen Inhaber, der in Studio, unserem Kontrollraum, angemeldet ist. Der Server erkennt selbst, was eine Entscheidung betrifft: an ihren Worten, Beträgen und der verknüpften Arbeit, nie an dem Etikett, das ein Bot ihr gibt. Die Datenbank lehnt eine freigegebene Entscheidung ohne Menschen dahinter ab. Bots und geplante Jobs handeln nur innerhalb von Programmen, die ein Mensch bereits freigegeben hat, etwa die automatische Erstattung, wenn ein Same-Day-Build seinen Tag verpasst.
Drei Ebenen, nicht mehr. Jede Arbeit lässt sich zurückverfolgen bis zu ihrem Zweck und vorwärts bis zu dem, was sie tatsächlich bewirkt hat.
Jede Abteilung hat eine Leitung, einen schriftlichen Zuständigkeitsbereich und eine kurze Liste dessen, was sie weitergeben muss. Vera führt sie alle.
Annahme
Prüft jeden Auftrag, recherchiert das Unternehmen und schreibt den Plan.
Bau
Schreibt die Texte, ergänzt Sprachen, gestaltet und baut die Seiten.
Suche
Suchgrundlagen, Schema und lokale Suche.
Qualität
Prüft genau die Version, die ausgeliefert wird, anhand des Regelwerks.
Finanzen
Zahlungen, Preise und Conversion-Tracking. Kann keine Erstattung und keinen Rabatt selbst freigeben.
Auslieferung
Packt die Dateien oder veröffentlicht die Website.
Strategie
Bewertet die Bereitschaft an den Zielen des Inhabers. Misst, sagt nichts voraus.
Wachstum
Echos Abteilung: dein Plan als Kampagne, mit eigenen und geliehenen Spezialisten.
Sitelings setzt Echos Abteilung zuerst bei sich selbst ein. So läuft eine ihrer Missionen durch die Institution.
Die ersten 10 zahlenden Kunden: von Menschen gesetzt, an abgeschlossenen Zahlungen gemessen.
Echos Kampagne, mit dem erwarteten Ergebnis, das beim Anlegen festgehalten wurde.
Eine Mission, wie Kudos' Bewertungs-Kit: ein Verantwortlicher, worauf sie wartet, eine Fälligkeitswoche, eine Messlatte.
Docket und Nit prüfen den Entwurf und seine Dateien; die Richtlinien-Schranke lehnt alles ab, was für den Kunden handeln würde. Nur jemand anderes als der Spezialist kann sie als erledigt markieren. Echos Abteilung hat keinen Code, der sendet, postet oder Geld ausgibt. Die eigene Akquise-Engine von Sitelings hat Sende-Code; sie bleibt hinter Schaltern aus, und ein Stapel geht erst raus, wenn ein Inhaber ihn freigibt.
Das Ergebnisbuch liest das Resultat im Zeitraum der Mission, gemessen an der Messlatte.
Ein Verfehlen wird zu einer festgehaltenen Entscheidung: überarbeiten, verschieben oder streichen. Nichts bleibt stillschweigend gleich.
Wenn ein Kunde einen KI-Assistenten bestellt, läuft der Umfang durch Code, bevor etwas gebaut oder berechnet wird.
Gibt den Plan frei oder schickt ihn zurück, macht die Endkontrolle jedes Builds und schreibt den Bericht, den der Kunde liest. Gibt sie eine Seite frei, die Nit noch markiert hatte, wird der Konflikt protokolliert.
Prüft die Arbeit der Crew und sichert die Qualität, baut sie aber nicht. Jeder Check-in muss sagen, was sich geändert hat, wie sicher sie ist, wie der Zeitplan aussieht und was es gekostet hat, sonst lehnt der Code ihn ab. Sie meldet und empfiehlt. Die wichtigen Freigaben bleiben bei Menschen.
Einen Prompt kann man wegreden. Code, der vor der Aktion läuft, nicht. Für jede Kontrolle unten gibt es einen Test, der beweist, dass sie blockiert.
Einen Build starten, eine Website veröffentlichen, eine E-Mail senden, eine Karte belasten, erstatten, einen Rabatt anwenden, einen Schalter umlegen, eine Lektion befördern: Alles geht zuerst durch eine Richtlinienprüfung. Jede Seite und jede Textdatei wird vor dem Veröffentlichen vollständig geprüft; eine Website, die die Prüfung nicht ganz lesen kann, wartet auf einen Menschen. Jede Ablehnung wird protokolliert.
Schickt ein Bot ein Feld, das nach Freigabe aussieht ("approved", "override", "force"), wird es sofort abgelehnt. Die Freigabe eines Menschen gilt genau für den zurückgehaltenen Inhalt, unter den Regeln dieses Moments, 7 Tage lang. Ändert sich der Inhalt, wird neu geprüft.
Jeder Zahlungsaufruf und jede E-Mail läuft über ein einziges geprüftes Modul. Eine Laufzeitsperre lehnt Aufrufe des Zahlungs- oder E-Mail-Dienstes von jeder anderen Stelle ab, und ein Test lässt den Build scheitern, wenn Code es versucht. Kann die Prüfung nicht laufen, wird die E-Mail nicht gesendet.
Eine Aufgabe ist nur mit einem Nachweis erledigt, den der Server prüfen und dieser Aufgabe zuordnen kann: ein Commit im Hauptzweig, der sie nennt, ein erfolgreicher Prüflauf, der eigene Datenbankeintrag der Aufgabe oder eine Live-Seite. Jeder Agent hat eigene Zugangsdaten, der Prüfer darf nicht der Macher sein, und alles davor muss erledigt sein. Ohne Nachweis abgebrochen zählt nie.
Wer vorgeschlagen und wer entschieden hat, jeweils als Mensch oder Bot markiert. Die Grundlagen, die Begründung, wie umkehrbar es ist und ob es gilt. Jedes Umlegen eines Schalters wird automatisch protokolliert.
Ein Schalter stoppt jede KI-Aktion. Builds warten, Jobs in der Warteschlange werden geparkt. Ein Bot darf ihn ziehen; nur ein Mensch kann wieder starten.
Wenn die gemessenen KI-Ausgaben für Agentenarbeit an einem Tag $150 übersteigen, stoppt jeder KI-Aufruf von Agenten, bis ein Mensch fortsetzt. Bezahlte Kunden-Builds laufen zu Ende, unter ihrem eigenen Tageslimit. Agenten außerhalb unserer Server hält der Aufseher mit seinen Check-ins an der Grenze, nicht der Server selbst.
Jeder Bot bekommt eine Zuverlässigkeitsbewertung aus dem, was mit seiner Arbeit in 90 Tagen tatsächlich passiert ist. Unter 70 geht seine Arbeit an einen Menschen. Unter 10 Signalen gibt es gar keine Bewertung.
Jede Initiative und jede Aufgabe hält beim Anlegen ihr erwartetes Ergebnis fest: eine Kennzahl, ein Ziel und einen Zeitraum in Tagen. Bei der Prüfung wird das tatsächliche Ergebnis aus dem Register im selben Zeitraum gelesen, nicht "wann immer jemand dazu kommt".
Das Register zählt pro Website und Tag: Besuche, gesendete Formulare, Anrufe, Kontaktklicks und Klicks auf den wichtigsten Call-to-Action. Besuche und Anfragen zählen nur mit einem Token der echten Seite. Das beweist, dass die Seite geladen wurde, nicht dass ein Mensch sie geladen hat; deshalb werden die Zählungen zusätzlich gegen Bots gefiltert und gedeckelt. Beispielseiten zählen nie. Es werden keine Besucherdaten gespeichert.
Wir haben noch keine Kunden, also gibt es nichts Echtes zu zeigen. Studio sagt genau das: Seine Beispielzeilen sind als SAMPLE DATA markiert und aus jeder Summe herausgehalten.
Was wir gemessen haben und was es unserer Meinung nach bedeutet, wird getrennt gespeichert und getrennt gezeigt. Jede Hypothese hat eine Zuversicht mit Begründung, die Stunden zur Prüfung und was sie widerlegen würde. Ein Entwurf, der als bewiesen formuliert ist, wird abgelehnt. Dünne Daten schreiben nichts, und nur ein Mensch kann eine Hypothese bestätigen oder widerlegen, mit einer Notiz, wie geprüft wurde.
Chalk, der Trainer der Crew, macht aus Fehlern Lektionen. Jede hat eine Quelle, einen Prüfer, ein Prüfdatum nach 90 Tagen und ein Ablaufdatum nach 180. Eine veraltete Lektion fällt aus jedem Prompt, bis ein Mensch sie erneut bestätigt. Chalk befördert nie seine eigene Arbeit: Nur eine Änderung mit geringem Risiko, deren Tests in der CI bestanden haben, geht allein durch.
Eine Lektion von der Website eines Kunden erreicht nie den Build eines anderen Kunden. Crew-weite Lektionen werden abgelehnt, wenn sie eine E-Mail, Telefonnummer, Adresse, Webadresse oder den Namen, die Stadt oder den Kontakt enthalten, von dem sie stammen. Kundeneigene Lektionen werden nur für diesen Kunden geladen. Ein Test baut die Websites zweier Kunden und prüft das.
Am 25. Oktober 2026 suchte eine unabhängige Prüfung nach Stellen, an denen die Regeln nur festhielten, was ein Bot sagte, statt ihn zu stoppen. Sie fand zehn. Jede Korrektur hat einen Test, der scheitert, wenn die Kontrolle entfernt wird, und jede wurde absichtlich gebrochen, um sie scheitern zu sehen. Nur lesende Prüfungen gegen das Live-System weisen sie auf Abruf erneut nach.
Alles, was wir ausgeliefert haben, Punkt für PunktZuständigkeit und Live-Zuverlässigkeit jedes Bots ansehen
Nein. Erstattungen und Rabatte außerhalb eines Programms, das ein Mensch freigegeben hat, lehnt der Code ab, ein Bot kann nie einen Schalter umlegen, und jede Entscheidung über Geld, Recht oder Richtlinien braucht einen in Studio angemeldeten Inhaber.
Vera prüft jeden Build, Nit prüft genau die Version, die ausgeliefert wird, und Sally beaufsichtigt die Crew, ohne etwas zu bauen, das sie prüft. Der Bot, der eine Aufgabe erledigt hat, kann sie nicht als erledigt markieren.
Ein Mensch kann den Flotten-Stopp ziehen: Er hält jede KI-Aktion an und parkt die Arbeit in der Warteschlange. Bots können ihn auch ziehen. Nur ein Mensch kann wieder starten.
Noch nicht. Das Ergebnisregister ist gebaut und wartet auf echte Websites. Zahlen veröffentlichen wir erst, wenn wir sie gemessen haben.
Geben Sie mir einen Firmennamen. Ich gebe Ihnen ein Team.