Mein Social-Agent ist 0 Codezeilen alt — und sitzt auf 10.687, die ich vor 8 Monaten geschrieben habe
Build-in-Public · Tag 0 · 3. Mai 2026
Ich baue gerade öffentlich mein Unternehmen mit KI-Agenten. Tag 0 ist diese Woche. Phase eins ist der Social-Media-Agent — der Teil, der entscheidet, was ich auf welchem Kanal poste, der die Texte entwirft, der die Performance trackt und mir Sonntag früh per Telegram drei Daumen-hoch-Knöpfe für die Freigabe hinhält.
Bevor ich erzähle, was ich baue, kurz warum überhaupt: ich arbeite Vollzeit als AI Engineer bei Breuninger, habe eine dreijährige Tochter, baue zwei Marken parallel auf (Futurhinos AI und Futurhinos for Kids), habe null Mitarbeiter und kein Budget, jemanden einzustellen. Mein Mann hält den Familien-Alltag mit — und der soll sich nicht um meine Belege oder meinen Posting-Plan kümmern müssen. Bleibt: Hebel statt Stunden. Agenten sind dieser Hebel.
Was viele beim Stichwort „Marketing-Automation mit KI“ hören: irgendein SaaS-Tool mit „AI“ im Namen, das per Knopfdruck Posts ausspuckt. Was ich tatsächlich baue: drei Dinge nebeneinander, die jedes für sich eine Aufgabe gut lösen.
Der Stack — und warum drei statt eins
1. n8n (self-hosted auf Railway) — die Klempnerei.
Wenn eine Mail reinkommt, ein Buchungs-Webhook feuert, Instagram-Insights gepullt werden müssen, ein Cron-Job einen Trend-Report bauen soll: das ist n8n-Gebiet. Keine Logik, keine Entscheidungen, nur Datenbewegung. Das ist Arbeit, die ich nicht in Python schreiben will, weil OAuth-Flows zu LinkedIn, Meta Graph und Google Search Console pre-built sind. Ich will nicht jeden zweiten Tag eine Stunde Token-Refresh debuggen.
2. Python + Claude Agent SDK — das Denken.
Sobald eine Entscheidung mehrstufig wird — „nimm die Säulen-Rotation aus dem Q2-Plan, schau die letzten 7 Tage Performance an, gewichte aktuelle Suchanfragen aus der Search Console, prüf den Saison-Kalender, bau einen Wochenplan“ — wird das in n8n ein 40-Knoten-Albtraum. In einem Python-Service mit dem Claude Agent SDK bleibt es lesbar, testbar, versionierbar. Und nebenbei: dokumentierbar — was der eigentliche Zweck dieser ganzen Übung ist.
3. Mein bestehendes Booking-Backend.
Das ist der Teil, den niemand erwartet — und genau deshalb der wichtigste. Ich habe vor acht Monaten ein eigenes Buchungs-System für Futurhinos for Kids gebaut: 57 Datenbank-Tabellen, eigenes E-Mail-System, Google-Calendar-Integration, ein erster steuerlicher Agent, ein Mitglieder-Bereich mit Login. 10.687 Zeilen Express-Backend in einer einzigen `server.js` — genau die Art „pragmatisch statt elegant“, die solo gewachsene Systeme aussehen lässt, und genau die Art, die läuft.
Das System hat alle relevanten Kundendaten: Anmeldungen, Anfragen, Mitglieder, Rechnungen, Termine. Es wäre absurd, die Daten woanders nochmal zu sammeln.
Mein Social-Agent setzt also oben drauf, nicht daneben. Single Source of Truth für Kunden, Anmeldungen und Anfragen bleibt die bestehende Datenbank. Der Social-Agent liest und schreibt dort über eine API — und hält nur die Sachen separat, die wirklich nur Social-Agent-Sachen sind: Posts, Performance-Metriken, Trend-Snapshots, klassifizierte Anfragen.
Was die Kampagnensteuerung „intelligent“ macht
Das Wort „intelligent“ wird in der Marketing-Branche so verwendet, dass es nichts mehr bedeutet. Was ich darunter verstehe: der Wochenplan-Generator bekommt jeden Samstagabend sechs Eingaben gleichzeitig und macht daraus einen adaptierten Plan — statt blind einen Redaktionsplan abzuarbeiten.
Die sechs Eingaben:
1. Wo wir im Q2-Plan stehen — welche Content-Säule, welcher narrative Anker dran ist
2. Was letzte Woche performte — Reach, Engagement, Saves pro Post pro Plattform
3. Aktuelle Trends DACH — RSS aus drei Tech-Magazinen + Google Trends für 5 Keywords
4. Was Leute aktiv googeln — Top-Queries aus der Google Search Console der letzten 7 Tage
5. Was Eltern und Kunden aktuell fragen — alle Mail- und DM-Anfragen der Woche, durch Claude klassifiziert
6. Saison-Trigger der nächsten 7 Tage — Schulferien, lokale Events, allgemeine Anlässe
Kein Machine Learning, keine Magie. Nur Kontext, der bisher in meinem Kopf war, jetzt im Prompt. Das reicht, damit Claude statt „mach ein Carousel über Pfingstcamps“ konkret „mach ein Carousel über Pfingstcamps mit Hook auf Suchanfrage X, weil 200 Eltern letzte Woche genau das gegoogelt haben und unsere Seite auf Position 8 lag“ generiert.
Den Output bekomme ich Sonntag früh als Telegram-Karten. Daumen hoch, Stift für Edits, X für Verwerfen. Drei Knöpfe, fünfzehn Minuten auf dem Sofa.
Was ich bewusst weglasse
– Vollautomatisches Posten ohne menschliche Freigabe. Markenstimme verzeiht keine zwei Wochen Drift, und Krisen-Posts dürfen niemals an einen Bot.
– Microservices-Architektur. Drei Agenten in einem Mono-Service mit klar getrennten Modulen, ein Railway-Deploy, ein Log-Stream. Microservices sind ein Architektur-Pattern für 50-Personen-Teams, nicht für Solo-Founder.
– „Trending Topic“-Hijacking. Wenn die Trend-Daten ein Thema melden, das nicht zu meinen Säulen passt, ignoriert der Agent es. Reichweite, die nichts verkauft, ist Vanity.
– Generische Hashtag-Generatoren. Falsche Sprache, falsche Reichweite, falsche Algorithmus-Signale. Hashtags kommen aus einer kuratierten Liste pro Content-Säule, nicht aus einem LLM-Würfel.
– Eigene Datenbank für den Social-Agent. Doppelte Datenhaltung ist die teuerste technische Schuld, die ein Solo-Projekt sich anlachen kann. Bestehende DB als Quelle reicht.
Wie es weitergeht
In den nächsten zwölf Wochen baue ich öffentlich:
– Wochen 1–4: Social-Agent live — Architektur, n8n-Workflows, der Wochenplan-Generator, erste Posting-Loops
– Wochen 5–8: Buchhaltungs-Agent — Erweiterung des bestehenden Steuer-Moduls um Claude. Belege sind keine Aufgabe für mich und keine für meinen Mann.
– Wochen 9–12: Vertriebs-Agent — der schwierigste, weil ich öffentlich erklären muss, warum ich genau **nicht** mache, was die Cold-Outreach-Bots gerade mit dem deutschen B2B-Markt anstellen.
Jede Architektur-Entscheidung kommt hier auf die Webseite und auf LinkedIn. Wöchentliche Token-Kosten in echten Zahlen, ehrliche Stundenersparnis-Schätzungen (keine „70 % schneller“-Behauptungen), und vor allem: was ich verworfen habe, weil es nicht funktioniert hat.
Wenn dich das interessiert
Der Code bleibt privat — mein Buchungs-Backend enthält Geschäftslogik und echte Kundendaten, die nicht in ein öffentliches Repo gehören. Was ich vollständig teile: **Architektur-Entscheidungen, Prompt-Strukturen, Workflow-Diagramme und Lessons** — Schritt für Schritt, hier auf der Seite.
Wenn du etwas Ähnliches baust oder einen Sparringspartner für eine vergleichbare Architektur-Entscheidung suchst: melde dich gerne direkt, ich antworte persönlich. Wenn du oder dein Team eine Inhouse-Variante dieser Architektur braucht, gibt es Workshops und Pilot-Projekte — Kontakt unten.
In zwei Wochen kommt der nächste Artikel: das erste Live-Modul (Email-Triage und Inquiry-Routing), mit Workflow-Diagramm und ehrlichem Token-Kosten-Tracking nach der ersten Woche Betrieb.
—
*Astrid baut Futurhinos AI als Mompreneur-Build-in-Public-Projekt parallel zu ihrem Vollzeitjob als AI Engineer. Wenn du in die wöchentlichen Build-Updates reinschauen willst, folge auf [LinkedIn](#) oder abonniere den [Newsletter](#).*
