Domain-Portal: vom Reseller-Account zum automatischen Domain-Geschäft, gebaut mit einem AI-Agenten-Team
Wie ich mit parallelen Claude-Code-Sessions, einem Koordinator und einem Review-Board aus Agentenrollen ein Domain-Portal von der Bestellung bis zur Rechnung gebaut und in Betrieb genommen habe – und welche Regeln das Agenten-Team sicher gemacht haben.
Seit dem 24. Oktober 2026 läuft unter chnet.domains ein Domain-Geschäft, das ich nicht von Hand betreibe: Kundinnen und Kunden suchen eine Domain, bestellen, bezahlen, bekommen ihre Rechnung und verwalten ihre Domains im Portal. Am 26. Oktober lief die erste Registrierung vollautomatisch durch, ohne dass ich einen Knopf gedrückt habe. Gebaut und betrieben habe ich das nicht mit einem Entwicklerteam, sondern mit einem Team aus AI-Agenten. Dieser Beitrag handelt von dieser Arbeitsweise; die Abrechnungsarchitektur bekommt einen eigenen Beitrag.
Ausgangslage
Ich verwalte über einen Reseller-Account bei einem Hoster Domains für Kunden, darunter ein Bestandskunde mit rund 70 Domains. Der Ablauf lief über drei getrennte Systeme: ein Bestellsystem für die Registrierung, die technische Verwaltung der Domains und die Buchhaltung. Jeder Kundenwunsch bedeutete nach meiner eigenen Schätzung rund eine Stunde Klickarbeit, die Rechnungen entstanden als Serienrechnung von Hand, und Kunden hatten keinen Einblick in ihren Bestand.
Das Ziel war deshalb nicht „ein hübsches Portal“, sondern: Bestellung bis Registrierung ohne Admin, der Mensch nur noch für Ausnahmen. Für eine Ein-Personen-Beratung ist das ein Projekt, das ich klassisch nie nebenbei angefangen hätte. Mit einem Agenten-Team war es realistisch, sofern das Team Regeln hat, die es sicher machen.
Lösung
Das Produkt. Eine Landingpage mit Domainsuche und KI-gestützten Namensvorschlägen, ein Kundenportal mit Login und ein serverloses Backend, komplett in AWS CDK beschrieben: Lambda-Funktionen, DynamoDB, Cognito für die Anmeldung und Step Functions für die langen Abläufe. Ein Bestellprozess kann Tage dauern, weil er auf eine Zahlung, eine Prüfung oder eine Rückmeldung der Registry wartet; dafür nutze ich Wartezustände mit Task-Token, die einen Workflow anhalten, bis ein externes Ereignis ihn fortsetzt. Bezahlt wird per Karte über Stripe oder über PayPal, die Rechnungen entstehen in Lexware Office. Die Namensvorschläge kommen aus einem kleinen Modell auf Amazon Bedrock, abgesichert durch eine Guardrail, eine harte Budgetgrenze und eine Golden-Eval als Release-Gate: Eine neue Prompt- oder Modellversion geht nur live, wenn sie einen festen Satz an Referenzfällen besteht.
Jeder schreibende Aufruf beim Registrar kostet Geld, auch ein fehlgeschlagener. Wie das Portal gegen doppelt berechnete Aufrufe geschützt ist, beschreibe ich in einem separaten Beitrag.
Das Team. Gearbeitet haben mehrere parallele Claude-Code-Sessions, die ich „Lanes“ nenne. Jede Lane hat ein festes Thema, etwa Zahlungen, Domain-Einstellungen oder Landingpage, und arbeitet in einem eigenen Git-Worktree. Dadurch kommen sich die Lanes im Dateisystem nicht in die Quere, und jede liefert ihre Arbeit als eigenen Pull Request.
Über den Lanes sitzt eine Koordinator-Session. Sie serialisiert Merges und Deploy-Auslösungen und gibt jeder Lane ein ausdrückliches GO, bevor diese etwas auf den Hauptzweig bringt. Eine weitere Session ist die Schnittstelle zum Menschen, also zu mir. Mit den Lanes rede ich kaum direkt; Fragen, Entscheidungsvorlagen und Freigaben laufen über diese eine Stelle.
Pläne und größere Änderungen prüft ein Review-Board aus Agentenrollen: Architekt, Security, Senior Developer, FinOps und ein Skeptiker. Das ist kein Ritual. Schon die erste Konzeptprüfung hat den Bauplan umgedreht: Der Skeptiker hielt fest, dass der eigentliche Schmerz die vergessene Abrechnung ist, nicht der fehlende Self-Service. Also kam zuerst eine Admin-Version mit automatischer Abrechnung, danach der Kunden-Login und erst danach die Bestellung.
Leitplanken
Agenten schreiben schnell Code. Die eigentliche Arbeit lag darin, Regeln zu finden, unter denen ich diesem Tempo trauen kann. Diese haben sich bewährt:
- Der Mensch entscheidet über Geld, Recht und Öffentlichkeit. Kostenpflichtige Aktionen, Rechtstexte und veröffentlichte Texte gehen nur mit meiner ausdrücklichen Freigabe raus. Alles andere dürfen die Lanes selbstständig erledigen.
- Schalter statt Deploys. Neue Funktionen gehen inaktiv live und werden über Laufzeit-Schalter in der Konfiguration aktiviert. Ein Schalter ist in Sekunden umgelegt und genauso schnell zurück; ein Deploy nicht.
- Dry Run als Standard. Jedes Betriebsskript zeigt zuerst nur, was es tun würde. Schreiben erfordert einen ausdrücklichen Parameter.
- Ein lokales Quality Gate vor jedem Push. SonarQube prüft lokal, bevor Code den Rechner verlässt, und pro Pull Request gibt es genau einen Push. Das spart CI-Läufe und verhindert, dass Lanes sich gegenseitig rote Pipelines hinterlassen.
- Nach einem Abbruch erst den Serverzustand prüfen. Ein abgebrochener Befehl ist kein nicht ausgeführter Befehl. Vor jeder Wiederholung wird nachgesehen, was tatsächlich passiert ist.
- Ein Nadelöhr für den Hauptzweig. Nur der Koordinator gibt Merges und Deploys frei, einer nach dem anderen, und erst nachdem der vorherige Lauf verifiziert ist.
Ergebnis
Die ersten Commits für das Portal stammen vom 16. Oktober 2026, am 24. Oktober ging es live, am 26. Oktober lief die erste vollautomatische Registrierung. In dieser Zeit sind auf dem Hauptzweig rund 300 Pull Requests für Portal und Landingpage gemergt worden. Kunden verwalten heute ihre Domains, DNS-Einträge und Weiterleitungen selbst und laden ihre Rechnungen im Portal herunter.
Offen ist noch einiges: Lastschrift gibt es noch nicht, und Nameserver können Kunden noch nicht selbst ändern. Automatisch registriert wird vorerst nur eine Endung; weitere folgen nach eigenen Testregistrierungen.
Was nicht reibungslos lief
- Koordination kostet. Der Koordinator ist ein Engpass mit Absicht, aber ein Engpass. Lanes warteten auf ihr GO, während eine andere Lane ihren Deploy verifizierte. Parallelität im Code heißt nicht Parallelität beim Ausrollen.
- Merges, die sich gegenseitig verdrängen. Die CI hält pro Zweig nur den jüngsten wartenden Deploy vor. Folgen zwei Merges zu schnell aufeinander, verwirft sie den älteren wartenden Deploy stillschweigend. Genau deshalb läuft alles über den Koordinator, auch meine eigenen Merges.
- Geteilte Werkzeuge. Mehrere Lanes teilen sich eine SonarQube-Instanz. Ein lokaler Scan, der zeitgleich mit dem Scan auf dem Hauptzweig lief, konnte diesen scheitern lassen. Lösung: vor jedem Scan prüfen, ob gerade ein Lauf auf dem Hauptzweig aktiv ist.
Transfer
Das Muster ist nicht an Domains gebunden. Es passt überall dort, wo ein kleines Team, im Extremfall eine Person, ein Produkt mit echten Geldflüssen bauen und betreiben will:
- Feste Lanes in eigenen Worktrees lassen sich 1:1 übernehmen. Entscheidend ist ein klar geschnittenes Thema pro Lane, damit Konflikte selten bleiben.
- Ein Koordinator für den Hauptzweig ist in jedem Team mit mehr als einer Agenten-Session sinnvoll, sobald Deploys automatisch an Merges hängen.
- Eine einzige Schnittstelle zum Menschen hält die Zahl der Rückfragen beherrschbar. Wichtig ist, vorab festzulegen, welche Entscheidungen beim Menschen bleiben: bei mir Geld, Rechtstexte und Veröffentlichungen.
- Ein Review-Board aus Rollen lohnt sich vor allem bei Konzepten; die wertvollste Stimme war oft die des Skeptikers.
Nicht 1:1 übertragbar ist das Vertrauensniveau. In einem Unternehmen mit bestehender Freigabe- und Betriebsorganisation müssen Schalter, Dry Runs und Freigaben in die vorhandenen Prozesse eingehängt werden, statt sie zu ersetzen. Das Prinzip bleibt dasselbe: Agenten bekommen Tempo, Menschen behalten die Entscheidungen mit Konsequenzen.
Stack: Claude Code · AWS CDK · AWS Lambda · AWS Step Functions · DynamoDB · Amazon Cognito · Amazon Bedrock · Stripe · PayPal · Lexware Office · Astro · SonarQube