Wie ich aus einer Messenger-App ein Betriebssystem für Domain Agents gebaut habe

Ich wollte keinen Super-Agenten

Die naheliegende Idee bei persönlichen AI Agents ist ein einziger großer Chat:

Schreib meinen Content.
Prüf das neue Feature.
Such eine Wohnung.
Analysiere eine Aktie.
Überwache den Server.
Merke dir alles.

Das funktioniert erstaunlich lange.

Bis der Agent anfängt, den falschen Kontext in die richtige Aufgabe zu mischen. Eine technische Diskussion beeinflusst plötzlich einen Blogtext. Eine alte Entscheidung taucht in einem neuen Projekt auf. Der Agent hat immer mehr Memory, aber immer weniger Klarheit darüber, was davon gerade relevant ist.

Mein Ausweg war nicht ein größeres Modell und auch nicht ein noch längerer System Prompt.

Ich habe dem Agenten Arbeitsräume gegeben.

Heute nutze ich eine Messenger-App als Control Plane für mehrere fachliche Bereiche: Content, Softwareentwicklung, Research, Investments, Immobilien und operative Projekte. Jeder Bereich hat einen eigenen Chat und damit eine getrennte Session mit eigenem Verlauf.

Diese Sessions sind aber keine getrennten Bots. Sie sind mehrere fachliche Fenster auf dieselbe agentische Runtime. Je nachdem, in welchem Raum ich schreibe, lädt die Runtime ein anderes Domain-Profil: passende Regeln, erlaubtes Memory, Skills, Tools und wiederkehrende Abläufe.

Der „Domain Agent“ ist damit keine eigene laufende Instanz, sondern die fachliche Form, die die gemeinsame Runtime innerhalb eines bestimmten Chat-Raums annimmt. Im Alltag fühlt sich das trotzdem wie ein kleines Team spezialisierter Domain Agents an.

Über diesen operativen Räumen liegt mein Direktchat mit Boba. Dieser DM ist nicht einfach eine weitere Fachabteilung. Er ist mein Architektenraum und die Agent Factory: Dort beschreibe ich eine neue Domain, und Boba führt mich durch ein festes Playbook, bis daraus ein klar begrenzter Arbeitsraum mit überprüfbarem Verhalten geworden ist.

1

gemeinsame agentische Runtime

6

getrennte Chat-Sessions als fachliche Fenster

1

zentraler Boba-DM als Agent Factory

Die kurze Version

Ein Domain Agent entsteht in meinem Setup weder durch einen Namen oder eine Persona noch durch eine zusätzliche Runtime.

Alle Chat-Sessions laufen über dasselbe Agent-System. Die Spezialisierung entsteht erst dadurch, dass der jeweilige Raum fünf konkrete Grenzen für die gemeinsame Runtime setzt:

1. Ein eigener Arbeitsraum: Der Chat bestimmt, zu welcher Domain eine Aufgabe gehört.
2. Ein Operating Contract: Regeln legen Zuständigkeit, erlaubte Aktionen, Freigaben und Ergebnisform fest.
3. Kuratiertes Memory: Jede Domain erinnert ihre eigenen Entscheidungen, nicht automatisch alles über mich.
4. Passende Skills und Tools: Der Agent lädt nur die Arbeitsverfahren und Fähigkeiten, die zur Aufgabe passen.
5. Überprüfbare Flows: Wiederkehrende Arbeit folgt einem Ablauf mit Trigger, Artefakt, Verifikation und Übergabe.

Der Boba-DM ist meine Agent Factory

Die Domain-Chats beantworten die Frage: Wo wird gearbeitet?

Der direkte Chat mit Boba beantwortet eine andere Frage: Wie entsteht ein neuer Arbeitsraum?

Ich nutze diesen DM als übergeordnete Architektenebene. Wenn etwa ein neuer Raum für ein Hedgefund-Experiment, ein Immobilienprojekt oder „Project X“ gebraucht wird, kopiere ich nicht einfach einen alten Prompt und vergebe einen neuen Namen. Boba konstruiert das Domain-Profil gemeinsam mit mir nach einem festen Playbook:

1. Zweck und konkrete Aufgaben klären
2. Zuständigkeit und Nicht-Ziele abgrenzen
3. Operating Contract und Freigaben definieren
4. erlaubtes Memory festlegen
5. Skills, Tools und isolierte Workflows auswählen
6. Chat-Raum und Domain-Profil anlegen
7. mit einer realen Aufgabe testen
8. Ergebnis, Evidenz und Grenzen abnehmen

Erst danach ist der neue Domain Agent betriebsbereit. Die Factory erzeugt dabei keinen weiteren Bot und keine zweite Runtime. Sie konfiguriert eine neue fachliche Projektion derselben Runtime und gibt ihr einen eigenen Session-Verlauf, Regeln, Fähigkeiten und Governance-Grenzen.

Damit gibt es zwei klar getrennte Ebenen:

• Boba-DM / Agent Factory: entwirft, verändert und prüft Domain Agents.
• Domain-Räume: führen die fachliche Arbeit innerhalb ihrer definierten Grenzen aus.

Diese Trennung verhindert Wildwuchs. Neue Räume folgen demselben Konstruktionsverfahren, haben aber nicht automatisch dieselben Daten, Tools oder Rechte.

Das Modell ist wichtig. Aber es ist nicht die Architektur.

Die Architektur entscheidet, welchen Kontext das Modell bekommt, welche Werkzeuge es benutzen darf, wann es handeln soll und woran ein erfolgreicher Lauf erkennbar ist.

Chats sind bei mir keine Ordner. Sie sind Zuständigkeitsgrenzen

Der Screenshot aus meinem echten Telegram-Setup zeigt den Unterschied besser als jede abstrakte Architekturzeichnung: Investing, Huecki-blog, Immobilien, KI-Projekt Bau oder Agent-buildprint erscheinen als eigenständige Arbeitsräume. In allen antwortet Boba. Hinter der Oberfläche laufen aber nicht fünf separat gebaute Bots.

Für kleine Firmen fühlt sich das wie ein digitales Team an

Das Modell ist nicht nur für persönliche Experimente oder große Agentenplattformen interessant. Gerade in einer kleinen Firma bleiben viele wichtige Aufgaben an wenigen Menschen hängen: Website pflegen, Social Media betreuen, recherchieren, SEO verbessern und Leads nachfassen.

Mein zugeschnittener Slack-Ausschnitt macht diesen Kontext greifbar. Statt technischer Namen stehen dort Rollen, die jeder im Unternehmen sofort versteht: Homepage Horst, Instagram Ingrid, LinkedIn Lukas, Researcher Rolf, SEO Sigrid und Vertrieblerin Veronika.

Die Namen sind die benutzerfreundliche Oberfläche, nicht die technische Architektur. Hinter jeder Rolle liegt ein eigener Arbeitsraum mit fachlichem Verlauf, Domain-Profil und festem Workflow. Darunter arbeitet weiterhin dieselbe agentische Runtime.

So könnte die Arbeitsteilung aussehen:

Homepage Horst
→ prüft Website, Inhalte und technische Auffälligkeiten

Instagram Ingrid und LinkedIn Lukas
→ beobachten ihre Kanäle, planen Formate und bereiten Beiträge vor

Researcher Rolf
→ sammelt Quellen und liefert belegte Briefings an die anderen Rollen

SEO Sigrid
→ priorisiert Suchthemen und prüft veröffentlichte Inhalte

Vertrieblerin Veronika
→ qualifiziert neue Leads und bereitet den nächsten Kontakt vor

Der Vorteil für eine kleine Firma ist nicht eine möglichst große Zahl künstlicher Mitarbeiter. Der Vorteil ist, dass Routinearbeit sichtbare Zuständigkeiten bekommt. Jede Rolle folgt ihrem spezialisierten Schema, kann nach Zeitplan oder Ereignis proaktiv anlaufen und übergibt ihr Ergebnis an den passenden Menschen oder die nächste Rolle.

Die Governance bleibt dabei dieselbe: Recherche, Analyse und interne Entwürfe dürfen weitgehend automatisch laufen. Veröffentlichungen, Kundennachrichten, Angebote oder andere externe Aktionen folgen den festgelegten Freigaben.

Ich behandle jeden dieser Chats wie eine kleine Abteilung. Technisch ist er eine eigene Session auf derselben Runtime; operativ gibt er ihr eine andere Zuständigkeit.

Der Content-Bereich darf Themen recherchieren, Ideen bewerten, Drafts erzeugen und Builds prüfen. Er darf aber nicht selbstständig veröffentlichen.

Der Software-Bereich arbeitet näher an Repositories, Tests und technischen Proof-Artefakten. Dort ist eine gute Antwort weniger wichtig als ein reproduzierbarer Check.

Der Investment-Bereich trennt Fakten, Annahmen, Risiken und Unsicherheit. Aktuelle Aussagen brauchen aktuelle Quellen. Ein selbstbewusster Ton ersetzt dort keine belastbare Evidenz.

Andere Bereiche haben wiederum andere Arbeitsweisen, Freigaben und Ausgabeformate.

Das Entscheidende ist: Ein Wechsel von „Investing“ zu „Immobilien“ startet nicht einfach einen neuen Bot. Er wechselt den Betriebskontext derselben agentischen Runtime. Die Session liefert den fachlichen Verlauf und das Routing-Signal; das Domain-Profil ergänzt Regeln, relevantes Memory, Skills, Tools und Freigabegrenzen.

So bleibt die Identität des Assistenten konsistent, ohne dass alle Themen in einem riesigen Kontexttopf landen. Die Räume sehen für mich wie ein Team aus. Unter der Haube sind sie kontrollierte Projektionen desselben Systems.

Drei Domain Agents, die nicht nur für Entwickler interessant sind

Die Architektur wird verständlicher, wenn man sie nicht an abstrakten Agentenbegriffen, sondern an alltäglichen Aufgaben betrachtet.

Influencer Manager: ein operativer Social-Media-Arbeitsraum

Der Influencer Manager betreut Social-Media-Accounts nach einem eigenen Content- und Community-Schema. Er beobachtet relevante Signale, verdichtet Trends und Performance, pflegt den Redaktionsfluss und bereitet Content sowie nächste Aktionen vor.

Sein Workflow kann beispielsweise so aussehen:

Accounts und Signale beobachten
→ relevante Trends und Kommentare priorisieren
→ Content-Idee und Format auswählen
→ Entwurf oder Medienpaket vorbereiten
→ Qualitäts- und Brand-Check durchführen
→ nach geltender Freigaberegel planen oder veröffentlichen
→ Performance zurück in das Domain-Memory spielen

Der wichtige Punkt ist nicht, dass ein Modell einen Post schreiben kann. Der Manager betreut den Kreislauf rund um den Account. Er arbeitet proaktiv, meldet Chancen oder Probleme im Messenger und führt vorab erlaubte Routinen automatisch aus. Was öffentlich gepostet oder beantwortet werden darf, bestimmt sein Operating Contract.

Investing: beobachten, prüfen und rechtzeitig melden

Der Investing Agent arbeitet nach einem Recherche- und Risikoschema statt nach Bauchgefühl. Er kann Watchlists beobachten, neue Unternehmensmeldungen oder Marktbewegungen erkennen und eine bestehende These gegen aktuelle Evidenz prüfen.

Watchlist oder Ereignis
→ aktuelle Primärquellen und Marktdaten
→ Fakten von Annahmen trennen
→ These, Gegenargumente und Risiken aktualisieren
→ Relevanzschwelle prüfen
→ kompaktes Briefing oder Alarm in den Investing-Chat

So muss ich nicht ständig selbst Kurse und Nachrichten aktualisieren. Der Agent wird aktiv, wenn ein definiertes Signal relevant wird. Er liefert eine Entscheidungsvorlage – keine ungeprüfte Gewissheit und keinen eigenmächtigen Trade.

Immobilien: neue Angebote gegen das echte Suchprofil prüfen

Der Immobilien Agent kennt nicht einfach nur ein paar Suchbegriffe. Sein Domain-Profil enthält das konkrete Suchschema: Lage, Budget, Größe, Zustand, Ausschlusskriterien und die Gewichtung wichtiger Kompromisse.

neue Angebote einsammeln
→ Duplikate und unpassende Treffer entfernen
→ Muss-Kriterien und Ausschlüsse prüfen
→ Preis, Lage und Risiken bewerten
→ passende Objekte als Dossier aufbereiten
→ bei einem starken Treffer proaktiv benachrichtigen

Das spart nicht nur Suchzeit. Der Agent wendet bei jedem Objekt dieselben Kriterien an und hält fest, warum ein Treffer interessant oder ungeeignet ist. Eine Kontaktaufnahme oder Bewerbung bleibt ein eigener, freigabepflichtiger Schritt.

Alle drei Räume nutzen dieselbe Runtime. Trotzdem handeln sie nicht gleich, weil Trigger, Prüfschema, Tools, Ergebnisform und Autonomiegrenzen je Domain verschieden sind.

Ein großer Assistent vs. Domain-Arbeitsräume

Ein großer Chat

• Jede Aufgabe landet im selben Kontext.
• Memory wächst zu einem großen persönlichen Datenhaufen.
• Eine globale Antwortlogik für alle Themen.
• Der Agent muss Relevanz aus der gesamten Historie erraten.
• Mehr Fähigkeiten bedeuten schnell mehr Unklarheit.

Domain-Agent-System

• Getrennte Sessions spiegeln dieselbe Runtime in fachlich begrenzte Arbeitsräume.
• Entscheidungen werden dort gespeichert, wo sie später wieder gebraucht werden.
• Jede Domain definiert Ton, Evidenz, Freigaben und Ergebnisform.
• Der Chat liefert bereits ein starkes Routing-Signal.
• Skills und Tools werden passend zur Aufgabe ausgewählt.

Der Messenger wird dadurch zu einem einfachen Router vor der gemeinsamen Runtime:

Boba-DM / Agent Factory
→ konstruiert und prüft ein Domain-Profil nach Playbook
→ legt einen begrenzten Chat-Arbeitsraum an

Domain-Chat
→ getrennte Session und eigener Verlauf
→ dieselbe agentische Runtime
→ passendes Domain-Profil
→ begrenztes Memory, Skills und Tools
→ passende Ergebnisform und Freigaben

Das ist im Alltag so simpel wie das Öffnen des richtigen Chats. Gleichzeitig ist es strukturiert genug, um daraus ein belastbares Agent-System aufzubauen.

Proaktiv heißt: Der Workflow wartet nicht auf meinen Prompt

Die Domain Agents reagieren nicht nur, wenn ich eine Frage in den Chat tippe. Sie können auch durch einen Zeitplan oder ein fachliches Ereignis gestartet werden:

Zeitplan oder relevantes Ereignis
→ Domain-Workflow startet
→ Quellen und Zustand werden geprüft
→ Ergebnis überschreitet eine definierte Relevanzschwelle
→ Agent handelt innerhalb seiner Freigaben
→ Messenger liefert Ergebnis, Warnung oder Entscheidungspunkt

Der Influencer Manager kann auf neue Social-Media-Signale reagieren. Der Investing Agent meldet eine relevante Veränderung an einer beobachteten These. Der Immobilien Agent weist auf ein neues Objekt hin, das das Suchprofil wirklich erfüllt.

Proaktivität bedeutet dabei nicht grenzenlose Autonomie. Ein Agent soll selbstständig beobachten, filtern, prüfen und vorbereiten. Bei öffentlichen Posts, finanziellen Transaktionen oder externen Kontaktaufnahmen greifen die für seine Domain festgelegten Freigaben.

AI Governance ist mein Beschleuniger

Governance klingt für viele nach einem Gremium, das Innovation verlangsamt.

In meinem Setup bedeutet AI Governance fast das Gegenteil:

Je klarer die Grenzen sind, desto mehr Routinearbeit kann der Agent ohne Rückfrage erledigen.

Wenn ein Agent bei jeder gelesenen Datei, jedem lokalen Test und jedem Draft um Erlaubnis bitten muss, ist er kein produktiver Mitarbeiter. Wenn er dagegen ohne Rückfrage veröffentlicht, Menschen kontaktiert oder produktive Systeme verändert, ist er kein verantwortbares System.

Die nützliche Zone liegt dazwischen.

Ich teile Aktionen deshalb gedanklich in drei Klassen:

vorab erlaubt
  lesen, suchen, vergleichen, lokal testen, private Entwürfe erzeugen

beweispflichtig
  Code ändern, Konfiguration patchen, Builds ausführen, Ergebnisse bewerten

freigabepflichtig
  veröffentlichen, pushen, externe Nachrichten senden,
  irreversible oder öffentlich sichtbare Aktionen

Diese Einteilung ist kein theoretisches Compliance-Modell. Sie ist ein praktisches Interface zwischen Mensch und Agent.

Der Agent weiß, wo er selbstständig arbeiten darf. Ich weiß, an welchen Punkten ich bewusst die Verantwortung übernehme.

Meine Governance-Regeln für produktive Agenten

• Kontextzugriff ist nicht automatisch Nutzungserlaubnis: Der Agent lädt nur, was die aktuelle Domain braucht.
• Reversible interne Arbeit darf weitgehend autonom laufen.
• Öffentliche, externe oder schwer rückgängig zu machende Aktionen brauchen eine explizite Freigabe.
• Ein Ergebnis ist erst fertig, wenn passende Evidenz vorliegt: Build, Test, Quelle, Diff, Screenshot oder Live-Check.
• Der Agent meldet nicht nur Erfolg, sondern auch Blocker, Restunsicherheit und den nächsten Entscheidungspunkt.

So verstanden ist Governance keine Bremse. Sie ist die Voraussetzung dafür, dem Agenten mehr Verantwortung geben zu können.

Memory muss kleiner werden, nicht größer

Bei persönlichen AI-Systemen wird Memory oft wie ein Wettbewerb behandelt: Wer kann sich am meisten merken?

Ich halte das für die falsche Optimierung.

Die bessere Frage lautet:

Welche Erinnerung darf in welcher Situation eine Entscheidung beeinflussen?

In meinem Setup besitzt jede Domain einen eigenen Entscheidungsspeicher. Dort landen keine vollständigen Chatprotokolle als vermeintliche Wahrheit, sondern ausgewählte Dinge, die später wirklich nützlich sind:

• getroffene Entscheidungen
• geltende Arbeitsregeln
• bekannte Projektgrenzen
• offene Aufgaben
• geprüfte Learnings
• bewusst verworfene Ansätze

Privates, globales Memory wird nicht automatisch in Gruppen- oder Projektkontexte getragen.

Das schützt nicht nur Informationen. Es erhöht die Qualität.

Ein Agent, der weniger irrelevante Erinnerung sieht, muss weniger raten. Context Engineering ist deshalb für mich nicht die Kunst, möglichst viel in das Kontextfenster zu stopfen. Es ist die Disziplin, den richtigen Ausschnitt zur richtigen Zeit bereitzustellen.

Skills sind meine Standard Operating Procedures

Tools und Skills werden oft gleichgesetzt. Für den Betrieb macht die Trennung einen großen Unterschied.

Ein Tool kann eine Webseite öffnen, eine Datei bearbeiten, einen Test ausführen oder Marktdaten abrufen.

Ein Skill beschreibt, wie eine bestimmte Art von Arbeit zuverlässig erledigt werden soll.

Beispiele:

• Deep Research beginnt mit einer Forschungsfrage und endet mit Quellen, Evidenz und Konfidenznotizen.
• Browser-Automation definiert, wie Tabs, Logins, Timeouts und veraltete Seitenelemente behandelt werden.
• Debugging beginnt mit Reproduktion und Beobachtung, nicht sofort mit einem Patch.
• Ein Content-Skill trennt Signalbewertung, Drafting, Claim-Prüfung und Veröffentlichung.

Tool, Skill und Flow

Einzelne Fähigkeit

• Tool: kann eine Aktion ausführen.
• Prompt: beschreibt die aktuelle Aufgabe.
• Antwort: berichtet ein Ergebnis.
• Memory: speichert Kontext.

Operatives System

• Skill: kennt das wiederverwendbare Arbeitsverfahren.
• Operating Contract: definiert Grenzen und Erfolgskriterien.
• Flow: verbindet Trigger, Arbeit, Prüfung und Übergabe.
• Governance: entscheidet, welcher Kontext benutzt werden darf.

Meine Faustregel:

Wenn eine erfolgreiche Arbeitsweise wiederholt werden soll, darf sie nicht nur im Chatverlauf überleben.

Sie braucht eine klare Schnittstelle, ein erwartetes Ergebnis und einen Check, der zeigt, ob sie noch funktioniert.

Der Content-Flow als konkretes Beispiel

Mein Blog-Workflow zeigt gut, wie diese Bausteine zusammenspielen.

Jeden Morgen startet ein isolierter Research-Lauf. Er prüft Primärquellen und ausgewählte Kuratoren, verdichtet die Signale und schreibt ein privates Radar-Artefakt. Der Messenger-Chat erhält nur die wichtigsten Ergebnisse: Top-Signale, Blocker und eine Empfehlung, ob sich ein Draft lohnt.

In einem zweiten Flow wird das neueste Radar ausgewertet. Ein Artikel entsteht nur, wenn die Idee einen definierten Qualitätswert erreicht und einen praktisch nutzbaren Workflow enthält.

Danach endet die Autonomie.

Der Draft bleibt privat. Er wird lokal validiert. Veröffentlichung, Commit und Deployment benötigen meine Freigabe.

Das Beeindruckende an diesem Flow ist für mich nicht, dass ein Modell Text schreiben kann.

Das können inzwischen viele Modelle.

Der eigentliche Wert liegt in der Produktionslogik:

• Research und Schreiben sind getrennte Phasen.
• Schwache Themen erzeugen keinen Draft.
• Jeder Lauf hinterlässt ein Artefakt.
• Claims sollen auf Quellen oder eigene Betriebserfahrung zurückführbar sein.
• Ein lokaler Build prüft die technische Integrität.
• Der Agent darf vorbereiten, aber nicht eigenmächtig veröffentlichen.
• Das Ergebnis landet wieder im richtigen Arbeitsraum.

So wird aus „Schreib mir einen Blogpost“ ein kontrollierbarer Content-Prozess.

Subagents sind temporäre Spezialisten

Neben den dauerhaften Domain-Arbeitsräumen kann das System für größere Aufgaben temporäre Subagents einsetzen.

Das ist eine andere Form von Spezialisierung.

Eine Domain-Session hält fortlaufenden fachlichen Kontext innerhalb der gemeinsamen Runtime. Ein Subagent ist dagegen eine tatsächlich temporär gestartete Ausführung mit einer begrenzten Teilaufgabe: beispielsweise Quellen prüfen, einen Codepfad analysieren oder eine unabhängige Review durchführen. Danach liefert er sein Ergebnis zurück und verschwindet wieder aus dem kritischen Pfad.

Ich nutze dieses Muster nicht, um möglichst viele Agenten zu zählen.

Ich nutze es, wenn Parallelisierung oder eine unabhängige Sicht den Lauf tatsächlich verbessert.

Domain-Session
  projiziert die gemeinsame Runtime in einen fachlichen Arbeitsraum

Subagent
  ist eine temporäre Ausführung für eine klar begrenzte Teilfrage

Skill
  liefert das wiederverwendbare Verfahren

Tool
  führt die konkrete Aktion aus

Diese Trennung verhindert, dass „Multi-Agent“ nur zu einem teuren Rollenspiel mehrerer Modelle wird.

Warum eine Messenger-App als Control Plane funktioniert

Eine Messenger-App ist keine perfekte Oberfläche für jedes Detail. Für die Steuerung persönlicher Agents hat sie aber starke Eigenschaften:

• Sie ist mobil und immer verfügbar.
• Text, Sprache, Bilder und Dateien landen am selben Ort.
• Rückfragen und Freigaben sind natürliche Chat-Aktionen.
• Jeder Domain-Chat ist gleichzeitig Verlauf, Inbox und Statuskanal.
• Ergebnisse können proaktiv zugestellt werden, ohne ein Dashboard öffnen zu müssen.

Der entscheidende Wechsel lautet:

nicht App öffnen → Formular finden → Workflow starten

sondern

Absicht formulieren → Agent wählt Verfahren → Ergebnis prüfen

Das Interface ist Intent-first.

Ein Dashboard bleibt sinnvoll, wenn ich viele Zustände vergleichen oder historische Metriken sehen will. Für Delegation, Rückfragen und Freigaben ist ein Messenger oft die schnellere Control Plane.

Was ich bewusst nicht automatisiere

Ein gutes Agent-System zeigt seine Reife nicht daran, dass es alles selbst darf.

Es zeigt sie daran, dass es sauber zwischen Vorbereitung, Ausführung und Verantwortung trennt.

Autonomie mit klaren Grenzen

Automatisieren

• ✓ Research sammeln, strukturieren und mit Quellen versehen
• ✓ private Drafts und Entscheidungsvorlagen erzeugen
• ✓ lokale Builds, Tests und Health Checks ausführen
• ✓ wiederkehrende Signale überwachen und verdichten
• ✓ Blocker und Freigabepunkte präzise melden

Nicht stillschweigend automatisieren

• × öffentliche Inhalte ohne Review veröffentlichen
• × Menschen im Namen des Nutzers kontaktieren
• × private Erinnerung zwischen Domains vermischen
• × riskante Änderungen nur aufgrund einer plausiblen Antwort akzeptieren
• × Fehler hinter einer freundlichen Erfolgsmeldung verstecken

Mein Ziel ist nicht maximale Autonomie.

Mein Ziel ist maximale nützliche Autonomie innerhalb nachvollziehbarer Grenzen.

Das Modell ist austauschbar. Das Operating System bleibt

Modelle werden besser, günstiger und schneller. Deshalb versuche ich, möglichst wenig Systemwissen ausschließlich an ein bestimmtes Modell zu binden.

Die dauerhaften Assets meines Setups sind:

• Domain Contracts
• kuratiertes Memory
• Skills
• Tool-Grenzen
• Verifikationsregeln
• Flow-Definitionen
• Run-Artefakte
• Freigabepunkte

Ein besseres Modell kann dieses System leistungsfähiger machen. Es ersetzt das System aber nicht.

Das ist vielleicht meine wichtigste technische Erkenntnis aus dem Betrieb:

Der Model Call ist eine Komponente. Das Produktverhalten entsteht im Harness darum herum.

Mein Best-Practice-Blueprint

Wer ein ähnliches Setup bauen will, sollte nicht mit zehn Agenten anfangen.

Ich würde in dieser Reihenfolge vorgehen:

1. Eine zentrale Factory-Ebene bestimmen. Bei mir ist das der Boba-DM, in dem neue Domain Agents konstruiert und später verändert werden.
2. Eine echte Domain auswählen. Nicht „persönlicher Assistent“, sondern beispielsweise Content Research, Software Reviews oder Immobilien-Suche.
3. Zweck und Nicht-Ziele klären. Die Factory hält fest, wofür der Raum zuständig ist und was ausdrücklich außerhalb seines Mandats liegt.
4. Ein kurzes Operating Contract schreiben. Zweck, erlaubte Arbeit, Freigaben, Evidenz und Ausgabeform.
5. Memory, Skills und Tools begrenzen. Nur freigegebene Fähigkeiten und geprüfte Entscheidungen in die Domain übernehmen.
6. Einen eigenen Arbeitsraum anlegen. Der Chat eröffnet eine getrennte Session, die dieselbe Runtime mit dem neuen Domain-Profil nutzt.
7. Einen wiederkehrenden Flow bauen. Trigger, Eingaben, Artefakt, Qualitäts-Gate, Verifikation und Übergabe.
8. Mit einer realen Aufgabe abnehmen. Die Factory prüft Ergebnis, Evidenz, Tool-Nutzung und Grenzverhalten, bevor der Raum als betriebsbereit gilt.
9. Öffentliche Aktionen hinter eine Freigabe setzen.
10. Den ganzen Lauf messen. Nicht nur die Qualität der letzten Antwort, sondern Routing, Tool-Nutzung, Evidenz, Kosten, Laufzeit und Fehler.

Der kleinste sinnvolle Domain Agent

• ein klarer fachlicher Arbeitsraum
• ein Operating Contract mit erlaubten und freigabepflichtigen Aktionen
• ein kleiner, kuratierter Entscheidungsspeicher
• mindestens ein wiederholbarer Skill oder Flow
• ein überprüfbares Ergebnis statt einer bloßen Erfolgsmeldung

Mehr braucht der erste produktive Domain Agent nicht.

Was ich als Nächstes verbessere

Das Setup ist produktiv, aber nicht fertig.

Der nächste Reifegrad liegt für mich an drei Stellen:

Erstens brauchen zeitlich gekoppelte Automationen explizite Übergaben. Ein Folge-Flow sollte nicht nur zu einer bestimmten Uhrzeit starten, sondern auf ein erfolgreiches, validiertes Artefakt reagieren.

Zweitens brauchen Skills Regressionstests. Wenn ein gutes Verfahren als Skill gespeichert wird, muss ich später erkennen können, ob neue Modelle, Tools oder Regeln es verschlechtert haben.

Drittens müssen technische Grenzen die Policy-Grenzen stärker ergänzen. Getrennte Arbeitsverzeichnisse, enger zugeschnittene Tools und Capability-basierte Rechte können sensible Domains robuster isolieren.

Das ist kein Gegenargument gegen das aktuelle System.

Es ist der normale Weg von einer nützlichen persönlichen Automation zu einer belastbaren Agentenplattform.

Der eigentliche Shift

Ich habe nicht sechs Bots gebaut.

Ich habe eine agentische Runtime so organisiert, dass sie über sechs getrennte Chat-Sessions in sechs Bereichen unterschiedlich arbeiten kann.

Der Boba-DM ist dabei die Agent Factory und der Architektenraum: Dort entstehen neue Domain-Profile nach einem wiederholbaren Playbook. Die Messenger-App liefert das Interface. Domain-Chats liefern getrennte Sessions und das Routing in die gemeinsame Runtime. Der Influencer Manager, der Investing Agent und der Immobilien Agent zeigen, wie unterschiedlich dieselbe Runtime dadurch arbeiten kann. Operating Contracts liefern die Regeln. Memory liefert Kontinuität. Skills liefern wiederverwendbare Erfahrung. Proaktive Flows liefern Betrieb. Governance liefert die Freiheit, Routinearbeit tatsächlich abzugeben.

Das Ergebnis fühlt sich nicht wie ein allwissender AI-Assistent an.

Es fühlt sich eher wie ein kleines digitales Unternehmen an:

• mit Abteilungen
• mit Zuständigkeiten
• mit Standardverfahren
• mit internen Arbeitsräumen
• mit Freigaben
• mit überprüfbaren Ergebnissen

Und genau darin liegt für mich die Zukunft produktiver AI Agents.

Nicht ein Modell, das alles irgendwie kann.

Sondern ein System, das weiß, wofür es zuständig ist, wie es arbeiten soll, wann es Beweise liefern muss und wann der Mensch entscheidet.