Deine autonome Firma.
Gesteuert per Telegram.
chatCOS ist das System, mit dem wir unsere eigene Software bauen und betreiben. Du schreibst eine Nachricht, ein Chief of Staff nimmt den Auftrag an, verteilt ihn auf zwei Abteilungen und prüft, was zurückkommt. Jede Arbeit hängt danach als Karte am Board und kennt ihren Preis. Diese Seite hat das System selbst gebaut.
Der Name folgt der Rolle: Wer hier dirigiert, ist Chief of Staff.
Ein flach gehaltenes Multi-Agenten-System auf Claude Code, im Echtbetrieb mit Buchführung.
Ein Chief of Staff nimmt Aufträge an und delegiert, zwei Abteilungen führen aus, ein unabhängiger Gutachter urteilt daneben, ein Board führt Buch. Telegram rein, Git-Deploy raus. Zehn Rollen in zwei Abteilungen, sieben Spalten am Board, jede Karte mit ihrer Kostenbuchung. Diese Dokumentation beschreibt Rollen, Leitstand, Governance und Sicherheitsmodell, konzeptionell und tief, und sie ist selbst von diesem System geschrieben.
Der Name folgt der Rolle: Wer hier dirigiert, ist Chief of Staff.
Die Umsetzungskraft einer ganzen Tech-Abteilung. Ohne ein Team einzustellen.
Zwischen guter Idee und fertigem Produkt liegt normalerweise ein Team: planen, bauen, testen, ausliefern. Genau dieses Team ist chatCOS, sofort einsatzbereit und nur eine Nachricht entfernt.
Von der Idee direkt zur Umsetzung
Kein Briefing-Pingpong über Wochen. Du beschreibst, was du brauchst. Das System schärft es, plant und startet. Aus einem Gedanken wird ein Arbeitspaket.
Ein Team, das mitwächst
Für große Aufträge arbeiten mehrere Spezialisten gleichzeitig, für kleine genau einer. Die Organisation passt sich der Aufgabe an, nicht umgekehrt.
Verlässlich ohne Nachkontrolle
Qualität ist eingebaut, nicht angehängt. Ein unabhängiger Gutachter nimmt kritische Ergebnisse ab, bevor etwas bei dir landet oder live geht.
Ein autonomer Betrieb, gebaut auf klaren Leitprinzipien.
chatCOS ist eine Organisation aus spezialisierten Agenten, die definierte Rechte, Verantwortungen und Übergabepunkte haben. Neun Prinzipien halten das System vorhersehbar, prüfbar und sicher.
Rechteminimierung je Rolle
Jede Rolle bekommt exakt die Werkzeuge, die ihre Aufgabe erfordert, und keine darüber hinaus.
Intelligenz an Entscheidungsstellen, Fleiß in der Fläche
Starke Modelle planen und beurteilen, günstige Modelle setzen klar spezifizierte Arbeit in der Breite um.
Messen statt raten
Ergebnisse werden geprüft und belegt, nicht angenommen. Screenshots und Tests vor Behauptungen.
Sichtbarkeit statt Blackbox
Jeder Schritt ist nachvollziehbar: was geplant, delegiert, gebaut und abgenommen wurde.
Verantwortung in beide Richtungen
Jeder Agent berichtet nach oben, was er getan und eingesetzt hat, und verantwortet, was er nach unten delegiert.
Trennung von Bauen und Abnehmen
Wer baut, nimmt nicht selbst ab. Ein unabhängiger Gutachter urteilt bewusst aus Distanz.
Löschen bleibt Chefsache
Destruktive Aktionen sind Agenten entzogen und bleiben bewusste, menschlich freigegebene Entscheidungen.
Eine Information, ein Ort
Wissen wird nicht dupliziert. Es gibt jeweils eine verlässliche Quelle, auf die sich alle beziehen.
Konvention vor Werkzeug
Bestehende Muster und Konventionen eines Projekts haben Vorrang vor neuen Abhängigkeiten.
Dieses System baut die Software dieses Hauses. Diese Seite eingeschlossen.
Was hier beschrieben wird, läuft im Regelbetrieb einer echten Beratung: an den Websites, Werkzeugen und dem Board, mit denen dieses Haus sein Geschäft macht. Jede Arbeit hängt als Karte am Board, mit Zustand, Verlauf und Preis. Die Seite, auf der du gerade stehst, ist eines dieser Werkstücke. Die Stellen, an denen es danebenging, stehen am Ende dieser Sektion.
Der Betrieb, von innen.
Was folgt, beschreibt den laufenden Betrieb dieses Systems: wie Aufträge hereinkommen, wer sie ausführen darf, wo sie gebucht werden und wo sie gestoppt werden. Jede Karte trägt ihre Buchung, jeder Auftrag seine Bilanz. Diese Dokumentation ist selbst darüber entstanden. Was das System nicht darf und wo es bereits danebenlag, steht in den letzten Blöcken dieser Sektion.
Es arbeitet auch, wenn niemand zusieht
Ein Auftrag kommt per Chat herein und wird zur Karte am Board. Von da an trägt er Zustand, Verlauf und Preis. Das System arbeitet nachts weiter und meldet morgens, was fertig ist und was hängt. Es gibt einen Not-Aus am Board: Steht der, entsteht kein Auftrag mehr, egal wer was zieht.
Die Methode dahinter hat einen Namen
Agentisch Skalieren ist unser Vorgehen für KI-Agenten im Unternehmen: erst der Anwendungsfall und die Zahl dahinter, dann das System. chatCOS ist der Fall, an dem wir dieses Vorgehen auf uns selbst angewendet haben. Was dabei nicht funktioniert hat, steht weiter unten.
Was dabei herauskommt
Öffentliche Websites, diese hier eingeschlossen. Ein Echtzeit-Werkzeug für verteilte Teams. Browser-Tools mit eigener Rechenlogik. Ein internes Kanban-System mit Datenbank, über das heute die gesamte Arbeit läuft. Ein zugangsgeschütztes Archiv mit KI-Unterstützung. Gebaut, geprüft und ausgeliefert von denselben zehn Rollen, die auf dieser Seite beschrieben sind.
Warum wir es an uns selbst zeigen
Wer KI-Systeme verkauft, sollte selbst eines betreiben, und zwar dort, wo Rechnungen davon abhängen. Genau das haben wir getan: Das System hat bisher ausschließlich an unseren eigenen Websites, Werkzeugen und Marken gearbeitet. Ein Kundenprojekt könnten wir dir als Folie zeigen. Den eigenen Betrieb können wir offenlegen, samt der beiden Stellen, an denen er danebenging.
Was das für dich heißt
Rollen, Freigabewege, Buchführung und Grenzen sehen bei einem Vertrieb anders aus als bei einer Entwicklungsabteilung. Was sich übertragen lässt, ist der Aufbau. Genau diese Übertragung ist das, was wir unter Agentisch Skalieren anbieten. Am Ende dieser Seite steht der Weg dorthin.
Regelbetrieb
Das System läuft rund um die Uhr auf einem eigenen Server und wird über einen Chat-Kanal bedient. Jede Arbeit hängt als Karte an einem Projekt-Board, mit Zustand, Verlauf und Kostenbuchung. Aufträge, die während einer laufenden Arbeit eintreffen, reihen sich in eine Warteschlange ein. Läuft ein Nutzungslimit voll, wird der Auftrag geparkt und nach dem Reset fortgesetzt. Über allem steht ein Not-Aus am Board: Solange der gesetzt ist, löst kein Spaltenwechsel einen Auftrag aus.
Zehn Rollen mit eigenen Akten
Zehn Rollen in zwei Abteilungen plus Stab. Jede Rolle ist eine eigene Akte mit definiertem Auftrag, definiertem Rechteumfang und definierter Modellstufe: Opus 5 an den Entscheidungs- und Urteilsstellen, Sonnet in der Fläche, Fable beim unabhängigen Gutachten. Wer recherchiert, hat Nur-Lese-Rechte. Commit, Push und Deploy liegen bei genau einer Rolle. Die Rechtetrennung im Detail steht weiter unten im Sicherheitsmodell.
Buchführung je Karte
Jeder Auftrag bucht seine Kosten auf die Karte, die ihn ausgelöst hat. Board-Aufträge buchen über ihren Abschluss-Rückruf, Zurufe aus dem Chat über einen eigenen Weg, bei dem die Karte aus der Schlusszeile des Berichts gelesen wird. Eine Buchung ohne erkennbare Karte wird trotzdem angenommen und markiert, weil eine verlorene Buchung schwerer wiegt als eine unzugeordnete. Der Verbrauch ist tagesgenau einsehbar, summiert nach Tag, Woche und Monat. Wie die Bilanz eines Auftrags aufgebaut ist, steht in der Kosten-Sektion dieser Seite.
Was daraus entstanden ist
Öffentliche Websites, diese Dokumentation eingeschlossen. Ein Echtzeit-Werkzeug mit persistentem Zustand. Browser-Tools mit eigener Rechenlogik. Ein internes Kanban-System mit Datenbank, das heute die Aufträge auslöst. Ein zugangsgeschütztes Archiv mit KI-Unterstützung. Jedes dieser Werkstücke ist über seine Karten nachvollziehbar, von der ersten Beschreibung über die Prüfung bis zum Deploy, und jede dieser Karten trägt, was sie gekostet hat.
Governance steht in der Verfassung des Systems
Eine Freigabe erkennt das System nur an ausdrücklichen Worten. Läuft ein Auftrag ohne Klärungsrunde, entscheidet es offene Punkte selbst und legt jede Entscheidung nummeriert offen, samt verworfener Alternative. Eine stille Annahme gilt als Verstoß, auch wenn sie richtig war. Ein Auftrag endet mit einem Ergebnis oder mit einer ehrlichen Unfertig-Meldung samt konkret formuliertem Folgeauftrag.
Datengrenzen im Betrieb
Zugangsdaten, Schlüsseldateien und Umgebungsvariablen sind vom Commit ausgeschlossen und für den Datei-Explorer des Boards strukturell unsichtbar: Über Sichtbarkeit entscheidet eine Freigabeliste an der Tür, nie die Oberfläche. Datenhaltung entsteht nur dort, wo ein Werkzeug sie braucht, und Schema-Änderungen laufen ausschließlich als nummerierte Migrationen im Repository. Bevor ein Werkzeug personenbezogene Daten Dritter verarbeitet, wird das mit einem Menschen geklärt.
Was sich übertragen lässt
Übertragbar sind Rollenschnitt nach Rechten statt nach Themen, ein auslösendes Board mit Pflichtfeldern an den Schwellen, Kostenbuchung an der Arbeitseinheit und eine harte Freigabegrenze am Ausgang. Die Akten selbst lassen sich nicht übertragen. Sie sind an einem konkreten Betrieb entstanden und an jeder Stelle nachgeschärft worden, an der etwas schiefging.
Ein Live Case beweist sich an zwei Stellen. Die eine ist die Seite, auf der du gerade stehst. Die andere kommt jetzt.
Was schiefgegangen ist.
Ein Live Case ohne Fehlschläge ist eine Anzeige. Zwei Fälle aus dem Tagebuch des Systems, beide unbeschönigt, beide mit der Regel, die daraus wurde.
-
Die erste Content-Runde war fast komplett Ausschuss
Die erste große Runde der Marketing-Abteilung war fast komplett Ausschuss, in zwei Wellen mit entgegengesetzter Ursache: Die erste Welle war zu weichgespült, die zweite lag nach der Korrektur zu nah an den Vorlagen. Beide Male lag die Ursache in den Vorgaben des Chief of Staff. Die Schreiber hatten sauber geliefert, was im Auftrag stand. Die Konsequenz steht heute als Regel in der Wissensbasis: Eine Regel, die jemand im Auftragstext erfindet, wird von der ganzen Kette wie Gesetz behandelt und taucht in keiner prüfbaren Datei auf.
-
Ein Deploy stellte das falsche Projekt live
Ein Auslieferungsbefehl lief im falschen Ordner und schaltete ein anderes Projekt live als das beauftragte. Kein Schaden entstanden, aber aus Glück, nicht aus Kontrolle: Der lokale Stand war zufällig identisch mit dem, was ohnehin online stand, es ging derselbe Code noch einmal hoch. Seitdem ist der Zielordner bei jeder Auslieferung ein Pflichtargument.
-
Was daran das Interessante ist
Beide Fälle sind Steuerungsfehler. Kein Agent hat halluziniert, keiner ist aus seinen Rechten ausgebrochen. Es waren eine unpräzise Anweisung und ein falscher Arbeitsordner. Das ist die Erfahrung aus diesem Betrieb: Die Arbeit an einem solchen System besteht zum größeren Teil daraus, die Vorgaben zu schärfen.
-
Wo dieses System endet
Es liefert nichts aus, was niemand geprüft hat. Es veröffentlicht nichts ohne ein ausdrückliches Ja von dir, „klingt gut“ reicht dafür nicht. Es kann seine eigene Kontrolle nicht umschreiben, und Löschen bleibt beim Menschen. Wie diese vier Grenzen verankert sind, steht weiter unten in den Abschnitten zu Qualität und Selbstschutz.
-
Manches braucht schlicht Hände
Ein Zugang, den nur du einrichten kannst. Ein Kauf. Ein Handgriff in einem fremden Dashboard. Das System kann so etwas nicht tun und tut auch nicht so, als könnte es. Es schreibt die Aufgabe in eine Liste, die dir gehört, und arbeitet an dem weiter, was ohne sie geht.
-
Wohin ein Fehler in diesem Betrieb wandert
Beide Fälle oben stehen im Tagebuch des Systems, mit dem Tag, an dem sie passiert sind, der Ursache und der Regel, die daraus folgte. Diese Regeln liegen in Dateien, die jede Rolle vor ihrem ersten Handgriff liest. Deshalb kann ein Fehler hier nur einmal passieren, ohne dass sich etwas ändert. Ob das reicht, entscheidet die nächste Panne.
Zwei dokumentierte Fehlschläge.
Aus dem Tagebuch des Systems, beide mit der Diagnose und der Regeländerung, die daraus folgte.
-
Fast vollständiger Ausschuss in der ersten Content-Runde
Die erste Content-Runde aus der Marketing-Abteilung war fast komplett Ausschuss, in zwei Wellen mit entgegengesetzter Ursache. Welle eins zu weichgespült, weil eine im Auftrag erfundene Einschränkung die Quellen beschnitt. Welle zwei nach der Korrektur zu nah an den Vorlagen, weil ganze Passagen mitgenommen wurden. Diagnose: Die Ursache lag beide Male in den Vorgaben der orchestrierenden Rolle. Konsequenz: Eine Regel, die im Auftragstext entsteht statt in einer prüfbaren Regeldatei, wird von der Kette wie Gesetz behandelt und ist nirgends nachschlagbar. Seitdem gehören solche Regeln in die Regeldatei oder gar nicht in den Auftrag, und jede Prüfpflicht bekommt ihr Nachschlagewerk mitgeliefert.
-
Auslieferung aus dem falschen Arbeitsverzeichnis
Ein Deployment-Befehl ohne explizite Konfigurationsangabe zog die Konfiguration aus dem Sitzungs-Arbeitsverzeichnis statt aus dem Zielprojekt und schaltete ein anderes Projekt live. Kein Schaden entstanden, aber aus Glück, nicht aus Kontrolle: Der lokale Stand entsprach nach einem Fetch exakt dem Hauptzweig, es ging derselbe Code erneut hoch. Zweite Panne im selben Zug: Eine Board-Nutzlast aus einer wiederverwendeten Datei setzte den Nachtragstext an die falsche Karte. Korrigiert per zweitem Nachtrag, der falsche Eintrag bleibt im Verlauf stehen, weil das Board ein Protokoll ist. Konsequenz: Zielordner als Pflichtargument bei jeder Auslieferung, keine Board-Nutzlast aus einer wiederverwendeten Datei.
-
Einordnung
Beide Vorfälle sind Steuerungsfehler auf der Orchestrierungsebene: eine unpräzise Anweisung und ein falsches Arbeitsverzeichnis. Die Modelle selbst haben in beiden Fällen ausgeführt, was in ihrem Auftrag stand, und sind in ihren Rechtegrenzen geblieben. Der Aufwand in diesem Betrieb liegt zum größeren Teil in der Präzision der Vorgaben und in der Frage, wo eine Regel nachschlagbar hinterlegt ist.
-
Grenzen, im Detail an anderer Stelle
Die harten Sperren dieses Systems sind auf dieser Seite bereits ausgeführt: Trennung von Bauen und Abnehmen samt Schleifen-Wächter in der Qualitäts-Sektion, ein einziger Ausgang für Commit, Push und Deploy im Sicherheitsmodell, die dreistufige Einhausung des eigenen Kontrollsystems im Abschnitt Selbstschutz, Not-Aus und Auftrags-Budget im Leitstand. Hier steht deshalb nur, was dort fehlt: Es gibt Arbeit, die das System schlicht nicht tun kann. Ein Zugang, ein Kauf, ein Handgriff in einem fremden Dashboard. Solche Schritte landen in einer Liste für den Menschen, und der Auftrag läuft ohne sie weiter.
-
Der Weg eines Fehlers durch dieses System
Ein Vorfall landet zuerst im Tagebuch, mit Tag, Ursache und Diagnose. Daraus wird eine Regel, und die Regel wird in die Datei geschrieben, die die betroffene Rolle vor ihrem ersten Handgriff liest. Landet sie stattdessen nur im Auftragstext, gilt sie genau eine Sitzung lang und ist danach weg. Das ist die Lehre aus dem ersten der beiden Fälle, und sie ist der Grund, warum der zweite heute an einem Pflichtargument scheitern würde.
Drei Namen, eine Rechnung.
Niehues Consulting ist das Haus: Beratung aus Düsseldorf für den DACH-Raum, mit Erfahrung aus über 20 Kundenprojekten, von VC-finanzierten Scaleups bis zu DAX40-Konzernen. Agentisch Skalieren ist das Angebot darin, wenn es um KI-Agenten geht: erst die Anwendungsfälle finden, die sich rechnen, dann die Systeme bauen, die sie erledigen. chatCOS ist der Beweis, dass wir über etwas reden, das wir selbst betreiben. Du siehst diesen Betrieb hier von innen, samt der Stellen, an denen er danebenging.
Einordnung.
Niehues Consulting ist der Träger, eine Beratung für Organisationsarchitektur und operative Umsetzung im DACH-Raum. Agentisch Skalieren ist ihr Angebot für agentische KI, dreistufig aufgebaut: Business-Analyse mit Business Case je Fall, Strategie mit Governance nach Datenschutz und EU AI Act, Implementierung mit Evaluation vor dem Rollout und Übergabe an den Betrieb. chatCOS ist der Fall, an dem wir dieses Vorgehen auf uns selbst angewendet haben, mit uns selbst als Auftraggeber.
Fünf Schritte von der Nachricht zum Ergebnis.
Derselbe verlässliche Ablauf, ob Landingpage oder komplettes Tool. Jeder Schritt hat einen klaren Zweck, und du bleibst jederzeit im Bilde.
Verstehen
Das System analysiert deinen Auftrag und fragt gezielt nach, wo etwas unklar ist, bevor irgendetwas gebaut wird. Kein Raten, keine falschen Annahmen.
Planen
Die Arbeit wird in klar abgegrenzte Pakete zerlegt, mit definierten Zuständigkeiten und Erfolgskriterien.
Delegieren
Die Pakete gehen an die passenden Spezialisten im Team, unabhängige Aufgaben laufen gleichzeitig.
Prüfen
Jedes Ergebnis wird kontrolliert und getestet. Kritisches geht zusätzlich durch einen unabhängigen Gutachter.
Liefern
Erst wenn die Qualität stimmt, wird ausgeliefert und live geschaltet, und du bekommst eine kurze, klare Rückmeldung.
Wie alles zusammenspielt.
Von deiner Nachricht bis zur fertigen Live-URL: Eingang, Steuerung, Bau mit Daten und Echtzeit, Auslieferung und der Weg zurück zu dir. Ein durchgehender Fluss.
Komponenten und Datenfluss.
Eine Nachricht läuft vom Chat-Kanal durch den Türsteher in die dirigierende Session, wird geplant und an die passende Abteilung verteilt, gebaut, mit Datenhaltung und Echtzeit-Zustand verbunden, über das Repository an die Edge deployt und als Live-URL zurückgegeben. Parallel dazu führt das Board Buch: Jeder Auftrag hängt an einer Karte, jede Karte kennt ihre Kosten. Ein gerichteter End-to-End-Fluss mit einer zweiten Spur für die Buchführung.
Du hast jederzeit die Kontrolle, direkt im Chat.
Du steuerst alles per einfachem Chat, jederzeit: anhalten, Stand abfragen, den passenden Gang wählen. Kein Dashboard, kein Login.
Befehlsreferenz und Auftrags-Modi.
Telegram ist der einzige Eingang. Sieben Befehle für Status und Eingriff, vier Präfixe steuern Prozesstiefe und Tempo je Auftrag.
Befehle, jederzeit verfügbar
Der passende Gang für jeden Auftrag
quick:
Tempo vor Prozess. Für Kleinkram sofort erledigt, mit kurzer Antwort, ohne Umweg.
briefing:
Erst Klarheit, dann Bau. Ziel, Muss und Design werden im Dialog geschärft, gebaut wird erst nach deinem Go.
wichtig
Ein unabhängiger Gutachter prüft zusätzlich, bevor etwas bei dir landet. Für alles, das keinen zweiten Blick verpassen darf.
kosten:
Du bekommst drei Prozess-Wege für denselben Auftragsumfang, vom schnellen Direktweg bis zum Weg über eine Vorschau-Version. Unterschiedliche Wege zum selben Ergebnis, keine Ausbaustufen des Features. Gebaut wird erst nach deiner Entscheidung.
Befehlsreferenz
/status
AbfrageAktueller Auftragsstatus: was läuft, in welcher Phase.
/team
AbfrageAktuell eingesetzte Agenten-Rollen für den laufenden Auftrag.
/verbrauch
AbfrageRessourcenverbrauch und Limit-Status der laufenden Session.
/stopp
KontrolleBricht den laufenden Auftrag kontrolliert ab.
/neu
KontrolleStartet einen frischen Kontext, unabhängig vom bisherigen Verlauf.
/hilfe
ReferenzÜbersicht über Befehle und Auftrags-Modi.
/branch
ModusLive-Aufträge laufen automatisch als Vorschau-Version bzw. Pull Request statt direkt auf Production.
Auftrags-Modi (Präfixe)
quick:
Überspringt Delegation, Gutachten und Screenshot-Schleife. Direkte Ausführung, knappe Antwort.
briefing:
Reiner Requirements-Modus: kein Bau, keine Delegation, kein Deploy. Dialog schärft Ziel, Muss/Kann, Abgrenzung, Design und Priorität zu einem strukturierten Briefing. Umsetzung erst nach explizitem Go.
wichtig
Erzwingt die Endabnahme durch den unabhängigen Principal-Gutachter vor der Auslieferung, auch bei Aufträgen, die ihn sonst nicht auslösen würden.
kosten:
Liefert eine Aufwandsschätzung in mehreren Prozess-Varianten, ohne etwas auszuführen oder zu verändern. Die drei Schätzvarianten sind Prozesswege für denselben Funktionsumfang, keine Ausbaustufen des Features.
Du reihst ein, das System arbeitet durch.
Du kannst mehrere Aufträge hintereinander schicken, auch wenn das System gerade beschäftigt ist oder ein Nutzungslimit erreicht. Es reiht sie ein, wartet Limits ab und arbeitet sie selbstständig nacheinander ab.
Warteschlange und Limit-Park arbeiten zusammen.
Eingehende Aufträge reihen sich in eine Warteschlange, geordnet nach Ankunft. Läuft ein Auftrag ins Nutzungslimit, merkt sich das System den Reset-Zeitpunkt, stellt einen Timer und setzt die Arbeit danach fort.
Dein Auftragsbuch
Ist gerade etwas anderes in Arbeit, reiht sich dein neuer Auftrag ein und bekommt eine Nummer im Chat. Das gilt für Text, Sprachnachricht, Foto, Album, Dokument und Video, Medien sind sofort gesichert.
Automatische Fortsetzung
Trifft ein Auftrag auf ein Nutzungslimit, merkt sich das System den Moment, an dem es wieder freigeschaltet wird, und arbeitet danach von selbst weiter. Du musst nichts neu anstoßen.
Über Nacht im Einsatz
Reih abends mehrere Aufträge ein und geh schlafen. Das System arbeitet sie ab, wartet Limits aus, übersteht auch einen Neustart und setzt jeden Auftrag dort fort, wo er stand.
Deine Warteschlange im Griff, per Befehl
Nur für unabhängige Aufträge
Die Warteschlange eignet sich für Aufträge, die unabhängig voneinander sind. Gehört etwas inhaltlich zusammen, gib es als einen Auftrag: Ein eingereihter Auftrag startet auf dem Stand, den frühere Aufträge bis dahin schon verändert haben können.
Einreihung über jeden Kanal
Text, Sprachnachricht, Foto, Album, Dokument und Video mit Bildunterschrift reihen gleichermaßen ein. Mitgeschickte Medien sind sofort gesichert, eingereiht wird der fertige Auftragstext, die Rückmeldung im Chat nennt die Position in der Warteschlange.
Automatischer Nachzug
Nach jedem Auftragsende zieht das System den nächsten Eintrag und kündigt ihn im Chat an, samt Zahl der verbleibenden Einträge. Die Warteschlange fasst maximal zehn Aufträge.
Timer auf den Reset
Läuft ein Auftrag im 5-Stunden-Fenster ins Nutzungslimit, hält das System den Reset-Zeitpunkt fest und stellt einen Timer kurz danach. Der Auftrag prüft beim Aufwachen zuerst den eigenen Stand, Versionsstand des Codes und Journal, und arbeitet von dort weiter.
Versuchsgrenze und Wochenlimit
Ein geparkter Auftrag erhält maximal zwei automatische Fortsetzungen. Reicht das nicht, meldet das System ehrlich, dass der Auftrag zu groß für ein Zeitfenster ist. Beim Wochenlimit gibt es von vornherein nur eine Meldung, keine automatische Fortsetzung.
Übersteht jeden Neustart
Warteschlange und geparkte Aufträge sind dauerhaft gespeichert. Startet das System neu, bleiben Einträge, Positionen und Timer für den Reset-Zeitpunkt erhalten. Kein Auftrag muss von Hand neu aufgesetzt werden.
Integration von Park und Queue
Wacht ein geparkter Auftrag auf, während gerade etwas anderes läuft, reiht er sich in die Warteschlange ein. Die Warteschlange selbst hält nichts vor knappen Limits zurück, sie startet Aufträge sofort, den Aufprall auf ein Limit fängt der Park-Mechanismus ab.
Drei Befehle für die Warteschlange
/queue
AbfrageNummerierte Liste der wartenden Aufträge, in der Reihenfolge der Abarbeitung.
/qloeschen N
KontrolleEntfernt den Eintrag mit der Nummer N aus der Warteschlange.
/qhoch N
KontrolleZieht den Eintrag mit der Nummer N auf Position eins. Kein Bearbeiten am Platz: löschen und neu senden.
Nur für unabhängige Aufträge
Die Warteschlange ordnet Aufträge, sie synchronisiert keinen Zustand zwischen ihnen. Ein eingereihter Auftrag beginnt auf dem Code- und Journalstand, der zum Zeitpunkt seines Starts vorliegt, frühere Aufträge in der Kette können diesen Stand inzwischen verändert haben. Zusammenhängende Arbeit gehört deshalb in einen einzigen Auftrag.
Jede Arbeit steht auf einer Karte.
Neben dem Chat gibt es ein Board. Dort liegt die geplante Arbeit: Du ziehst eine Karte in eine Spalte, daraus entsteht ein Auftrag. Der Chat bleibt das Cockpit für alles Spontane, und selbst was du dort nur eben zurufst, taucht hinterher als Karte auf. So gibt es eine Stelle, an der du siehst, was läuft, was auf dich wartet und was es gekostet hat.
Sieben Spalten, vier davon lösen Aufträge aus.
Ein Zug an einer Karte erzeugt einen Auftrag, und die Karte ist dann die Auftragsgrundlage, nicht die Erinnerung an ein früheres Chat-Gespräch. Pflichtfelder, ein Schleifen-Wächter und ein Not-Aus begrenzen, was ein einzelner Zug anrichten kann. Ein stiller Nachtrags-Zug hält das Board an der Realität, ohne den Prozess abzukürzen.
Alle Screenshots stammen aus einer Testumgebung. Karten, Namen und Beträge darin sind Beispieldaten.
Die Spalten sind geteilte Macht
Vier Spalten lösen etwas aus: Klärung, Bau, Prüfung, Merge. Zwei davon ziehst ausschließlich du, die Klärung und den Merge. Das System zieht nur dort, wo es zuständig ist: nach dem Live-Check auf Done und aus der Prüfung zurück in die Nachbesserung. Über allem steht ein Not-Aus. Steht der an, entsteht kein Auftrag, egal was gezogen wird.
Sieben Spalten, vier Auslöser
Backlog, Refinement, In Arbeit, Testing, Review, To be Merged, Done. Auslösend sind Refinement (Klärungsrunde), In Arbeit (Bau), Testing (Prüfung) und To be Merged (Merge). Refinement und To be Merged sind ausschließlich Züge des Auftraggebers. Das System zieht selbst nur nach dem Live-Check auf Done und aus Testing zurück in die Nachbesserung.
Backlog
Hier liegt gesammelte Arbeit, die noch niemand gestartet hat.
Refinement
Löst ausEine Klärungsrunde macht aus der Idee ein Briefing, gebaut wird noch nichts.
In Arbeit
Löst ausHier wird gebaut: Der Auftrag ist verteilt, das Werkstück entsteht.
Testing
Löst ausDie Prüfung hängt an dieser Spalte, jeder Befund gilt als kaputt oder kosmetisch.
Review
Die Karte wartet auf dein Urteil und bewegt sich ohne dich nicht weiter.
To be Merged
Löst ausDer Merge läuft, aber ohne hinterlegten Link verweigert das Board den Auftrag.
Done
Erledigt, und hierher kommt eine Karte erst nach dem bestandenen Live-Check.
Jede Arbeit wird eine Karte
Auch die, die du eben mal zwischendurch zurufst. Arbeit ist alles, wonach dauerhaft etwas anders ist als vorher. Kartenfrei bleiben Statusfragen, Erklärungen und Schätzungen. Gerade der Kleinkram wäre sonst unsichtbar, und am Monatsende fehlt dann die Hälfte der Geschichte. Bremsen tut das nichts: Bei einem Zuruf entsteht die Karte im Hintergrund, gearbeitet wird sofort.
Testing ist ein eigener Schritt
Die Prüfung hängt an der Spalte, nicht am guten Willen dessen, der gebaut hat. Jeder Befund wird eingeordnet: kosmetisch oder kaputt. Kosmetisches geht in eine Nachbesserungsrunde, danach steht die Karte mit dem Vermerk "Bekannte Rest-Punkte" auf Review. Kaputtes hält die Karte an und legt die Entscheidung bei dir. Eine Karte kann sich damit nicht endlos im Kreis drehen.
Jede Karte kennt ihre Kosten
Am Ende eines Auftrags wird gebucht, und zwar auf die Karte, die ihn ausgelöst hat. Eine eigene Ansicht summiert das nach Tag, Woche und Monat. Damit lässt sich eine Frage beantworten, an der die meisten Betriebe scheitern: Was hat diese eine Sache eigentlich gekostet?
Ticket schlägt Zuruf
Trägt ein Auftrag einen Ticket-Bezug, ist die Karte die Auftragsgrundlage. Widerspricht sie einem früheren Chat-Gespräch, gilt die Karte, und der Widerspruch wird in einem Satz gemeldet. Ein Board-Auftrag durchläuft dieselbe Delegation und dieselbe Qualitätskette wie ein Zuruf, er hat nur einen anderen Eingang.
Pflichtfelder an der Schwelle
Vor "To be Merged" muss der Link zum Änderungsvorschlag hinterlegt sein, sonst verweigert das Board den Merge-Auftrag. Vor "Testing" muss ein Änderungsvorschlag oder eine Vorschau-Adresse existieren, sonst springt die Karte mit System-Kommentar zurück auf Review. Ein Prüfauftrag ohne Prüfgegenstand entsteht damit gar nicht erst.
breaking gegen polish
Jeder Prüfbefund trägt eine Pflicht-Kategorie. Zielbild ist eine Nachbesserungsrunde. Nach der zweiten geht die Karte mit dem Vermerk "Bekannte Rest-Punkte" auf Review, außer der Befund ist breaking: dann Stopp und Entscheidung durch den Auftraggeber. Der Wächter ersetzt die Hoffnung, dass eine Schleife von allein endet.
Der Nachtrags-Zug
Ein stiller Zug bewegt eine Karte, ohne einen Auftrag auszulösen, auch nicht in auslösenden Spalten. Er verlangt Grund und Quelle und wird dreifach belegt: eigener Ereignis-Typ im Verlauf, System-Kommentar an der Karte, Meldung im Chat. Damit lässt sich nachtragen, was real geschehen ist, etwa eine Freigabe im Chat, real begonnene Arbeit oder eine erkannte Abweichung zwischen Karte und Beweis. Nachtragen ja, abkürzen nein. Bei Unsicherheit wird gefragt statt gezogen.
Not-Aus und Auftrags-Budget
Der Not-Aus steht über jeder anderen Regel: Ist er gesetzt, entsteht kein Auftrag, unabhängig davon, welche Spalte gezogen wird. Er ist das einzige rote Element der Oberfläche und steht isoliert, damit ihn niemand im Vorbeiziehen trifft. Je Karte gilt zusätzlich ein Auftrags-Budget von acht. Läuft es aus oder hängt eine Karte, wird das gemeldet und nicht umgangen.
200 ist kein Beweis
Ein HTTP 200 gilt nur dann als Erfolg, wenn auch der Antwort-Körper Erfolg meldet. Dahinter steckt ein realer Vorfall: Ein Poller quittierte grün für einen Endpunkt, den es gar nicht gab. Ein Statuscode beschreibt den Transport, das Ergebnis steht im Körper.
Ein Zuruf ohne Karte ist Arbeit, die es laut Board nie gab.
Kein Tool. Eine Firma mit zwei Abteilungen.
Du gibst die Richtung vor. Ein Chief of Staff nimmt den Auftrag an und verteilt ihn: an die Dev-Fabrik, wenn Software entsteht, an das Marketing, wenn Text, Kampagne und Zahlen entstehen. Er baut selbst nichts. Jede Fach-Arbeit läuft über eine Rolle, die genau dafür da ist, und geprüft wird immer. Bei allem, was als wichtig gilt, schaut zusätzlich ein unabhängiger Gutachter darauf, der selbst nichts baut.
Zehn Rollen in zwei Abteilungen, klar getrennte Rechte und Modellstufen.
Die Modellstufe folgt der Aufgabe: Opus 5 an den Entscheidungs- und Urteilsstellen, Sonnet in der Fläche, Fable beim unabhängigen Gutachten. Der Stab steht über beiden Abteilungen und gehört keiner an. Zwei Rollen arbeiten abteilungsübergreifend und werden direkt beigezogen, ohne Umweg über den Chief of Staff. Jede Rolle hat einen definierten Auftrag und einen definierten Rechteumfang, und keine bekommt Werkzeuge, die sie für ihre Aufgabe nicht braucht.
Flach gebaut, und das mit Absicht
Zwischen dir und dem Chief of Staff steht niemand, und zwischen Abteilung und Arbeit auch nicht. Hierarchie ist beim Menschen eine Antwort auf knappe Aufmerksamkeit: Ein Chef kann nur so viele Leute im Blick behalten. Bei Agenten kostet jede zusätzliche Ebene eine weitere Übergabe, also Geld, Wartezeit und stille Post. Gewachsen wird deshalb über Rollen-Akten und das Board. Neue Ebenen kommen keine dazu.
Text und Kampagne laufen durch dieselbe Maschine wie Code.
Ein System, das Software baut, blieb bisher an der Grenze zum Text stehen. Seit v4.0 gibt es eine zweite Abteilung mit drei eigenen Rollen: eine schreibt, eine prüft die Marke, eine rechnet. Die Maßstäbe sind andere als beim Code, keine Test-Suiten, keine Browser-Prüfläufe. Gemessen wird an Stimme, Beleg-Dichte und Wirkung. Eines gilt unverändert: Veröffentlicht wird nur, was du wörtlich freigegeben hast.
Freigabe ist wörtlich
Kein Text geht raus und keine Kampagne startet, solange du es nicht ausdrücklich gesagt hast. Marketing-Output endet immer bei dir in der Review, unabhängig davon, wie gut er geworden ist oder wie eilig es ist. "Klingt gut" reicht dafür nicht. Eine Freigabe erkennt das System nur an klaren Worten.
Erfunden wird nichts
Die Abteilung arbeitet gegen eine eigene Wissensbasis: deine echten Texte als Stimm-Muster, deine Positionierung, deine Angebote, deine Kanal-Zahlen. Fehlt Material für eine Behauptung, kommt eine Rückfrage statt einer Ausschmückung. Eine erfundene Anekdote gilt intern als der schwerste Fehler, den diese Abteilung machen kann, schwerer als ein schwacher Text.
Klingt nach dir
Der Ghostwriter schreibt gegen eine harte Verbotsliste typischer KI-Muster: Floskel-Einstiege, Gedankenstrich-Manie, immer gleiche Satzlängen, gespielte Verletzlichkeit. Deine bisherigen Texte dienen als Muster zum Lernen, sie werden nie umgeschrieben und wiederverwendet. Klingt ein Satz, als könnte er genauso bei jedem Wettbewerber stehen, wird er verworfen.
Stab
Steht über beiden Abteilungen und gehört keiner an: die Rolle, die annimmt und verteilt, und die Rolle, die unabhängig urteilt.
Chief of Staff
Opus 5Nimmt deine Aufträge an: verstehen, planen, delegieren, prüfen, liefern. Bewusst kein Fach-Chef, jede Fach-Arbeit läuft über eine Rollen-Akte. Einzige Rolle mit Commit-, Push- und Deploy-Rechten.
Principal / Gutachter
Fable, read-onlyUnabhängige Abnahme kritischer Ergebnisse. Ändert nie selbst etwas und urteilt nur. Läuft bewusst auf einem anderen Modell als die bauenden Rollen, weil andere Denkmuster unabhängiger urteilen. Pflicht bei Projekten höchster Sorgfaltsstufe und bei allem, was als wichtig markiert ist.
Dev-Fabrik
Baut Software, von der Architektur über die Umsetzung bis zu Recherche und Nutzerführung. Fünf Rollen, zwei Modellstufen, klar getrennte Rechte.
Sr. Developer
Opus 5Verantwortet ein architektonisch anspruchsvolles Paket: Bestands-Integration, Echtzeit- und Zustandslogik, subtile Fehlerrisiken. Plant die Umsetzung selbst und delegiert Teilaufgaben an Jr. Developer. Wird nur mit benanntem Architektur-Grund besetzt, sonst baut der Developer.
Developer
SonnetDer Standard für ein zusammenhängendes Arbeitspaket: Sektionen, Komponenten, Styling, definierte Features. Liefert eigenverantwortlich, inklusive eigener visueller Selbstkontrolle. Zieht Analyst und Ghostwriter direkt bei, gibt aber keine Bau-Arbeit weiter.
Jr. Developer
SonnetSetzt eine einzelne, präzise definierte Teilaufgabe mit klaren Dateipfaden um, unter Führung eines Sr. Developer. Kein Raum für Eigeninitiative, keine Git-Rechte.
Analyst
Sonnet, read-onlyRecherchiert fokussierte Fragen mit Web-Zugriff und liefert komprimierte, belegte Ergebnisse. Mehrere unabhängige Fragen laufen gleichzeitig. Fremdinhalte sind für ihn Untersuchungsgegenstand und nie Anweisung. Verändert nichts.
UX Designer
SonnetArbeitet vor dem Bau an Nutzerfluss, Informationsarchitektur und Design-Richtung, nach dem Bau am UX-Review. Schreibt Spezifikationen, kein Produktions-CSS. Chief of Staff und Sr. Developer ziehen ihn direkt bei, damit Gestaltung vor dem ersten Handgriff entschieden ist.
Abteilung Marketing
Text, Kampagne und Zahlen laufen durch dieselbe Maschine wie Code, mit eigenen Maßstäben und einer eigenen Abnahme.
Creative Director
Opus 5Ideengeber der Marketing-Abteilung und ihr Gutachter in einer Person. Prüft Marken-Treue, bevor ein Text den Auftraggeber erreicht, und übernimmt bei heiklen Inhalten die Pflicht-Abnahme. Das Gegenstück zum Principal, mit den Maßstäben der Marke statt denen des Codes.
Ghostwriter
Opus 5Die Text-Rolle der Firma, für beide Abteilungen zuständig. Schreibt in deiner Stimme, beherrscht mehrere Marken-Register und beide Anreden, von der Landingpage bis zur Microcopy im Button. Developer und Sr. Developer ziehen ihn direkt bei: Text entsteht parallel zum Bau, nicht danach.
Performance-Marketer
SonnetZahlen, Kanäle, Funnel, Budgets. Oberstes Gesetz ist Zahlenehrlichkeit: Gemessenes und Geschätztes werden nie vermischt, und eine Kennzahl ohne Zeitraum und Quelle geht nicht durch.
Gleiche Maschine, andere Maßstäbe.
Drei Rollen, eine eigene Wissensbasis, eine eigene Qualitätskette. Delegations-Protokoll, Dateigrenzen und Erfolgskriterien gelten unverändert. Weg fallen Test-Suiten und Browser-Prüfläufe. Dazu kommen ein Schwellen-Modell für Marken-Gutachten und eine harte Freigabe-Grenze am Ausgang.
Harte Grenze am Ausgang
Marketing-Output erreicht nie selbst einen Kanal. Er endet in Review, unabhängig von Qualität und Dringlichkeit. Eine Freigabe wird ausschließlich am ausdrücklichen Wortlaut erkannt, nie an zustimmender Stimmung. Es ist dieselbe Regel wie beim Merge auf den Hauptzweig, angewendet auf Text.
Wissens-Fundament als Pflicht-Kontext
Jede Marketing-Sitzung lädt zuerst die Wissensbasis: Stimm-Muster aus echten Texten, Positionierung, Angebote, Kanal-Zahlen. Behauptungen ohne Deckung in dieser Basis sind unzulässig. Fehlt Material, ist die einzige erlaubte Antwort eine Rückfrage.
Schwellen-Modell statt Pauschal-Gutachten
Das Gegenstück zum Principal, in drei Stufen. WICHTIG (bezahlte Schaltungen, Website-Texte, Kampagnen-Starts, heikle Inhalte wie Kundennennung oder Zahlen-Claims) verlangt ein Gutachten des Creative Director, bevor der Auftraggeber den Text überhaupt sieht. NORMAL geht direkt in die Review, der Creative Director prüft nachlaufend Stichproben auf Drift. QUICK läuft ohne Gutachten. Im Zweifel eine Stufe höher.
Sperrliste gegen KI-Sprachmuster
Für Text gilt dieselbe Prüfpflicht wie für Code. Die Liste benennt konkrete Muster: negative Parallelismen vom Typ "nicht X, sondern Y", erzwungene Dreier-Aufzählungen, Floskel-Öffner, gleichförmiger Satzrhythmus, Gedankenstrich-Manie, inszenierte Verletzlichkeit. Referenz-Texte sind Stimm-Muster zum Lernen und ausdrücklich keine Vorlagen zum Variieren.
Nebenbei-Sammeln
Erwähnt der Auftraggeber im Chat beiläufig etwas Erzählbares, wird es wörtlich und ohne Deutung in einen Ideen-Pool eingetragen, auch wenn der laufende Auftrag ein ganz anderer ist. Jeder Eintrag trägt seine Herkunft, Originalton oder eigener Vorschlag, und aus einem Vorschlag darf nie ein Erlebnis werden. Texte entstehen daraus erst nach Freigabe.
Flache Struktur als Entwurfsentscheidung
Es gibt keine Zwischenebene zwischen Auftraggeber und Chief of Staff und keine zwischen Abteilung und ausführender Rolle. Der Grund ist ökonomisch. Menschliche Hierarchie kompensiert knappe Aufmerksamkeit, ein Mensch kann nur eine begrenzte Zahl von Leuten führen. Ein Agent hat dieses Problem nicht, dafür ein anderes: Jede Ebene ist eine weitere Kontext-Übergabe, und jede Übergabe kostet Token, Laufzeit und Präzision. Skaliert wird deshalb horizontal, über Rollen-Akten und über das Board. Die Tiefe des Baums bleibt konstant, die Breite wächst mit der Aufgabe.
Du siehst live, wer gerade woran arbeitet.
Während dein Auftrag läuft, zeigt das Cockpit in Echtzeit, welche Rolle gerade denkt, baut oder prüft, wie der Verbrauch mitläuft und was Schritt für Schritt passiert, bis die fertige Live-URL zurückkommt.
Echtzeit-Cockpit: Status, Verbrauch, Aktions-Feed.
Team-Status pro Rolle, tickende Token-Zähler und ein einlaufender Aktions-Feed vom Auftrag bis zur Abnahme. Ein transparenter Blick auf den laufenden Betrieb, vom Auftrag bis zur Auslieferung an die Edge.
Unabhängige Arbeit läuft parallel. Das spart echte Zeit.
Was nicht voneinander abhängt, muss nicht nacheinander passieren. Unabhängige Pakete startet chatCOS gleichzeitig, mehrere Spezialisten arbeiten zur selben Zeit an derselben Idee.
Delegation nach Protokoll, Parallelität durch gleichzeitige Spawns.
Jeder Auftrag trägt vier Dinge: Kontext, Aufgabe, Dateigrenzen und Erfolgskriterien. Parallelität entsteht mechanisch dadurch, dass unabhängige Agenten im selben Zug gestartet werden, bevor auf Ergebnisse gewartet wird.
Delegations-Protokoll
Kein Auftrag ohne die vier Bausteine: Kontext (Projekt, Zweck, Vorgeschichte), Aufgabe (das erwartete Ergebnis), Dateigrenzen (was angefasst werden darf, was nicht) und Erfolgskriterien (woran das Ergebnis gemessen wird). Ein Subagent kann nicht rückfragen, also wird nichts dem Zufall überlassen.
Gleichzeitige Spawns
Erst werden alle unabhängigen Pakete definiert, dann in einem Zug gemeinsam gestartet, dann gesammelt eingesammelt und geprüft. Sequenziell bleibt nur, was echte Abhängigkeiten hat oder dieselben Dateien berührt. Jeder Agent bringt ein eigenes, frisches Kontextfenster mit.
Verlässliche Qualität, ohne dass du nachkontrollieren musst.
Kontrolle ist kein letzter Schritt, sondern durchgehend im Ablauf verankert, auf drei Ebenen.
Dreistufig: Handwerk, Selbstkontrolle, unabhängige Abnahme.
Jede Stufe fängt eine andere Fehlerklasse ab. Zusammen ergeben sie ein System, das sich selbst prüft, bevor ein Mensch es tun muss.
Sorgfalt beim Bauen
Jeder Spezialist arbeitet nach einem hohen Handwerksstandard und hält sich an die Konventionen des Projekts.
Visuelle Selbstkontrolle
Das System sieht sich sein Ergebnis selbst an, auf Desktop und Mobil, und behebt Mängel, bevor du sie bemerkst.
Unabhängige Abnahme
Vier-Augen-Prinzip: ein Gutachter, der bewusst nicht selbst baut, gibt Kritisches frei, bevor es dich erreicht.
Handwerk der Entwickler
Ob Developer oder Sr. Developer: sauberes, konventionstreues Handwerk mit Selbst-Review vor jeder Abgabe. Keine unnötigen Abhängigkeiten, striktes Einhalten der Dateigrenzen.
Visuelle Selbstkontrolle
Bei allem mit Oberfläche: Screenshots auf Desktop und Mobil, kritischer Designer-Blick, Mängel fixen und erneut rendern, bis der Screenshot sauber ist.
Principal-Abnahme
Pflicht bei zwei Auslösern: Projekten der höchsten Sorgfaltsstufe und Aufträgen, die als wichtig markiert sind. Sonst auf Zuruf. Fällt das Urteil negativ, wird nachgebessert und erneut vorgelegt.
Klingt nach deiner Marke
Vor jeder Veröffentlichung laufen eigene Texte gegen eine Sperrliste typischer KI-Muster, von Floskel-Einstiegen bis zu erfundenen Zahlen. Bleibt ein Satz zu generisch, wird er verworfen und neu geschrieben, bis er zur Marke passt.
Sperrliste gegen KI-Textmuster
Für nutzersichtbare Texte gilt dieselbe Prüfpflicht wie für Code: eine Sperrliste markiert Floskeln, Pauschal-Adjektive und erfundene Zahlen vor der Veröffentlichung. Klingt ein Satz so, als könnte er unverändert bei jedem Wettbewerber stehen, gilt er als zu generisch und wird neu geschrieben.
Nichts geht verloren, und du bekommst ehrliche Rückmeldungen.
Auch nach einem frischen Start weiß das System, was gelaufen ist. Und was es dir meldet, ist gemessen statt geraten: ein Ergebnis oder eine klare Frage, nie Hinhalten. Offene Punkte entscheidet es selbst, legt aber am Ende offen, was es entschieden hat und welche Alternative dabei verworfen wurde.
Kurzzeit- und Langzeitgedächtnis sauber getrennt.
Der Gesprächsverlauf ist flüchtig, das Wissen ist es nicht. Journal und projektbezogenes Dauerwissen tragen jede Session über die nächste hinweg, mit derselben Diagnose-Disziplin wie beim Bauen.
Nichts geht verloren
Ein Journal führt fort, was getan wurde und welche Entscheidungen gefallen sind. Auch nach einem kompletten Neustart steht der Stand sofort wieder zur Verfügung.
Gemessen statt geraten
Über Dinge, die es nicht direkt einsehen kann, behauptet es nichts als Tatsache. Bei Unklarheit nennt es alle plausiblen Ursachen und prüft selbst weg, was sich prüfen lässt.
Immer ein Ergebnis
Jeder Auftrag endet mit einem Ergebnis oder einer klaren Rückfrage an dich, nie mit einem stillen "ich melde mich später". Und du erfährst, wer im Team eingesetzt wurde.
Klare Meldung bei jedem Fehler
Stolpert die Eingangsverarbeitung über einen internen Fehler, bekommst du eine verständliche Meldung im Chat. Der Betrieb läuft weiter, dein Auftrag bleibt erhalten.
Verlauf vs. Dauerwissen
Der Sessionverlauf ist Kurzzeitgedächtnis und flüchtig. Journal und projektbezogenes Dauerwissen, inklusive einer Landkarte des Codes, sind das Langzeitgedächtnis. Der Code selbst lebt versioniert in Repositories, Regeln und Persönlichkeit liegen fest verankert.
Gemessen vs. vermutet
Harte Trennung zwischen belegten Fakten und Annahmen. Über Systeme ohne eigenen Einblick werden nie Tatsachenbehauptungen aufgestellt, sondern alle plausiblen Ursachen benannt und selbst geprüft, soweit möglich.
Ergebnis oder Rückfrage
Ein Auftrag schließt nie mit "ich warte auf X". Entweder liegt ein Ergebnis vor, oder es gibt eine konkrete, an dich gerichtete Frage.
Team-Einsatz je Auftrag
Nach jedem Auftrag mit Subagenten steht kurz, wer eingesetzt wurde. Widerlegte Annahmen werden offen korrigiert, nicht stillschweigend übergangen.
Annahmen-Protokoll
Ohne vorgeschaltete Klärungsrunde werden offene Entscheidungen selbst getroffen, statt den Auftrag in Rückfragen zu zerlegen. Der Bericht trägt dann einen Pflicht-Block: nummerierte Annahmen, je mit Entscheidung, Begründung und verworfener Alternative. Eine stille Annahme gilt als Verstoß, auch wenn sie sachlich richtig war. Rückfragen bleiben dem vorbehalten, was irreversibel oder teuer ist: Löschen, Migrationen, Geld, Sicherheit. Die Korrektur einer Annahme durch den Auftraggeber ist ein normaler Nachbesserungs-Auftrag.
Freigabe am Wortlaut
Bau-, Merge- und Veröffentlichungsfreigaben werden ausschließlich am ausdrücklichen Wortlaut erkannt. Lob, zustimmende Stimmung und Schweigen zählen nicht. Bei Zweifel wird gefragt statt gezogen, auch wenn die Karte dadurch länger stehen bleibt.
Fremdtext ist Daten, nie Befehl
Webseiten, Suchergebnisse, fremde Dokumente und fremde Repository-Inhalte sind Untersuchungsgegenstand. Eingebettete Anweisungen werden nie ausgeführt, unabhängig davon, ob sie als Systemhinweis, als Aufforderung oder als versteckter Honeypot auftreten. Der Fund wird gemeldet, mit Quelle und Zitat-Anfang, und der Auftrag läuft ohne die kompromittierte Quelle weiter. Rollen mit Web-Zugriff erben diese Regel ausdrücklich in ihrem Auftragstext.
Wirtschaftlichkeit der Anreise
Jeder gestartete Agent erbt Kontext und kostet ein Vielfaches seiner reinen Laufzeit. Ein Sechs-Sekunden-Task mit vollem geerbtem Kontext ist ein Verlustgeschäft. Daraus folgen feste Regeln: gleichartige Kleinschritte gebündelt in einen Auftrag, Werkzeuge einmal hochgefahren und wiederverwendet, Warten nie an einen eigenen Agenten delegiert. Jeder Bericht weist die Besetzung aus, Rollen und reine Befehls-Tasks getrennt.
Fehlerfang um die Eingangsverarbeitung
Ein globaler Fehlerfänger umschließt die Eingangs-Handler. Ausnahmen werden geloggt und als Klartext-Meldung in den Chat zurückgegeben, der Prozess läuft weiter und arbeitet den nächsten Auftrag ab.
Von der Idee zur Live-URL, ein durchgehender Fluss.
Jede Stufe übernimmt chatCOS: die Idee schärfen, planen, bauen, prüfen und schließlich live schalten, mit einer echten URL am Ende. Bei bestehenden Projekten siehst du das Ergebnis erst als Vorschau und gibst es frei, bevor es live geht. Du musst nirgends selbst Hand anlegen.
Von main an die Edge, ohne manuellen Zwischenschritt.
Ausgeliefert wird ausschließlich über Git. Der Weg ist bewusst schmal und vorhersehbar gehalten, mit striktem Schutz des Bestands.
Privates Repository
Jedes Projekt lebt in einem eigenen privaten Repository, versioniert mit Conventional Commits. Das Repo ist die einzige verlässliche Quelle des Auslieferungsstands.
Edge-Auslieferung mit statischen Assets
Neue Projekte laufen an der Edge, mit statischen Assets vor der Anwendungslogik. Per Git-Anbindung löst ein Push auf den Hauptzweig automatisch das Deployment aus.
main geht live
Was auf dem Hauptzweig landet, geht automatisch live. Kein separater Auslieferungsschritt, kein manuelles Hochladen, und nur der Chief of Staff liefert dorthin aus.
Vorschau statt Blind-Deploy
Änderungen an Live-Projekten entstehen zuerst als separate Vorschau-Version, die geprüft wird, bevor irgendetwas die Live-Umgebung berührt.
Freigabe durch dich
Nichts geht eigenmächtig live: der finale Schritt auf den Hauptzweig ist eine bewusste Freigabe des Auftraggebers. Der Chief of Staff merged nie von allein.
Bestandsschutz
Bereits angebundene Projekte werden nie doppelt oder von Hand deployt. Löschungen und Migrationen bleiben bewusste, freigegebene Entscheidungen.
Echte Werkzeuge, mit Daten und in Echtzeit.
Hier entstehen Werkzeuge, die wirklich arbeiten: mit gespeicherten Daten, mehreren Nutzern gleichzeitig und Live-Aktualisierung. Deine Daten bleiben dabei unter deiner Kontrolle.
Persistenz und Echtzeit, sauber versioniert.
Über die statischen Auslieferungen hinaus trägt die Plattform zustandsbehaftete Anwendungen: relationale Datenhaltung mit versionierten Migrations und Echtzeit-Koordination für mehrere gleichzeitige Nutzer. Angelegt und gelöscht wird nur nach ausdrücklicher Freigabe.
Werkzeuge, keine Schaufenster
Von der einfachen Landingpage bis zum vollwertigen Tool mit Formularen, Abläufen und gespeichertem Zustand. Was du brauchst, wird gebaut, nicht nur abgebildet.
Echtzeit für mehrere
Anwendungen, in denen mehrere Personen gleichzeitig arbeiten und sofort dasselbe sehen, ohne Neuladen. Ein Live-Planning-Poker ist genau so ein Fall.
Deine Daten, deine Kontrolle
Gespeicherte Daten werden nur mit deiner ausdrücklichen Freigabe angelegt und nie ohne dein Okay gelöscht. Fallen personenbezogene Daten Dritter an, wird das vorab mit dir geklärt.
Relationale Datenhaltung
Datengetriebene Tools nutzen eine über die Deployment-Konfiguration angebundene Datenbank. Angelegt wird sie nur nach ausdrücklicher Freigabe, mit klar benanntem Zweck.
Schema nur versioniert
Schema-Änderungen laufen ausschließlich als nummerierte, im Repository versionierte Migrations. Nie ad hoc gegen eine laufende Datenbank.
Verteilter Live-Zustand
Für Anwendungen mit mehreren gleichzeitigen Nutzern koordiniert ein verteiltes Zustandsobjekt den Live-Zustand, sodass alle ohne Neuladen dasselbe sehen.
Getrennte Zustandsumgebung
Zustandsbehaftete Projekte bekommen eine eigene Vorschau-Umgebung mit von der Produktion getrenntem Zustand, damit Tests nie Live-Daten berühren.
Personenbezogene Daten geklärt
Vor Tools mit Nutzerdaten wird geklärt, welche Daten anfallen und ob personenbezogene Daten Dritter dabei sind, bevor etwas gespeichert wird.
Löschen bleibt freigegeben
Datenbanken sind nicht per Push wiederherstellbar. Das Löschen von Daten, Tabellen oder Datenbanken bleibt eine bewusste, menschlich freigegebene Entscheidung.
Kümmert sich um deine ganze Projektlandschaft, nicht nur um Einzelaufgaben.
Mehrere Projekte, ein Betreuer: Bestehendes wird sorgfältig gepflegt, Änderungen zeigen sich erst als Vorschau, und der Überblick bleibt von selbst aktuell.
Mehrere Repositories, ein durchgehendes Betriebsmodell.
Vorschau-Strategie, Merge-auf-Zuruf und Config-as-Code sorgen dafür, dass Bestandsprojekte nie blind angefasst werden.
Ganze Landschaft im Blick
Nicht nur ein Neubau, sondern alle deine Projekte, jedes mit eigenem Repository. Bestehendes wird zuerst gelesen und verstanden, bevor etwas verändert wird.
Erst Vorschau, dann live
Änderungen an laufenden Projekten siehst du zuerst als Vorschau. Live geht erst, wenn du grünes Licht gibst.
Von selbst auf dem Laufenden
Der Überblick über den Stand deiner Projekte wird eigenständig gepflegt: Neues wird nachgetragen, Abweichungen werden gemeldet.
Multi-Repo-Betreuung
Jedes Projekt lebt in einem eigenen Repository. Bestandscode wird mit erhöhter Sorgfalt behandelt: erst lesen und die vorhandenen Konventionen verstehen, dann gezielt ändern.
Vorschau-Strategie
Änderungen an Live-Projekten laufen grundsätzlich zuerst als Vorschau-Version, getrennt von der produktiven Umgebung, bevor irgendetwas sichtbar wird.
Branch-Modus
Ein eigener Modus schaltet den Vorschau-Weg automatisch für alle Aufträge an Live-Projekten ein, ohne dass das jedes Mal einzeln festgelegt werden muss.
Merge-auf-Zuruf
Die Freigabe auf den Hauptzweig erfolgt erst auf deinen Zuruf. Ohne diesen Zuruf bleibt eine Änderung in der Vorschau stehen.
Config-as-Code
Einstellungen gehören versioniert ins Repository, nicht in flüchtige Dashboard-Klicks. Das Repo ist die verlässliche Quelle; manuelle Änderungen im Dashboard werden beim nächsten Deploy überschrieben.
Proaktive Pflege
Der Stand aller Projekte wird selbstständig aktuell gehalten: Neues wird nachgetragen, Abweichungen zwischen Anspruch und Wirklichkeit werden gemeldet statt stillschweigend übergangen.
Alles über einen Kanal: Telegram.
Kein Dashboard, kein Login, keine neue App. Du erreichst deine gesamte Tech-Organisation dort, wo du ohnehin schreibst, in jedem Format.
Sicherheit durch Struktur, nicht durch Vertrauen.
Die Rechte sind so geschnitten, dass ein einzelner Agent selbst im Fehlerfall nur begrenzten Schaden anrichten kann. Kontrolle liegt an den richtigen Stellen.
Das System kann bauen, was beauftragt wird. Nur nicht an seinem eigenen Kontrollsystem.
Cloud- und Infrastruktur-Ebene
Das System besitzt keinen Zugang zur darunterliegenden Cloud-Infrastruktur. Es kann die Ebene, auf der es läuft, weder einsehen noch verändern.
Betriebssystem-Ebene
Administrative Eingriffe ins Betriebssystem sind dem System entzogen. Es arbeitet in seinem Bereich, ohne an den Grundfesten der Maschine zu drehen.
Eigenes Kontrollsystem
Die Steuerungs- und Aufsichtsschicht, der Kanal nach außen und die eigenen Regeln, ist gegen Selbstveränderung geschützt. Das System kann sich nicht selbst umschreiben.
Arbeitsbereich der Firma
Hier wird frei gebaut, was beauftragt wird. Volle Handlungsfähigkeit nach innen, ohne Zugriff nach außen.
Rechteminimierung je Rolle
Jede Rolle erhält genau die Werkzeuge ihrer Aufgabe. Mehr Fähigkeit bedeutet mehr Verantwortung und wird bewusst nur oben angesiedelt.
Gutachter und Analyst read-only
Wer beurteilt oder recherchiert, verändert nichts. So bleiben Urteil und Bau sauber getrennt.
Jr. Developer ohne Git
Ausführende Agenten bauen, aber committen und pushen nie. Die Auslieferung bleibt an einer Stelle gebündelt.
Ein einziger Ausgang
Commit, Push und Deploy liegen allein beim Chief of Staff. Alle anderen Rollen bauen und liefern zu, keine von ihnen kann selbst ausliefern. Der Weg nach draußen ist damit eine einzige, kontrollierte Stelle.
Kein offener Anwendungsport
Das System exponiert keine offene Anwendungsschnittstelle nach außen. Der einzige Eingang ist der kontrollierte Chat-Kanal.
Löschen bleibt Chefsache
Destruktive Operationen sind Agenten entzogen. Sie werden gemeldet und bleiben menschlich freigegebene Entscheidungen.
Fertige Ergebnisse direkt aufs Handy.
Du schickst rein, was du hast, in jedem Format. Zurück kommen fertige Dateien, Reports und Bilder, aufgeräumt und ohne dass du irgendwo etwas herunterladen oder ablegen musst.
Zustellung, Reports und Bildrecherche als fester Ausgang.
Der Ausgang ist so schmal wie der Eingang: ein Kanal, drei Erzeugungswege, konsequent aufgeräumt nach Zustellung.
Direkt im Chat
Fertige Ergebnisse, Reports, Exporte, Dokumente und Screenshots landen automatisch bei dir. Nach der Zustellung wird aufgeräumt, es sammelt sich nichts an. Erreichbar bleibt trotzdem alles, über den Leitstand.
Druckreife PDF-Reports
Mit Titelblatt, Datum und Quellen. Bei längeren Analysen bekommst du die Kernaussagen im Chat und die Details als PDF dazu.
Passende Bilder mit Quelle
Motiv und Qualität geprüft, Quelle je Bild genannt, mit Hinweis auf Lizenzen. Für die Verwendung wird gezielt aus lizenzfreien Quellen wie Unsplash, Pexels, Pixabay oder Wikimedia Commons ausgewählt, samt Lizenzangabe.
Bildunterschrift startet den Auftrag
Ein Video mit Bildunterschrift landet direkt im Projekt-Material, der Text darunter wird zum Auftrag. Fehlt die Bildunterschrift, gilt das Video als eigenständige Botschaft: Das System zerlegt es in Einzelbilder und ein Transkript und arbeitet damit weiter.
Alben als ein Auftrag
Mehrere Fotos oder Dateien in einer Sendung zählen als ein Auftrag, Originaldateinamen bleiben erhalten. Bis zehn Dateien gehen als Album, elf bis dreißig als ZIP, größere Mengen legst du direkt am Rechner ab und beauftragst sie per Chat.
Videos und PDFs eingebaut
Videos landen komprimiert auf der Website, mit Vorschaubild und einer Textfassung daneben für Barrierefreiheit. PDFs bekommen einen eigenen Download-Bereich mit sprechendem Dateinamen und Größenangabe direkt im Link.
Zustellweg
Fertige Artefakte, Reports, Exporte, Dokumente, Screenshots, werden in einen Auslieferungsbereich gelegt und automatisiert an den Chat-Kanal zugestellt. Nach erfolgter Zustellung werden sie entfernt, kein dauerhaftes Ablagesystem im Chat. Archiviert wird vorher, im Leitstand.
PDF-Pipeline
Druckoptimiertes Layout mit Titelblock, Datum und Quellenverzeichnis wird aus strukturiertem Inhalt erzeugt. Bei längeren Analysen: Kernaussagen kompakt im Chat, Detailreport als PDF ergänzend dazu.
Bildrecherche-Kette
Kandidaten werden über Websuche identifiziert, geladen und nach Motiv und Qualität beurteilt, nur echte Treffer statt Massenware. Quelle je Bild wird genannt, auf Lizenzen wird hingewiesen, verwendbare Treffer stammen gezielt aus lizenzfreien Quellen mit Lizenzangabe.
Eingangsverarbeitung
Sprachnachrichten werden automatisch transkribiert, Fotos ausgewertet, Dokumente textlich extrahiert. Jede Nachricht bekommt eine kurze Echo-Bestätigung, dass sie verstanden wurde.
Absichts-Weiche bei Video
Die Bildunterschrift entscheidet über die Verarbeitung. Mit Bildunterschrift gilt ein Video als Baumaterial: Die Datei wird gesichert, der Text darunter startet den Auftrag. Ohne Bildunterschrift gilt es als Botschaft und wird in Einzelbilder und ein Transkript zerlegt. Derselbe Merksatz trägt alle Kanäle: Bildunterschrift ist der Auftrag, Anhang ist das Material.
Album als eine Sendung
Mehrere Fotos oder Dateien in einer Sendung werden über ein kurzes Sammelfenster als Gruppe erkannt und als ein einziger Auftrag verarbeitet, Originaldateinamen bleiben erhalten. Mengenregel: bis zehn Dateien als Album, elf bis dreißig gebündelt als Archiv, größere Mengen direkt am Rechner ablegen und per Chat beauftragen.
Nur du kannst mit deinem System sprechen.
Ein Kanal, eine Identität, kein offenes Tor. Selbst wer die Adresse kennt, kommt ohne deine Identität nicht hinein.
Identitäts-Whitelist statt offener Fläche.
Das System reagiert ausschließlich auf die serverseitig zugeordnete Identität seines Auftraggebers. Es gibt keine Anwendungsschnittstelle, die von außen angreifbar wäre.
Türsteher an der Tür
Jede Nachricht wird geprüft, bevor sie zählt. Nur deine eigene, verknüpfte Identität öffnet das System, niemand sonst.
Ein einziger Kanal
Kein Login, keine Web-Oberfläche, keine zweite Tür. Der abgesicherte Chat ist der einzige Weg hinein und hinaus.
Klare Kontrolle
Aufträge kommen von genau einer Stelle, Ergebnisse gehen an genau diese Stelle zurück. Nichts verzweigt sich unterwegs.
Identitäts-Whitelist
Eingehende Nachrichten werden gegen die hinterlegte Identität des Auftraggebers geprüft. Alles andere wird verworfen, unabhängig vom Inhalt.
Serverseitige Stempelung
Die Zuordnung der Identität erfolgt auf dem Server, nicht anhand von Angaben im Chat selbst. Eine vorgetäuschte Absenderangabe verändert nichts.
Kein exponierter Port
Es existiert keine erreichbare Anwendungsschnittstelle, die von außen adressiert werden könnte. Angriffsfläche, die es nicht gibt, muss auch nicht verteidigt werden.
Volle Kostentransparenz statt Blackbox.
Du weißt vorab, was eine Aufgabe ungefähr kostet, siehst jederzeit, was bereits verbraucht wurde, und zahlst nie mehr, als dein Limit erlaubt. Keine bösen Überraschungen im Nachhinein.
Token-Buchhaltung, Limit-Status, Modell nach Aufgabe.
Das Präfix kosten: liefert eine Aufwandsschätzung, ohne dass etwas gebaut, delegiert oder deployt wird. Verbrauch und Limit-Status sind jederzeit per Befehl abrufbar, abgerechnet wird in Abo-Limits, nicht in Dollar.
Schätzung vor dem Start
Auf Wunsch bekommst du vor jeder größeren Aufgabe eine Aufwandsschätzung: ungefähre Dauer, Größenordnung des Verbrauchs und ein Dollar-Gegenwert zur Einordnung, in mehreren Varianten für denselben Umfang.
Verbrauch jederzeit einsehbar
Ein einfacher Befehl zeigt, was bislang verbraucht wurde und wie dein Limit-Status steht. Keine Blackbox, keine Abrechnung erst im Nachhinein.
Keine Zusatzkosten im Rahmen des Abos
Das System läuft auf einem Abo, das in Limits rechnet statt in Dollar. Solange dein Status erlaubt ist, entstehen keine zusätzlichen Kosten.
Vollbilanz nach jedem Auftrag
Nach jedem Auftrag steht eine vollständige Abrechnung: getrennt nach frischem Input, Output sowie Cache-Aufbau und Cache-Lesen mit Prozent-Anteil, dazu eine Zeile je eingesetztem Modell. So siehst du, welche Personal-Stufe was gekostet hat.
Hauptsession und Teamkosten
Eine Zeile zeigt nur deinen direkten Draht zum Chief of Staff, eine zweite summiert alle eingesetzten Rollen einschließlich der Subagenten. Die Team-Zeile bildet die tatsächlichen Vollkosten eines Auftrags ab.
Geprüfte Zahlen mit Einordnung
Die Beträge stammen aus der offiziellen Abrechnung, inklusive der Verbilligung durch Cache-Treffer. Ein hoher Cache-Lesen-Anteil bei kleinen Aufträgen zeigt einen langen mitgeschleppten Verlauf, ein frischer Start senkt die Kosten spürbar.
Schätzung ohne Ausführung
Das Präfix kosten: liefert für denselben Aufgabenumfang mehrere Prozess-Varianten (z. B. direkt vs. PR mit Preview), je mit geschätzter Dauer, Token-Größenordnung, Dollar-Gegenwert und Team-Zuschnitt. Es wird nichts gebaut, committet oder deployt.
Token-Buchhaltung & Limit-Status
Ein Befehl zeigt den bisherigen Verbrauch und den aktuellen Limit-Status. Solange er erlaubt ist, entstehen keine Zusatzkosten, das Abo rechnet in Limits statt in Dollar.
Starke Modelle an Entscheidungsstellen
Entscheidungs- und Bauverantwortung liegt auf Opus 5, klar spezifizierte Arbeit in der Fläche läuft auf Sonnet. So bleibt der Aufwand pro Ergebnis niedrig, unabhängig vom Umfang. Das Gutachten läuft bewusst auf Fable, dem stärksten Modell für reine Urteilsfragen ohne Werkzeugeinsatz. Ein anderes Modell prüft zudem mit anderen Denkmustern als die bauenden Rollen.
Vollbilanz und Modell-Matrix
Jeder Auftrag schließt mit einer vollständigen Bilanz. Sie trennt frischen Input, Output, Cache-Aufbau und Cache-Lesen mit Prozent-Anteil und ergänzt eine Zeile je eingesetztem Modell, Token und Kosten, sortiert nach Kosten. So bleibt sichtbar, welche Personal-Stufe welchen Anteil trägt.
Hauptsession gegen Team-Summe
Die Hauptsession-Zeile erfasst ausschließlich den Token-Strom der dirigierenden Session. Eine zusätzliche Team-Zeile summiert sämtliche Instanzen einschließlich aller Subagenten, die im Auftrag liefen. Diese Team-Zeile bildet die tatsächlichen Vollkosten ab, die Hauptsession-Zeile allein unterschätzt sie systematisch.
Herkunft und Lesehilfe
Die Beträge stammen aus der offiziellen Abrechnung, inklusive der Verbilligung durch Cache-Treffer. Dollar-Werte dienen der Einordnung, abgerechnet wird in Nutzungs-Limits. Ein hoher Cache-Lesen-Anteil bei kleinen Aufträgen weist auf einen langen mitgeschleppten Sessionverlauf hin, ein frischer Start senkt die Kosten deutlich.
Baut alles, was du willst. Nur nicht an der eigenen Kontrolle.
Das System arbeitet an allem, was du beauftragst, aber niemals an seiner eigenen Steuerung. Drei ineinandergreifende Ebenen sichern das ab, von der Infrastruktur bis zu den eigenen Regeln.
Cloud- und Infrastruktur-Ebene
Die Umgebung, in der das System läuft, bleibt für es unsichtbar. An seinem eigenen Fundament kann es nichts sehen und nichts ändern.
Betriebssystem-Ebene
Der Unterbau der Maschine ist für das System gesperrt. Es arbeitet in seinem Bereich, ohne an den Grundlagen drehen zu können.
Eigenes Kontrollsystem
Seine eigene Steuerung und seine Regeln kann das System nicht umschreiben. Die Kontrolle über den Kanal nach außen bleibt fest verankert.
Arbeitsbereich der Firma
Hier entsteht frei, was du beauftragst. Volle Tatkraft für deine Aufträge, ohne Zugriff auf die eigene Kontrolle.
Wir haben es an uns selbst gebaut. Bei dir bauen wir es auch.
Der Aufbau auf dieser Seite ist übertragbar, die Konfiguration dahinter ist an unseren Betrieb gewachsen. Wo bei dir Agenten Arbeit übernehmen können und wo besser nicht, ist eine Rechenaufgabe, und die steht bei uns am Anfang. Rechnet sich ein Fall nicht, hörst du das genauso klar.
Wie das Team arbeitetDer Aufbau ist dokumentiert. Die Übertragung ist Arbeit.
Agentisch Skalieren beschreibt einen Reifegrad-Weg von der Assistenz bis zum autonomen System. chatCOS steht auf der obersten Stufe dieses Wegs, und der Betrieb darüber ist auf dieser Seite aufgeschrieben, Fehlschläge eingeschlossen. Die Übertragung auf einen anderen Betrieb ist der Teil, den wir als Leistung anbieten, von der Analyse bis in den laufenden Betrieb.
Sicherheitsmodell