Zum Inhalt springenSkip to content
Ahnenhain Systems
Ahnenhain Systems

Ahnenhain Systems · Julius C. Gnädig

AI Engineer · KI-Agenten und Automatisierung, sicher im Betrieb

KI-Agenten und Automatisierung für den produktiven Betrieb.

Ich richte KI-Agenten für Betriebe, Vereine und Teams ein: selbst gehostet, getestet und mit menschlicher Freigabe. Das Fundament sind Plattform und Betrieb: Kubernetes, Automatisierung, Sicherheit.

Seit 2022 täglich mit generativer KI, seit 2023 mit eigenen KI-Workflows.

Gespräch anfragenFallstudien ansehen

So entsteht diese Seite

Echter Ablauf, vereinfacht

  1. PlanEin planendes Modell teilt die Arbeit in Teilaufgaben und schreibt für jede einen eigenen Auftrag.
  2. BauMehrere Coding-Agenten (Claude Code) arbeiten parallel. Jeder liefert seine Teilaufgabe als Pull Request.
  3. PrüfungBei jedem Pull Request baut GitHub Actions die Seite aus den Quellen und prüft Seite und Repository. Unabhängige Review-Agenten prüfen die Änderung zusätzlich.
  4. MessungLighthouse, axe-core und Playwright messen Leistung, Barrierefreiheit, Überlauf, Fremdabrufe und Größe.
  5. FreigabeIch prüfe das Ergebnis und führe es zusammen. Ohne meine Freigabe geht nichts live.
  6. LiveErst danach erscheint die Änderung auf der Seite.

Womit ich baue

Wie diese Seite gebaut ist

So läuft es ab

Vier Schritte, vom ersten Gespräch bis zum laufenden System.

  1. Kennenlernen

    20 Minuten, kostenlos

    Wir besprechen, was bei Ihnen Zeit kostet und ob sich ein Agent dafür eignet.

  2. Standortbestimmung

    Bericht, den Sie behalten

    Der schriftliche Bericht zeigt, wo ein Agent hilft, wo nicht und wer freigibt.

  3. Umsetzung

    Festpreis, getestet

    Ich richte das System ein und teste es vor dem Ausrollen. Ein Mensch gibt frei.

  4. Übergabe

    Läuft bei Ihnen, mit Einweisung

    Das System läuft auf Ihrer Seite, nicht bei mir. Ich weise Sie und Ihr Team ein.

Fallstudien

Architektur, Entscheidungen, Betrieb.

  1. Nr. 01

    Selbst gehostet: Daten und Logik

    Symbiont

    Messenger-Eingang, KI als Interpret, menschliche Bestätigung.

    Stand
    Täglich im Einsatz
  2. Nr. 02

    Automatisierung aus eigenem Bedarf

    Landwirtschaft und Imkerei

    Stockkarte und Flächen aus offenen Geodaten.

    Stand
    Prototyp in eigenem Gebrauch
  3. Nr. 03

    Überprüfbar von außen

    Firmen-IT und diese Website

    E-Mail-Sicherheit, Prüfpipeline. Vieles davon lässt sich mit öffentlichen Werkzeugen nachprüfen.

    Stand
    Live seit September 2026

Alle Projekte

Woran ich gerade arbeite

Was im Einsatz ist und woran ich gerade baue.

Status: Im Einsatz

Agenten bauen, Prüfungen entscheiden, ich gebe frei

Mehrere KI-Agenten bauen parallel, automatische Prüfungen messen jeden Stand, veröffentlicht wird erst nach meiner Freigabe. Auch über Nacht: Agenten arbeiten einen Fehlerkatalog auf eigenen Zweigen ab, veröffentlicht wird erst nach meiner Freigabe am nächsten Tag.

Technik Claude Code · Playwright · Lighthouse · axe-core · Python

Status: Im Einsatz

Fragen an die eigene Dokumentation, mit Quellen

Fragen an die eigene, vorher geschwärzte Projektdokumentation beantwortet ein Messenger-Bot mit einer hybriden Suche aus Volltext und Vektoren. Die Antwort nennt ihre Quellen, die Belege werden im Code geprüft, und Aussagen über den Produktivbetrieb sind als solche gekennzeichnet.

Technik PostgreSQL · pgvector · hybride Suche · Belegprüfung · Telegram-Bot

Fallstudie Symbiont lesen

Status: Im Einsatz

Eigene Entwicklungsplattform mit GitOps und Review-Agenten

Symbiont wird auf einem eigenen Kubernetes-Cluster entwickelt, der nur im privaten Netz erreichbar ist. Nach der Freigabe zieht der Cluster den Stand selbst. Unabhängige Review-Agenten prüfen jede Änderung. Nach main kommt nur, was ich freigegeben habe, für den Produktivbetrieb gilt dasselbe.

Technik Kubernetes (k3s) · Flux · GitOps · Kustomize · SOPS/age · GitHub Actions · Container-Registry

Status: Im Einsatz

Eine Ablage, die KI-Sitzungen überdauert

Ergebnisse aus KI-Sitzungen landen in einer einzigen Ablage mit sichtbarer Versionsnummer, Prüfung auf Vollständigkeit, Aussortieren statt Löschen und einseitiger Sicherung auf einen zweiten Datenträger. Neue Sitzungen arbeiten aus dieser Ablage weiter.

Technik Python · Markdown · Versionsschema · Prüfskripte

Status: Prototyp

Lokale Modelle mit Werkzeugaufrufen

Ein Orchestrator-Agent leitet Anfragen an spezialisierte Unteragenten weiter. Ihre Werkzeuge sind in einer Registry beschrieben und werden per Web-Anfrage aufgerufen, etwa an eine offene Daten-API; die Modelle laufen lokal.

Technik TypeScript · Node.js/Express · Ollama · Open WebUI · Docker

Status: In Vorbereitung

Erstes Paper: Mensch-KI-Symbiose aus langjähriger Praxis

Ein Position Paper über eine langjährige Arbeitspartnerschaft mit KI, aus der Innensicht und gestützt auf Aufzeichnungen des eigenen Systems. Drei Prinzipien machen aus Werkzeugnutzung Symbiose: Validierung, Nachvollziehbarkeit, Selbstverbesserung.

Format Position Paper · Fallstudie (N = 1) · Englisch

Zur Seite Publikationen

Status: Im Einsatz

Fragen an die eigenen Daten mit festen Werkzeugen

Fragen an die eigenen Ernährungsdaten beantwortet ein Sprachmodell, das nur aus festen, lesenden Werkzeugen wählt, etwa Tagessummen oder Durchschnitte. Es schreibt nie selbst SQL, und wessen Daten abgefragt werden, bestimmt der Code, nicht das Modell.

Technik Function Calling · PostgreSQL · Telegram-Bot

Status: Im Aufbau

Dokumenten-Gehirn: Post scannen, lokal verstehen, mit Herkunft beantworten

Papierpost wird mit dem Telefon gescannt und auf einem kleinen eigenen Rechner im Haus verarbeitet, personenbezogene Angaben werden zuvor pseudonymisiert. Ein lokales Sprachmodell antwortet per Messenger immer mit Quellenangabe, getestet bisher mit synthetischen Briefen.

Technik Raspberry Pi · PostgreSQL · pgvector · Graph (relational, Apache AGE optional) · lokales Sprachmodell · n8n

Ausgearbeitete Fallstudien stehen unter Projekte. Alle Projekte

Für wen

Drei typische Einstiege. Bei jedem prüft und gibt ein Mensch frei.

  • Kleine Betriebe und Handwerk

    BeispielTerminanfragen per E-Mail oder Sprachnachricht werden gelesen, sortiert und als Antwortvorschlag vorbereitet.

    Prüft und gibt freiSie, bevor eine Antwort versendet wird.

    Aufbauvorschlag ansehen

  • Vereine und Organisationen

    BeispielAus Ihren Notizen entsteht der Entwurf für die Mitgliederpost, etwa eine Terminänderung der Probe.

    Prüft und gibt freiEine Person aus dem Vorstand liest und gibt jeden Text frei.

    Aufbauvorschlag ansehen

  • Teams und Selbstständige

    BeispielOffene Angebote werden erkannt, das Nachfassen wird als Entwurf vorbereitet.

    Prüft und gibt freiDie Person, die das Angebot gemacht hat, liest den Entwurf und sendet ihn selbst.

    Aufbauvorschlag ansehen

Wo lohnt sich ein Agent?

Fünf Fragen zu einer Aufgabe aus Ihrem Alltag. Die Einschätzung entsteht in Ihrem Browser. Es wird nichts übertragen und nichts gespeichert.

Die fünf Fragen

  1. Wie oft fällt die Aufgabe an? Mehrmals täglich · Täglich oder mehrmals pro Woche · Etwa einmal im Monat · Selten oder einmalig
  2. Wie lange dauert ein Durchgang? Länger als zwei Stunden · 30 Minuten bis zwei Stunden · 5 bis 30 Minuten · Unter 5 Minuten
  3. Wie strukturiert sind die Eingangsdaten? Fest aufgebaut, etwa Formulare oder Tabellen · Überwiegend einheitlich, mit Ausnahmen · Gemischt, etwa E-Mails und PDFs unterschiedlicher Herkunft · Frei oder nur im Kopf vorhanden
  4. Was kostet ein Fehler? Wenig: Er fällt auf und ist schnell korrigiert · Spürbar: Nacharbeit oder Ärger · Hoch: Geld, Vertrag oder Kundenvertrauen · Schwer: Recht, Sicherheit oder nicht rückholbar
  5. Wer kann das Ergebnis prüfen und freigeben? Eine fachkundige Person, schnell · Jemand, aber es kostet Zeit · Nur stichprobenartig · Niemand, das Ergebnis geht direkt raus

Ohne JavaScript gilt: Je häufiger und zeitaufwendiger die Aufgabe, je fester die Eingangsdaten und je besser jemand das Ergebnis prüft, desto eher lohnt sich ein Agent. Ist ein Fehler teuer und prüft niemand, lohnt er sich nicht.

Preise

Sie wissen vor dem Start, was es kostet.

Kennenlernen20 Minuten
kostenlos
KI-Standortbestimmung90 Minuten plus schriftlicher Bericht
450 €
Team-Workshop „KI im Arbeitsalltag“Halber Tag, bis 8 Personen
1.490 €
UmsetzungspaketFestpreis nach der Standortbestimmung
ab 1.950 €
Beratung nach StundenAbrechnung im 30-Minuten-TaktEinführungspreis bis 31. Dezember 2026
115 € pro Stunde
VortragKonferenz, Verein oder Team, vor Ort oder onlinePlus 50 € pro Stunde bei vertraulichen Inhalten des Auftraggebers. Zuzüglich Anfahrt nach Aufwand. Vorbereitung nur, wenn ich das Material nicht weiterverwenden darf. Für gemeinnützige Vereine und Organisationen gegen eine geringe Aufwandsentschädigung möglich.
150 € pro Stunde Vortragszeit

Kleinunternehmer nach § 19 UStG, daher ohne Umsatzsteuer. Die Anfrage zur Beratung nach Stunden oder zu einem Vortrag läuft über das Rückruf-Formular.

Häufige Fragen

Wo läuft das System?

Bei Ihnen, nicht bei mir. Ich richte es auf Ihrer Seite ein und übergebe es mit Einweisung. Die Fallstudien zeigen selbst gehostete Systeme im Detail.

Zu den Fallstudien

Was passiert mit meinen Daten?

Die Vertraulichkeitsklasse der Daten bestimmt, welches Modell sie sehen darf. Personenbezogene, Gesundheits- und Biometriedaten von Kunden verarbeite ich nur mit Datenschutzkonzept und Auftragsverarbeitungsvertrag. Diese Seite setzt keine Cookies und ruft keine fremden Server ab.

Leitplanken im Detail

Was kostet es?

Das Kennenlernen ist kostenlos. Die Standortbestimmung kostet 450 €, der Team-Workshop 1.490 €. Ein Umsetzungspaket beginnt bei 1.950 € und wird nach der Standortbestimmung als Festpreis genannt. Die Beratung nach Stunden kostet 115 € pro Stunde (Einführungspreis bis 31. Dezember 2026) und wird im 30-Minuten-Takt abgerechnet. Ein Vortrag kostet 150 € pro Stunde Vortragszeit, bei vertraulichen Inhalten des Auftraggebers (eigene Firmenbeispiele, Verschwiegenheit) 50 € pro Stunde mehr, zuzüglich Anfahrt nach Aufwand (bei Online-Vorträgen fällt keine Anfahrt an). Vorbereitung berechne ich nur, wenn ich das Vortragsmaterial nicht selbst weiterverwenden darf, dann zum Beratungssatz von 115 € pro Stunde im 30-Minuten-Takt. Für gemeinnützige Vereine und Organisationen ist ein Vortrag gegen eine geringe Aufwandsentschädigung möglich. Sprechen Sie mich an. Anfrage über das Rückruf-Formular. Alle Preise sind Endpreise, Umsatzsteuer wird nach § 19 UStG nicht erhoben.

Zur Preistafel

Was baue ich nicht oder nur eingeschränkt?

Keine Systeme, die Bewerberinnen und Bewerber auswählen oder Personalentscheidungen treffen, und keine Bewertungen der Kreditwürdigkeit. Auswertungen von Leistung oder Verhalten von Mitarbeitenden nur nach vorheriger rechtlicher Prüfung.

Zur Arbeitsweise

Wer ist verantwortlich, wenn der Agent sich irrt?

Der Mensch, der freigibt. Die KI entwirft, ein Mensch prüft und gibt frei, bevor etwas wirkt. Bei Symbiont und dieser Website prüfen zusätzlich unabhängige Review-Agenten jede Änderung. Agenten bekommen nur die Rechte, die der jeweilige Schritt braucht, und jeder Fehler wird zu einer Regel oder einem Test.

Wer was tut

Was brauche ich vorab?

Ein Anliegen genügt. Im Kennenlernen klären wir in 20 Minuten, was Sie beschäftigt und ob ein Agent dafür taugt. Alles Weitere ergibt sich aus der Standortbestimmung.

Gespräch anfragen

Woran sehe ich, dass Sie das können?

Die drei Fallstudien zeigen Architektur und Entscheidungen, Symbiont zusätzlich Vorfälle und die Regeln daraus. Diese Seite ist selbst ein Beleg: Messwerte, Sicherheitsheader und Werkzeuge stehen offen auf der Seite „So ist diese Seite gebaut“.

So ist diese Seite gebaut

In 20 Minuten klären wir, ob ein Agent bei Ihnen Sinn ergibt. Kostenlos.

Gespräch anfragen

Kontakt

Per E-Mail oder Telefon, auf Deutsch oder Englisch.

Freie Plätze: 1 von 2

Offener Knoten: frei. Geschlossener Knoten: belegt.

E-Mail
info@ahnenhain.de
Telefon
+49 160 2495853
LinkedIn
Julius C. Gnädig (öffnet eine externe Seite)

Gespräch anfragen

Ihre Angaben gehen nur per E-Mail an mich und werden auf dem Server nicht gespeichert. Mehr in der Datenschutzerklärung. Alle Zeiten deutsche Zeit.

Projekte

Die drei Fallstudien sind aus eigenem Bedarf entstanden und im eigenen Gebrauch. Die weiteren Projekte zeigen, was ich darüber hinaus konzipiert, getestet und gebaut habe. Der Anspruch ist überall derselbe: Lösungen, die funktionieren und nachvollziehbar sind.

SymbiontLandwirtschaftFirmen-ITWorkload IdentityCouncil of AgentsGitOpsfesten WerkzeugenSuccess ForgeLernanwendungenKI-KennzeichnungServerraum

11 Projekte · 3 Fallstudien · 8 weitere

Jeder Punkt öffnet das Projekt. Linien verbinden Projekte mit gemeinsamer Technik oder gemeinsamem Thema.

Fallstudien

  1. Nr. 01

    Fallstudie · Selbst gehostet: Daten und Logik

    Symbiont

    Ein KI-System für den eigenen Alltag, betrieben wie ein kleines Produktivsystem.

    Symbiont ist mein KI-System für Alltagsdaten. Entstanden aus der Idee, das eigene Leben mit einem System zu führen, das aus den eigenen Daten lernt. Daten und Logik sind selbst gehostet, die Sprachmodelle rufe ich bei externen Anbietern auf. Text, Sprachnachricht oder Foto kommen über einen Messenger, ein Sprachmodell macht daraus einen strukturierten Eintrag. Feste Regeln prüfen jeden Vorschlag, bei Mehrdeutigkeit bestätige ich über eine Schaltfläche. Betrieb wie ein Produktivsystem, entwickelt mit spezialisierten Claude-Agenten. Daneben läuft eine eigene Entwicklungsplattform auf Kubernetes.

    Nr. 01Täglich im Einsatz

    Rolle
    Idee, Architektur, Betrieb, Entwicklung mit Agenten
    Seit
    Idee 2022, Architekturkonzept Ende 2025, im täglichen Betrieb seit 2026
    Kern
    n8n, PostgreSQL mit pgvector, Sprachmodelle, Docker
  2. Nr. 02

    Fallstudie · Automatisierung aus eigenem Bedarf

    Landwirtschaft und Imkerei

    Stockkarte und Flächen aus offenen Geodaten, gebaut als Module, die beim Betrieb laufen.

    Bienenvölker an mehreren Ständen und Flächen mit Wald wollen verwaltet werden, bisher auf Papier. Ich habe eine digitale Stockkarte gebaut und Flächen aus offenen Geodaten als Kartenlayer aufbereitet, beides als Modul für den laufenden Betrieb.

    Nr. 02Prototyp in eigenem Gebrauch

    Rolle
    Bedarf, Konzept, Umsetzung mit KI, eigener Gebrauch
    Seit
    Juli 2026 (Flächen), September 2026 (Stockkarte)
    Kern
    Offline-Webanwendung, WFS, KML
  3. Nr. 03

    Fallstudie · Überprüfbar von außen

    Firmen-IT und diese Website

    Klein, aber so gebaut, wie ich es einem Kunden empfehlen würde.

    Im September 2026 habe ich die IT von Ahnenhain Systems von null aufgebaut: E-Mail mit korrekter Absenderprüfung, eine gegen Fälschung gesperrte Zweitdomain, diese Website ohne Cookies und ohne Fremdabrufe, ein privates Repository mit signierten Commits und Prüfpipeline. Claude hat vorbereitet, ich habe geprüft, committet und freigegeben; vieles davon können Sie mit öffentlichen Werkzeugen selbst nachprüfen.

    Nr. 03Live seit September 2026

    Rolle
    Planung, Umsetzung mit Claude, Freigabe
    Seit
    September 2026
    Kern
    Microsoft 365, DNS, GitHub Actions, statisches HTML

Weitere Projekte

  • 2026getestet

    Workload Identity Federation für KI auf Kubernetes

    KI-Dienste greifen ohne gespeicherte Schlüssel auf Ressourcen zu: Die Identität kommt aus dem Cluster, kurzlebige Tokens ersetzen langlebige Secrets. Auf einem eigenen Demo-Cluster umgesetzt und in der CI automatisiert getestet.

    Kubernetes · OIDC · Workload Identity Federation

  • Prototyp

    Council of Agents

    Mehrere KI-Agenten mit unterschiedlichen Rollen debattieren eine Frage strukturiert, ein letzter Schritt führt die Positionen zu einer Empfehlung zusammen. Rollen und Modi sind per Konfiguration einstellbar. Ein eigener Skill erzeugt Rollen und Persönlichkeiten der Agenten aus einer Beschreibung.

    n8n · xAI Grok · YAML-Konfiguration · Websuche · Docker

    • Agenten
    • n8n
    • Selbst gehostet

  • 2026im Einsatz

    Eigene Entwicklungsplattform mit GitOps und Review-Agenten

    Symbiont wird auf einem eigenen Kubernetes-Cluster entwickelt, der nur im privaten Netz erreichbar ist. Alles wird per GitOps ausgerollt: Jede Änderung ist ein Pull Request, nach der Freigabe zieht der Cluster den Stand selbst. Geheimnisse liegen verschlüsselt im Repository. Unabhängige Review-Agenten prüfen jeden Pull Request. Nach main kommt nur, was ich freigegeben habe, für den Produktivbetrieb gilt dasselbe.

    Kubernetes (k3s) · Flux · Kustomize · SOPS/age · GitHub Actions

    • Kubernetes
    • Agenten
    • Sicherheit

  • 2026im Einsatz

    Fragen an die eigenen Daten mit festen Werkzeugen

    Fragen an die eigenen Ernährungsdaten beantwortet ein Sprachmodell, das nur aus festen, lesenden Werkzeugen wählt, etwa Tagessummen oder Durchschnitte. Es schreibt nie selbst SQL, und wessen Daten abgefragt werden, bestimmt der Code, nicht das Modell.

    Function Calling · PostgreSQL · Telegram-Bot

    • Agenten
    • Daten

  • im eigenen EinsatzPrototyp

    Success Forge

    KI-gestütztes Zielmanagement mit einem Entscheidungskompass über mehrere Lebensbereiche. Leitgedanke: Die KI unterstützt Entscheidungen, nimmt sie aber nicht ab, und schützt vor zu viel Automatisierung.

    n8n · PostgreSQL

    • Agenten
    • n8n
    • Daten

  • 2026abgeschlossen

    Interaktive Lernanwendungen

    Lernanwendungen, mit denen sich andere neue KI-Werkzeuge selbst erarbeiten: ein Lernpfad für einen KI-Arbeitsbereich, einer mit Sprachausgabe für die Fernsteuerung von KI-Sitzungen und ein Trainer, der die Schwierigkeit an den Lernstand anpasst.

    React · Sprachausgabe · adaptive Testlogik (IRT)

    • Befähigung
    • Agenten

  • 2026abgeschlossen

    Onepager KI-Kennzeichnung

    Handreichung für Betriebe: wann und wie mit KI erzeugte Inhalte nach Artikel 50 der KI-Verordnung zu kennzeichnen sind, auf einer Seite.

    Recherche · Handreichung für Betriebe in der EU

    • Befähigung

  • Ausbildung 2023abgeschlossen

    Serverraumüberwachung mit Mikrocontroller

    Projekt aus der Ausbildung: den Zustand eines Serverraums mit Sensoren und Mikrocontroller überwachen, im Team nach Scrum organisiert, dokumentiert und präsentiert.

    Arduino · Sensorik · Scrum

    • IoT

Ähnliches Vorhaben?

Gespräch anfragen

Fallstudie · Selbst gehostet: Daten und Logik

Symbiont

Ein KI-System für den eigenen Alltag, betrieben wie ein kleines Produktivsystem.

Nr. 01Täglich im Einsatz

Rolle
Idee, Architektur, Betrieb, Entwicklung mit Agenten
Seit
Idee 2022, Architekturkonzept Ende 2025, im täglichen Betrieb seit 2026
Kern
n8n, PostgreSQL mit pgvector, Sprachmodelle, Docker

Kurzfassung

Symbiont ist mein KI-System für Alltagsdaten. Entstanden aus der Idee, das eigene Leben mit einem System zu führen, das aus den eigenen Daten lernt. Daten und Logik sind selbst gehostet, die Sprachmodelle rufe ich bei externen Anbietern auf. Text, Sprachnachricht oder Foto kommen über einen Messenger, ein Sprachmodell macht daraus einen strukturierten Eintrag. Feste Regeln prüfen jeden Vorschlag, bei Mehrdeutigkeit bestätige ich über eine Schaltfläche. Betrieb wie ein Produktivsystem, entwickelt mit spezialisierten Claude-Agenten. Daneben läuft eine eigene Entwicklungsplattform auf Kubernetes.

Ausgangslage

Ich wollte Ernährung, Training und weitere Alltagsdaten an einem Ort erfassen, ohne sie einer fremden Plattform zu überlassen. Statt Formularen und einem Konto beim Anbieter: eine Nachricht schreiben oder ein Foto schicken, das System erledigt den Rest. Daten und Logik laufen auf meinem Server. Für Sprache, Bild und Textverständnis nutze ich externe Modelle, Nachrichten kommen über einen Messenger.

Ziel und Randbedingungen

  1. Datenhoheit: Daten und Logik auf einem eigenen Server, keine Plattformbindung; externe Modelle nur für Sprache, Bild und Textverständnis.
  2. Eingabe so leicht wie eine Nachricht, Bedienung über Schaltflächen statt Formular.
  3. Die KI darf interpretieren, aber nicht still entscheiden: Vorschläge müssen prüfbar und korrigierbar sein.
  4. Ein Nutzer, täglicher Gebrauch: Verlässlichkeit vor Funktionsumfang.
  5. Modellaufrufe kosten je Anfrage Geld; das gehört in jede Entscheidung.
  6. Betrieb neben dem Beruf: Fehler müssen sich melden, nicht gesucht werden.

Architektur

Eine Nachricht nimmt immer denselben Weg: Eingang, Interpretation durch ein Modell, Prüfung durch feste Regeln, Bestätigung durch den Menschen, Speicherung. Betrieb und Entwicklung sind eigene Schichten mit eigenem Alarmkanal. Daneben gibt es eine Entwicklungsplattform.

Wählen Sie eine Komponente. Die Erklärung erscheint daneben, ihre Datenflüsse werden hervorgehoben.

Architektur als Liste lesen

Keine Komponente gewählt.

Architektur als Liste lesen

Architektur von Symbiont als Text. Messenger-Bots senden Nachrichten und Fotos per HTTPS an einen Reverse Proxy, der von außen nur die nötigen Endpunkte erreichbar macht. Ein n8n-Router prüft Absender und Rate und ordnet zu: Sprache wird zu Text, Fotos zur Bildanalyse, Freitext an ein Sprachmodell für strukturierte Vorschläge. Deterministische Wächter prüfen Datum, Jahr und Plausibilität; bekannte Eingaben gleicht das System mit eigenen Einträgen und einer offenen Produktdatenbank ab. Mehrdeutiges bestätigt, korrigiert oder verwirft der Mensch über eine Schaltfläche, erst dann speichert PostgreSQL mit pgvector. Nächtliche Workflows gleichen Summen ab, ein zweites Modell schreibt parallel Rückblicke. In der Entwicklung setzen Claude-Agenten mit festen Rollen auf Feature-Branches um; ich gebe den Plan frei, prüfe und führe zusammen, bevor eine Pipeline vor dem Ausrollen prüft. Sicherung und Überwachung laufen wie unter Betrieb beschrieben.

  1. Eingang

    1. Messenger-Bots in Betrieb

      Eingang für Text, Sprachnachricht, Foto und Schaltflächen.

      Ausgehend:

    2. Reverse Proxy (Caddy) in Betrieb

      Beendet TLS, setzt Sicherheitsheader, lässt von außen nur die nötigen Endpunkte durch.

      Ausgehend:

  2. Orchestrierung

    1. Befehle und Schaltflächen in Betrieb

      Status, Rückgängig, Berichte, Korrekturen.

      Ausgehend:

    2. Router-Workflow (n8n) in Betrieb

      Prüft Absender und Rate, ordnet die Eingabe einem Weg zu.

      Ausgehend:

  3. KI und Regeln

    1. Spracherkennung in Betrieb

      Macht aus der Sprachnachricht Text.

      Ausgehend:

    2. Sprachmodell als Interpret in Betrieb

      Zerlegt freie Sprache in strukturierte Einträge; schlägt vor, entscheidet nicht.

      Ausgehend:

    3. Bildanalyse in Betrieb

      Erkennt Produkte und Mengen auf Fotos, liefert einen Vorschlag.

      Ausgehend:

    4. Rückblicke (zweites Modell) in Betrieb

      Schreibt Tages- und Wochenrückblicke, parallel zur Antwort.

      Ausgehend:

    5. Deterministische Wächter in Betrieb

      Feste Regeln prüfen jeden Vorschlag auf Datum, Jahr und Plausibilität; fehlende Werte werden markiert.

      Ausgehend:

    6. Abgleich mit Bekanntem in Betrieb

      Sucht in eigenen Einträgen, dann in einer offenen Produktdatenbank.

      Ausgehend:

  4. Mensch

    1. Bestätigung durch den Menschen

      Mehrdeutiges erscheint als Vorschlag mit Bestätigen, Korrigieren oder Verwerfen.

      Ausgehend:

  5. Daten

    1. PostgreSQL mit pgvector in Betrieb

      Hält Einträge, Summen und Vektoren für die Ähnlichkeitssuche, ohne offenen Port.

      Ausgehend:

    2. Zeitgesteuerte Workflows in Betrieb

      Nächtliche Aggregation, Abgleich der Summen, Erinnerungen.

      Ausgehend:

  6. Betrieb

    1. Verschlüsselte Sicherung in Betrieb

      Täglich verschlüsselt gesichert, Kopie außer Haus, Wiederherstellung getestet.

    2. Überwachung in Betrieb

      Container-Gesundheit, Erreichbarkeit, Host-Messwerte.

      Ausgehend:

    3. System-Bot in Betrieb

      Ein Kanal für alles Betriebliche: Ausrollen, Fehler, Überwachung.

  7. Entwicklung

    1. Ich (Entwicklung)

      Formuliere den Auftrag, gebe den Plan frei, prüfe und führe zusammen.

      Ausgehend:

    2. Claude-Agenten mit Rollen im Einsatz

      Spezialisierte Agenten setzen um, suchen Fehler, prüfen Sicherheit und Tests.

      Ausgehend:

    3. Repository mit Prüfpipeline im Einsatz

      Workflows als JSON, versioniert. Vor dem Ausrollen: Analyse, Lint, Tests, Geheimnisscan.

      Ausgehend:

    4. Ausrollen im Einsatz

      Über SSH-Tunnel mit eigenem Nutzer ohne Root; danach Webhook-Prüfung.

      Ausgehend:

Zurück zum Diagramm

Entscheidungen

Im Stil von Architecture Decision Records: Kontext, Entscheidung, Abwägung, Folge.

Entscheidung 01Daten und Logik selbst hosten statt Plattform
Kontext
Persönliche Alltagsdaten sind sensibel; fertige Dienste speichern sie beim Anbieter.
Entscheidung
Eigener Linux-Server mit Docker Compose, Images auf feste Versionen gepinnt.
Abwägung
Sicherheit und Updates liegen bei mir statt bei einer Plattform.
Folge
Härtung als eigene Phase: Firewall, Zwei-Faktor, verschlüsselte Sicherung mit Wiederherstellungstest.
Entscheidung 02n8n als Orchestrierung
Kontext
Viele Eingangswege, viele kleine Abläufe, schnelle Änderungen im Alltag.
Entscheidung
Abläufe als n8n-Workflows, als JSON versioniert und per Pipeline ausgerollt.
Abwägung
Logik in Workflow-Knoten ist schwer testbar.
Folge
Eigene Lint-Regeln; testbare Logik wandert in Module mit Unit-Tests.
Entscheidung 03KI interpretiert, Regeln begrenzen, der Mensch bestätigt
Kontext
Sprachmodelle liefern plausible, aber falsche Werte: ein Datum in der Zukunft, das falsche Jahr.
Entscheidung
Modellausgabe ist immer ein strukturierter Vorschlag, den deterministische Wächter prüfen.
Abwägung
Ein Tipp mehr im Alltag; bekannte Eingaben gehen direkt durch und lassen sich rückgängig machen.
Folge
Modellfehler landen nicht still in den Daten; fehlende Werte bleiben sichtbar.
Entscheidung 04PostgreSQL mit pgvector statt eigener Vektordatenbank
Kontext
Für den Abgleich mit eigenen Einträgen braucht es Ähnlichkeitssuche, sonst relationale Daten.
Entscheidung
Eine Datenbank für beides: Tabellen, JSONB und Vektorindex in PostgreSQL.
Abwägung
Weniger Spezialfunktionen als eine eigene Vektordatenbank.
Folge
Eine Sicherung, ein Schema, Nutzereingaben nur über parametrisierte Abfragen.
Entscheidung 05Entwicklung mit Agenten und festen Prüfstufen
Kontext
Ein einzelner Agent übersieht dieselben Dinge wie ein einzelner Mensch.
Entscheidung
Spezialisierte Agenten mit Rollen, ein Plan vor jedem Schritt, eine Prüfstufe nach Risiko.
Abwägung
Mehr Modellaufrufe und mehr zu lesen.
Folge
Fehler werden vor dem Ausrollen gefunden, jede Entscheidung bleibt nachlesbar.

Mensch in der Schleife

Wo genau ein Mensch freigibt:

  • Mehrteilige oder mehrdeutige Eingaben und Fotos: ein Vorschlag mit Bestätigen, Korrigieren oder Verwerfen, gespeichert erst nach der Bestätigung.
  • Bekannte, eindeutige Eingaben gehen direkt durch, jede lässt sich über eine Schaltfläche rückgängig machen.
  • Rückblicke und Modellhinweise sind Vorschläge; Entscheidungen über Ernährung und Training treffe ich.
  • Entwicklung: Kein Agent setzt um, bevor ich den Plan gelesen und freigegeben habe. Nächtliche Agentenläufe arbeiten auf Feature-Branches, zusammengeführt und ausgerollt wird nach meiner Prüfung.
  • Datenkorrekturen in der Produktion nur mit vorheriger Sicherung und einem Probelauf, der zurückgerollt wird.
  • Nach jedem Ausrollen ein echter Funktionstest: eine echte Nachricht, eine echte Antwort.

Betrieb und Qualität

Entwicklungsplattform

Die Entwicklungsplattform läuft. Der Produktivbetrieb läuft wie unter Betrieb und Qualität beschrieben.

  • Ein eigener Server als Entwicklungs-Cluster auf Kubernetes, nur im privaten Netz erreichbar, nicht öffentlich.
  • GitOps mit Flux: Jede Änderung ist ein Pull Request; nach der Freigabe zieht der Cluster den Stand selbst.
  • Geheimnisse liegen verschlüsselt im Repository (SOPS mit age).
  • Images werden bei jedem Commit gebaut und in einer privaten Registry abgelegt.
  • Aufgaben stehen als Issues. Je Aufgabe baut eine sichtbare Coding-Agent-Session einen Pull Request.
  • Danach prüfen unabhängige Review-Agenten jeden Pull Request: Tests, Manifest-Prüfung, Suche nach Geheimnissen und Hostnamen, Sicherheit. Nach main und damit in den Cluster kommt nur, was ich freigegeben habe. Für den Produktivbetrieb gilt dasselbe.
  • Das gleiche Muster baut auch diese Website.

Wählen Sie eine Komponente. Die Erklärung erscheint daneben, ihre Datenflüsse werden hervorgehoben.

Architektur als Liste lesen

Keine Komponente gewählt.

Architektur als Liste lesen

Auf der Entwicklungsplattform, einem eigenen Kubernetes-Cluster nur im privaten Netz, rollt GitOps mit Flux freigegebene Pull Requests aus; Geheimnisse liegen verschlüsselt im Repository, Images werden je Commit gebaut und in einer privaten Registry abgelegt. Coding-Agenten bauen Pull Requests, unabhängige Review-Agenten prüfen sie, nach main und damit in den Cluster kommt nur, was ich freigegeben habe. Ein Betriebs-Bot und eine Überwachungsseite lesen den Cluster nur.

  1. Entwicklungsplattform

    1. Überwachungsseite Entwicklungsbetrieb

      Lesende Überwachung des Clusters, nur im privaten Netz.

      Ausgehend:

    2. Coding- und Review-Agenten Entwicklungsbetrieb

      Je Aufgabe baut eine sichtbare Session einen Pull Request, unabhängige Review-Agenten prüfen ihn. Nach main kommt nur, was ich freigegeben habe.

      Ausgehend:

    3. Verschlüsselte Geheimnisse (SOPS, age) Entwicklungsbetrieb

      Geheimnisse liegen verschlüsselt im Repository.

      Ausgehend:

    4. GitOps (Flux) Entwicklungsbetrieb

      Jede Änderung ist ein Pull Request; nach der Freigabe zieht der Cluster den Stand selbst.

      Ausgehend:

    5. Bau je Commit, private Registry Entwicklungsbetrieb

      Images werden bei jedem Commit gebaut und in einer privaten Registry abgelegt.

      Ausgehend:

    6. Betriebs-Bot Entwicklungsbetrieb

      Meldet Störungen und beantwortet Fragen zum Stand, nur lesend; keine Schreibrechte im Cluster.

      Ausgehend:

    7. Entwicklungs-Cluster (Kubernetes) Entwicklungsbetrieb

      Ein eigener Server, nur im privaten Netz erreichbar, nicht öffentlich.

Zurück zum Diagramm

Weitere Fähigkeiten

Was die Plattform und der Betrieb zusätzlich leisten und wie es abgesichert ist:

  • Fragen an die eigene Dokumentation im Messenger. Eine hybride Suche (Vektor plus Volltext) läuft über die vorher geschwärzte Projektdokumentation. Die Antwort nennt ihre Quellen, Belege werden im Code geprüft, Aussagen über den Produktivbetrieb sind als solche gekennzeichnet.
  • Fragen an die eigenen Ernährungsdaten. Das Sprachmodell wählt nur aus festen, lesenden Werkzeugen, etwa Tagessummen und Durchschnitten. Es schreibt nie selbst SQL, und wessen Daten abgefragt werden, bestimmt der Code, nicht das Modell.
  • Ein Betriebs-Bot für den Cluster meldet Störungen von selbst und beantwortet Fragen zum Stand über lesende Werkzeuge (Cluster, Code-Repositories, Dokumentation). Er hat keine Schreibrechte im Cluster.
  • Eine lesende Überwachungsseite für den Cluster, nur im privaten Netz erreichbar.
  • Das Trainingsmodul läuft als eigener Dienst (TypeScript, mit umfangreichen automatischen Tests gegen eine echte Datenbank) und ersetzt auf der Entwicklungsplattform die bisherige Workflow-Lösung.

Vorfälle und die daraus abgeleiteten Regeln

Symbiont läuft täglich, also gibt es echte Fehler und Ausfälle. Jeder wird als Vorfall dokumentiert: was passiert ist, die Ursache, die Regel, die ihn verhindert. Eine Auswahl, auch aus der Entwicklung.

  1. Eintrag 01Grün heißt nicht gesund
    Was passierte
    Nach einem Ausrollen schwiegen die Bots, obwohl Pipeline und Container grün waren.
    Ursache
    Ein Protokollschritt überschrieb Daten des nächsten Schritts. Die Infrastruktur war in Ordnung, die Anwendung nicht.
    Was ich daraus gebaut habe
    Ein Pflicht-Funktionstest nach jedem Ausrollen, plus eine Regel für ausdrückliche Bezüge zwischen Workflow-Schritten.
  2. Eintrag 02Die Nacht, die Summen löschte
    Was passierte
    Die nächtliche Aggregation überschrieb korrekte Tagessummen mit Null; am Morgen zeigte der Status nichts mehr an.
    Ursache
    Mehrere Komponenten lasen dieselben Werte, eine an falscher Stelle im JSON; der nächtliche Abgleich erkannte die Abweichung, seine Meldung wurde aber nicht zugestellt.
    Was ich daraus gebaut habe
    Ein einheitlicher Lesepfad, eine reparierte Alarmkette, eine Aggregation, die zurückliegende Tage neu berechnet und sich selbst heilt.
  3. Eintrag 03Sommerzeit an vielen Stellen
    Was passierte
    Einträge lagen im Sommer eine Stunde daneben; die erste Korrektur traf nur die gemeldete Stelle.
    Ursache
    Ein fest eingetragener Winterzeit-Versatz, kopiert in JavaScript und SQL mehrerer Workflows.
    Was ich daraus gebaut habe
    Die Regel: Muster Ende zu Ende suchen, alle Fundstellen beheben. Ein zentraler Zeitbaustein, dazu Wächter gegen falsche Modell-Zeitangaben.
  4. Eintrag 04Wenn der Zwischenspeicher Fehler lernt
    Was passierte
    Falsche Modellschätzungen landeten im Zwischenspeicher und wurden erneut ausgeliefert.
    Ursache
    Modellausgaben wurden ungeprüft wiederverwendet.
    Was ich daraus gebaut habe
    Ein Prüfer außerhalb des Antwortpfads gleicht gespeicherte Werte mit einem zweiten Modellaufruf ab.
  5. Eintrag 05Der Datenverlust, der keiner war
    Was passierte
    Lücken in den Datensatznummern sahen nach stillem Datenverlust aus; die erste Analyse bestätigte den Verdacht.
    Ursache
    Eine genauere Untersuchung widerlegte das: Die Lücken kamen von Löschungen durch Abbrechen und Rückgängig.
    Was ich daraus gebaut habe
    Ein Löschprotokoll per Datenbank-Trigger; widerlegte Befunde bleiben markiert in der Doku, statt zu verschwinden.
  6. Eintrag 06Automatisierung reparieren, nicht umgehen
    Was passierte
    Das automatische Ausrollen fiel still aus. Der Agent schlug vor, von Hand auszurollen. Ich habe abgelehnt.
    Ursache
    Ein zu flacher Checkout konnte Änderungen nicht vergleichen, der Fehler wurde verschluckt.
    Was ich daraus gebaut habe
    Vollständiger Checkout, ein manueller Auslöser für vollständiges Ausrollen. Die Regel: fehlerhafte Automatisierung wird repariert, nicht umgangen.
  7. Eintrag 07Der Fehlerkatalog über Nacht
    Was passierte
    Ein Katalog offener Fehler lag länger, als er sollte. Über Nacht arbeiteten Agenten ihn ab, jeder Fehler auf einem eigenen Zweig mit eigener Prüfung.
    Ursache
    Nicht die Fehler waren das Problem, sondern dass Behebung und Freigabe am selben Tag am selben Menschen hingen.
    Was ich daraus gebaut habe
    Agenten dürfen nachts beheben und prüfen. Veröffentlicht wird erst, wenn ich am nächsten Tag freigegeben habe.
  8. Eintrag 08Ein Dollarzeichen zu wenig
    Was passierte
    Ein Prüfjob nach einer Datenbank-Migration scheiterte im Cluster, obwohl er ohne Kubernetes lief. Derselbe Fehler steckte in einem zweiten Job und wurde dort vor dem Ausrollen behoben.
    Ursache
    Kubernetes ersetzt in Container-Befehlen $$ durch $. Die Befehle kamen dadurch anders an, als sie geschrieben waren.
    Was ich daraus gebaut habe
    $$ wird maskiert oder durch benannte Begrenzer ersetzt. Die Regel: Was die Plattform an Befehlen umschreibt, gehört in die Tests.
  9. Eintrag 09Dateinamen als Links
    Was passierte
    Telegram verlinkte in Antworten Dateinamen mit der Endung .md auf fremde Internetseiten.
    Ursache
    Telegram hielt die Dateinamen für Internetadressen, denn .md ist eine Länderdomain.
    Was ich daraus gebaut habe
    Dateinamen als Code formatiert, Linkvorschau aus. Die Regel: Ausgaben von Sprachmodellen sind Darstellungsdaten und werden vor dem Senden geformt.

Regeln, die daraus wurden

  1. Vor jedem Schritt ein Plan, geprüft gegen den Stand im Repository.
  2. Prüfstufe nach Risiko; Sicherheitsänderungen nur mit Test und Review.
  3. Eine Sicherung ohne Wiederherstellungstest ist keine Sicherung.
  4. Vor jedem neuen Geheimnis prüfen, ob der Name schon vergeben ist.
  5. Geringste Rechte als Standard: nie als Root, immer über einen Deploy-Nutzer.
  6. Nichts direkt auf dem Server anlegen, erst ins Repository, dann ausrollen.
  7. Befunde aus Reviews einzeln einordnen, aufschieben nur mit Grund.
  8. Was die Plattform an Befehlen umschreibt, gehört in die Tests.
  9. Ausgaben von Sprachmodellen sind Darstellungsdaten und werden vor dem Senden geformt.

Technik

Stand

Täglich im Einsatz.

Auf dieser Seite stehen bewusst keine Messwerte und keine persönlichen Daten aus dem System.

Fallstudie · Automatisierung aus eigenem Bedarf

Landwirtschaft und Imkerei

Stockkarte und Flächen aus offenen Geodaten, gebaut als Module, die beim Betrieb laufen.

Nr. 02Prototyp in eigenem Gebrauch

Rolle
Bedarf, Konzept, Umsetzung mit KI, eigener Gebrauch
Seit
Juli 2026 (Flächen), September 2026 (Stockkarte)
Kern
Offline-Webanwendung, WFS, KML

Kurzfassung

Bienenvölker an mehreren Ständen und Flächen mit Wald wollen verwaltet werden, bisher auf Papier. Ich habe eine digitale Stockkarte gebaut und Flächen aus offenen Geodaten als Kartenlayer aufbereitet, beides als Modul für den laufenden Betrieb.

Ausgangslage

In meiner Familie werden Bienen gehalten und Flächen bewirtschaftet. Wer wann wie viel gefüttert hat, wie hoch der Milbenfall war und wo genau eine Fläche endet, stand auf Papier oder im Kopf, oft ohne verlässliches Netz am Stand.

Ziel und Randbedingungen

  1. Erfassen am Stand mit wenigen Eingaben, auch ohne Netz.
  2. Die Daten gehören dem Betrieb und bleiben in offenen Formaten lesbar.
  3. Keine falsche Sicherheit: Was nicht gemessen ist, zählt nicht als erledigt.
  4. Die Module laufen beim Betrieb, nicht bei mir: kurz eingerichtet, danach ohne laufenden Service.

Architektur

Zwei Module: die Stockkarte für die Arbeit am Stand und die Flächen aus offenen Geodaten.

Wählen Sie eine Komponente. Die Erklärung erscheint daneben, ihre Datenflüsse werden hervorgehoben.

Architektur als Liste lesen

Keine Komponente gewählt.

Architektur als Liste lesen

Architektur als Text. Am Stand erfasst die Imkerin oder der Imker je Volk einen Eintrag in der Stockkarte auf dem Handy, einer Webanwendung in einer Datei, die sofort im Gerät speichert und so ohne Netz funktioniert. Die Daten bleiben auf dem Gerät. Auswertungsregeln rechnen Futter in Zuckerwert gegen ein Soll je Volk, berechnen den Milbenfall je Tag und zählen Tage seit dem Bodenschieber; das Ergebnis geht als Übersicht zurück. Ein Export liefert CSV und JSON als Sicherung. Getrennt davon werden amtliche Flurstücksdaten über WFS abgefragt, in KML umgewandelt und als Kartenlayer angezeigt.

  1. Mensch

    1. Imkerin oder Imker am Stand

      Erfasst, was am Volk passiert, entscheidet über Füttern, Behandeln, Ernten.

      Ausgehend:

  2. Erfassung

    1. Stockkarte auf dem Handy Prototyp

      Webanwendung in einer Datei: Stände, Völker, Einträge wie Fütterung, Wiegen, Varroakontrolle, Behandlung, Ernte.

      Ausgehend:

    2. Speicher im Gerät im Einsatz

      Hält Daten im Browser, damit die Karte ohne Netz funktioniert.

      Ausgehend:

  3. Auswertung

    1. Auswertungsregeln im Einsatz

      Rechnet Futter in Zuckerwert, berechnet Milbenfall je Tag, leitet die Königinnenfarbe ab.

      Ausgehend:

  4. Daten

    1. Export CSV und JSON im Einsatz

      CSV für die Ablage, JSON als Sicherung, lesbar ohne die Anwendung.

  5. Geodaten

    1. Offene Geodaten (ALKIS über WFS) im Einsatz

      Amtliche Flurstücksdaten über eine standardisierte Schnittstelle.

      Ausgehend:

    2. Abfrage und Umwandlung im Einsatz

      Fragt die eigenen Flächen ab und wandelt sie in KML um.

      Ausgehend:

    3. Kartenlayer im Einsatz

      Zeigt die Flächen auf dem Handy in einer Kartenanwendung.

      Ausgehend:

Zurück zum Diagramm

Entscheidungen

Kontext, Entscheidung, Abwägung, Folge.

Entscheidung 01Offline zuerst, eine einzige Datei
Kontext
Am Stand gibt es oft kein Netz; es sollte nichts installiert werden müssen.
Entscheidung
Webanwendung in einer HTML-Datei ohne Framework und ohne Abhängigkeiten. Speichern im Gerät.
Abwägung
Die Daten liegen nur auf dem jeweiligen Gerät, bis sie exportiert werden.
Folge
Die Karte funktioniert ohne Netz und ohne Server.
Entscheidung 02Offene Formate statt Datensilo
Kontext
Aufzeichnungen müssen auch in Jahren noch lesbar sein, unabhängig von meiner Anwendung.
Entscheidung
Export als CSV für die Ablage und als JSON für die vollständige Sicherung.
Abwägung
Die Sicherung läuft über den Export, nicht im Hintergrund.
Folge
Die Daten lassen sich ohne Verlust in andere Systeme übernehmen.
Entscheidung 03Regel statt Schätzung
Kontext
Ein Volk gilt schnell als eingefüttert, obwohl niemand gewogen hat.
Entscheidung
Futter wird über dokumentierte Faktoren in Zuckerwert umgerechnet und gegen ein Soll gestellt.
Abwägung
Strenger, und ein Arbeitsschritt mehr.
Folge
Die Übersicht zeigt offen, was fehlt; entscheiden muss weiterhin der Mensch.
Entscheidung 04Flächen aus amtlichen offenen Daten
Kontext
Flächengrenzen von Hand nachzuzeichnen ist ungenau und veraltet schnell.
Entscheidung
Flurstücke über die offene WFS-Schnittstelle abfragen, als KML für gängige Kartenanwendungen.
Abwägung
Die Flächen sind so aktuell wie der amtliche Datenbestand.
Folge
Grenzen stimmen mit dem amtlichen Stand überein.
Entscheidung 05Beim Betrieb laufen, nicht bei mir
Kontext
Ein kleiner Betrieb braucht keine Abhängigkeit von einem Dienstleister.
Entscheidung
Module werden beim Betrieb installiert, kurz eingerichtet, danach ohne laufenden Service.
Abwägung
Updates und Sicherung liegen beim Betrieb, deshalb muss alles dokumentiert sein.
Folge
Kein Konto bei mir, keine laufenden Kosten durch mich.

Mensch in der Schleife

  • Die Stockkarte bewertet den Milbenfall und zeigt einen Hinweis; ob und wie behandelt wird, entscheidet die Imkerin oder der Imker.
  • Die Anwendung rät nicht: Fehlt eine Messung, zeigt sie die Lücke statt einer Annahme.
  • Gebaut mit Claude; neue Funktionen probiere ich am echten Stand aus, bevor sie in den Gebrauch gehen.

Betrieb und Qualität

  • Jeder Eintrag wird sofort im Gerät gespeichert und bleibt auch ohne Netz erhalten.
  • Umrechnungsfaktoren für Futter stehen offen im Code, mit Quelle für den Herstellerwert.
  • Sicherung als JSON nach jedem Tag mit Einträgen.

Übertragbarkeit

Der gleiche Ansatz lässt sich für andere Betriebe und Imkervereine einrichten: Die Module werden vor Ort installiert, kurz eingerichtet und mit Anleitung übergeben, danach laufen sie ohne laufenden Service.

Die Stockkarte lässt sich um Sensorik am Stand erweitern (Gewicht, Temperatur, Feuchte). Dafür gibt es Versuche, noch keinen fertigen Prototyp.

Technik

Stand

Flächen als Kartenlayer im Einsatz, die Stockkarte als Prototyp in eigenem Gebrauch.

Keine Standorte, Völkerdaten oder Flurstücke auf dieser Seite.

Fallstudie · Überprüfbar von außen

Firmen-IT und diese Website

Klein, aber so gebaut, wie ich es einem Kunden empfehlen würde.

Nr. 03Live seit September 2026

Rolle
Planung, Umsetzung mit Claude, Freigabe
Seit
September 2026
Kern
Microsoft 365, DNS, GitHub Actions, statisches HTML

Kurzfassung

Im September 2026 habe ich die IT von Ahnenhain Systems von null aufgebaut: E-Mail mit korrekter Absenderprüfung, eine gegen Fälschung gesperrte Zweitdomain, diese Website ohne Cookies und ohne Fremdabrufe, ein privates Repository mit signierten Commits und Prüfpipeline. Claude hat vorbereitet, ich habe geprüft, committet und freigegeben; vieles davon können Sie mit öffentlichen Werkzeugen selbst nachprüfen.

Ausgangslage

Ein neues Einzelunternehmen braucht E-Mail, Domains, eine Website und einen Ort für Code, mit wenig Pflege. Gleichzeitig sollte es ein Beleg sein: Wer mir Sicherheit zutraut, soll sie an meiner eigenen IT sehen können.

Ziel und Randbedingungen

  1. E-Mails im Namen der Firma müssen sich prüfen lassen, und über die Zweitdomain darf niemand E-Mails fälschen können.
  2. Die Website lädt nichts von fremden Servern: keine Schriften von außen, keine Skripte, kein Tracking.
  3. Nichts geht ohne meine Freigabe online.
  4. Geschäftliche und private Identität bleiben technisch getrennt.
  5. Die E-Mail darf bei keinem Eingriff ausfallen; nach jeder DNS-Änderung wird sie sofort geprüft.

Architektur

Vom signierten Commit bis zur Seite im Browser, dazu Domains und E-Mail.

Wählen Sie eine Komponente. Die Erklärung erscheint daneben, ihre Datenflüsse werden hervorgehoben.

Architektur als Liste lesen

Keine Komponente gewählt.

Architektur als Liste lesen

Architektur als Text. Claude bereitet Dateien, Prüfskripte und Anleitungen vor. Freigabe und Ausrollen entscheide ich; Schritte an DNS oder Webspace führt Claude nur in einer Sitzung aus, die ich begleite. Ich prüfe, committe auf einem Arbeitsrechner mit getrennter geschäftlicher Identität und signiere jeden Commit per SSH-Schlüssel. Das private Repository liegt in einer eigenen Organisation. Jeder Pull Request durchläuft eine Prüfpipeline: HTML-Validierung, interne Links, keine Fremdabrufe, Impressum, Geheimnisscan, Größenbudget. Ausgerollt wird erst nach meiner Freigabe, nie automatisch. Das Hosting erzwingt HTTPS und strenge Sicherheitsheader, Besucher laden nur Dateien dieser Domain. Die Hauptdomain führt zur Seite und zur E-Mail bei Microsoft 365 mit SPF, DKIM und DMARC. Die Zweitdomain sendet nie E-Mail, ist per SPF, DMARC und Null-MX gesperrt und leitet auf die englische Fassung.

  1. Menschen und KI

    1. Claude

      Bereitet Dateien, Prüfskripte, Workflows, DNS-Sollwerte und Anleitungen vor. Freigabe und Ausrollen entscheide ich; Schritte an DNS oder Webspace führt Claude nur in einer Sitzung aus, die ich begleite.

      Ausgehend:

      • Ich: Vorschlag zur Prüfung

    2. Ich

      Gebe Inhalte frei, committe signiert, führe zusammen, starte das Ausrollen.

      Ausgehend:

  2. Entwicklung

    1. Arbeitsrechner mit getrennten Identitäten im Einsatz

      Eigenes Firmenkonto, getrennt vom privaten; Commits per SSH-Schlüssel signiert.

      Ausgehend:

    2. Privates Repository im Einsatz

      In einer eigenen Organisation, mit Zwei-Faktor und Passkey am Konto.

      Ausgehend:

  3. Pipeline

    1. Prüfpipeline im Einsatz

      HTML-Validierung, interne Links, keine Fremdabrufe, Geheimnisscan, Größenbudget.

      Ausgehend:

    2. Ausrollen nach Freigabe im Einsatz

      Nichts geht automatisch online: Ausgerollt wird erst nach meiner Freigabe.

      Ausgehend:

  4. Web

    1. Webhosting mit Sicherheitsheadern in Betrieb

      Erzwingt HTTPS, setzt Header auch bei Umleitungen und Fehlerseiten.

      Ausgehend:

    2. Besucherin oder Besucher

      Lädt nur Dateien von dieser Domain. Keine Cookies, kein Tracking.

  5. Domains und E-Mail

    1. Gesperrte Zweitdomain in Betrieb

      Sendet nie E-Mail: SPF ohne erlaubte Absender, DMARC auf Ablehnen, Null-MX.

      Ausgehend:

    2. DNS der Hauptdomain in Betrieb

      Web-Einträge für die Seite, E-Mail-Einträge für Microsoft 365: MX, SPF, DKIM, DMARC.

      Ausgehend:

    3. E-Mail (Microsoft 365) in Betrieb

      Postfächer der Firma. Ausgehende E-Mails bestehen SPF, DKIM und DMARC.

  6. Betrieb

    1. Ablage jedes Stands in Betrieb

      Jeder veröffentlichte Stand liegt mit Prüfsumme in der Ablage.

Zurück zum Diagramm

Entscheidungen

Kontext, Entscheidung, Abwägung, Folge.

Entscheidung 01Alle Repositories privat
Kontext
Ein öffentliches Repository hätte kostenlose Pflicht-Freigaben ermöglicht.
Entscheidung
Alles bleibt privat, nichts wird zusätzlich veröffentlicht.
Abwägung
Keine Pflicht-Prüfer, keine Branch-Regeln.
Folge
Die Freigabe sitzt an der Startschaltfläche des Ausrollens (siehe Entscheidung 02).
Entscheidung 02Ausrollen nur per Handstart
Kontext
Ohne Pflicht-Prüfer ginge ein Merge sonst automatisch online.
Entscheidung
Ausgerollt wird nur per Handstart nach meiner Freigabe, nie automatisch nach einem Merge.
Abwägung
Ein bewusster Schritt mehr vor jeder Veröffentlichung.
Folge
Nichts geht versehentlich online.
Entscheidung 03Keine Fremdabrufe, strenge Content Security Policy
Kontext
Schon eine externe Schrift gibt die Besucher-IP an Dritte weiter.
Entscheidung
Schriften lokal, kein CDN. Skripte und Stile liegen im Dokument und sind in der CSP per Prüfsumme freigegeben; sonst erlaubt die CSP nur die eigene Domain.
Abwägung
Code im Dokument braucht eine Prüfsumme in der CSP, sonst läuft er nicht.
Folge
Die Pipeline prüft das automatisch; die Abnahme zählte null Fremdabrufe.
Entscheidung 04Zweitdomain gegen E-Mail-Fälschung sperren
Kontext
Über die Zweitdomain läuft keine E-Mail, doch ohne Einträge wäre sie fälschbar.
Entscheidung
SPF ohne Absender, DMARC ablehnend, Null-MX; Weiterleitung auf die englische Seite.
Abwägung
E-Mail-Versand von dort bräuchte einen bewussten Rückbau der Einträge.
Folge
Gefälschte E-Mails im Namen der Zweitdomain werden abgelehnt.
Entscheidung 05Getrennte Identitäten, signierte Commits
Kontext
Ein privates Entwicklerkonto darf nie an Firmen-Commits stehen.
Entscheidung
Eigenes Firmenkonto; der Ordner wählt die Identität, Commits werden signiert.
Abwägung
Zwei Identitäten zu pflegen, ein Abo mehr.
Folge
Jeder Commit ist überprüfbar, private und geschäftliche Arbeit bleiben getrennt.

Mensch in der Schleife

  • Claude schreibt Dateien, Prüfskripte, Workflow-Entwürfe, DNS-Sollwerte und Schritt-für-Schritt-Anleitungen.
  • Ich committe und signiere, führe zusammen und starte das Ausrollen.
  • DNS ändere ich selbst oder gebe jede Änderung ausdrücklich frei; danach wird die E-Mail sofort geprüft.
  • Konten, Zahlungen, Passwörter, Schlüssel, Verträge und Rechtstexte liegen nur bei mir.

Betrieb und Qualität

  • Abnahme nach dem Livegang: alle Seiten erreichbar, eigene Fehlerseite, interne Dateien gesperrt, Umleitungen in einem Sprung, Header auch auf Fehlerseiten, keine Fremdabrufe, E-Mail-DNS unverändert.
  • HSTS mit einem Jahr Gültigkeit, ohne Preload.
  • Die DMARC-Richtlinie der Hauptdomain ist öffentlich abfragbar (siehe „Selbst nachprüfen“).
  • Budgets für kostenpflichtige Zusatzdienste auf null mit Stopp; abgerechnet wird nur, was bewusst gebucht ist.
  • Jeder veröffentlichte Stand liegt mit Prüfsumme und Abnahmeprotokoll in der Ablage.

Selbst nachprüfen

Diese Abfragen zeigen den öffentlichen Stand. Sie brauchen nur ein Terminal oder die Entwicklerwerkzeuge Ihres Browsers.

  2. dig +short TXT _dmarc.ahnenhain.de

    DMARC-Richtlinie der Hauptdomain.

  3. dig +short TXT ahnenhain.com

    SPF der Zweitdomain: keine erlaubten Absender.

  4. dig +short MX ahnenhain.com

    Null-MX: Die Zweitdomain nimmt keine E-Mail an.

  5. Browser: Entwicklerwerkzeuge, Reiter Netzwerk, Seite neu laden

    Alle Anfragen gehen an ahnenhain.de. Keine andere Domain.

Technik

Stand

Online seit 24.09.2026, auf Deutsch und Englisch.

Wie ich mit KI arbeite

Human in the Loop: Nichts geht ohne Prüfung online.

Wer was tut

Der Mensch

formuliert
Aufgabe, Ziel, Quellen und Grenzen.
prüft
Jedes Ergebnis gegen Quelle und Ziel.
korrigiert
Was falsch oder unbelegt ist.
gibt frei
Und trägt die Verantwortung.

Die Maschine

erzeugt
Entwürfe, Code, Varianten.
testet
Tests, Lint und Validierung bei jeder Änderung.
misst
Messwerte, Abgleiche, Überwachung.
prüft unabhängig
Bei Symbiont und dieser Website prüfen Review-Agenten jede Änderung, getrennt vom bauenden Agenten.

Der Ablauf

  1. Auftrag

    Ziel, Quellen, Grenzen.

  2. Plan

    Die Maschine legt einen Plan vor, ich gebe ihn frei.

  3. Erzeugen

    Oft mit getrennten Rollen: ein Agent setzt um, ein zweiter sucht Fehler, ein dritter prüft.

  4. Maschinell prüfen

    Tests, statische Analyse, Geheimnisscan. Rot heißt: Der Schritt beginnt von vorn.

  5. Menschlich prüfen

    Ich prüfe gegen die Quelle, Unbelegtes wird markiert.

  6. Freigeben

    Erst danach wird eingesetzt oder ausgerollt.

  7. Lernen

    Jeder Fehler wird zu einer Regel oder einem Test.

Leitplanken

Erst die Daten, dann das Modell
Die Vertraulichkeitsklasse der Daten bestimmt, welches Modell sie sehen darf.
Keine sensiblen Daten ohne Konzept
Personenbezogene, Gesundheits- und Biometriedaten von Kunden nur mit Datenschutzkonzept und Auftragsverarbeitungsvertrag.
Geringste Rechte für Agenten
Nur die Werkzeuge, die der Schritt braucht; Wirkung erst nach Probelauf, riskante Schritte in der Sandbox.
Freigabe vor Einsatz
Kein Text, kein Code und keine Auswertung geht ohne menschliche Freigabe an Dritte hinaus.
Bauen und Prüfen getrennt
In meinen eigenen Projekten bauen Agenten, unabhängige Agenten prüfen, nach main kommt erst, was ich freigegeben habe.
Offen kennzeichnen
Was eine KI erzeugt hat, sage ich; nächtliche Agentenläufe werden gekennzeichnet.
Kosten im Blick
Günstigere Modelle für viele parallele Prüfungen, stärkere für die Zusammenführung.

Was ich nicht oder nur eingeschränkt baue

Entscheidungen über Menschen bereite ich nicht mit einem Modell vor, dessen Ergebnis sich nicht überprüfen lässt.

  • Auswahl von Bewerberinnen und Bewerbern und Personalentscheidungen.
  • Bewertungen der Kreditwürdigkeit.
  • Auswertungen von Leistung oder Verhalten von Mitarbeitenden nur nach vorheriger rechtlicher Prüfung.

Diese Seite ist so entstanden

Inhalte und Texte hat Claude entworfen, gebaut wurde die Seite mit Claude Code. Ich habe jeden Satz gegen die Quellen geprüft und freigegeben; jede Änderung geht als signierter Commit von mir online.

So ist diese Seite gebaut

Kontakt

Per E-Mail oder Telefon, auf Deutsch oder Englisch.

Freie Plätze: 1 von 2

Offener Knoten: frei. Geschlossener Knoten: belegt.

E-Mail
info@ahnenhain.de
Telefon
+49 160 2495853
LinkedIn
Julius C. Gnädig (öffnet eine externe Seite)

Publikationen

In Vorbereitung. Hier erscheinen Veröffentlichungen, sobald sie freigegeben sind.

Erstes Paper

Arbeitstitel

Living in Symbiosis

Format
Position Paper mit einer autoethnografischen Längsschnitt-Fallstudie (eine Person, eigene Praxis), Sprache Englisch.
Übersicht

Ausgangspunkt ist J. C. R. Lickliders Idee der Mensch-Computer-Symbiose von 1960. Das Paper beschreibt eine langjährige Arbeitspartnerschaft mit KI aus der Innensicht, gestützt auf Aufzeichnungen des eigenen Systems Symbiont.

Es unterscheidet zwei Schichten: eine eigene Aufzeichnung, die der Mensch selbst verwahrt, und eine gemietete Interaktion mit KI-Diensten. Warum wächst der Abstand zwischen denen, die mit KI arbeiten, und denen, die sie nur benutzen? Das Paper sucht die Antwort im eigenen Datenbestand, nicht im Zugang.

Fallstudie Symbiont lesen

Drei Prinzipien machen aus Werkzeugnutzung Symbiose, wenn sie Mensch und System gleichermaßen binden.

  • Validierung
  • Nachvollziehbarkeit
  • Selbstverbesserung

Hinweis zur KI-Nutzung Recherche und Entwürfe entstehen mit KI-Unterstützung; Inhalt und Freigabe verantworte ich als Autor.

Ausgewählte Quellen

  1. Licklider, J. C. R. (1960). Man-Computer Symbiosis. IRE Transactions on Human Factors in Electronics. doi:10.1109/THFE2.1960.4503259 (öffnet eine externe Seite)
  2. Clark, A., & Chalmers, D. J. (1998). The Extended Mind. Analysis. doi:10.1093/analys/58.1.7 (öffnet eine externe Seite)
  3. Jarrahi, M. H. (2018). Artificial Intelligence and the Future of Work: Human-AI Symbiosis in Organizational Decision Making. Business Horizons. doi:10.1016/j.bushor.2018.03.007 (öffnet eine externe Seite)
  4. Green, B., & Chen, Y. (2019). The Principles and Limits of Algorithm-in-the-Loop Decision Making. Proceedings of the ACM on Human-Computer Interaction. doi:10.1145/3359152 (öffnet eine externe Seite)
  5. Lucero, A., Desjardins, A., Neustaedter, C., Höök, K., Hassenzahl, M., & Cecchinato, M. E. (2019). A Sample of One: First-Person Research Methods in HCI. DIS ’19 Companion.
  6. Zahedi, Z., & Kambhampati, S. (2021). Human-AI Symbiosis: A Survey of Current Approaches. arXiv. arXiv:2103.09990 (öffnet eine externe Seite)
  7. Vaccaro, M., Almaatouq, A., & Malone, T. (2024). When Combinations of Humans and AI Are Useful: A Systematic Review and Meta-Analysis. Nature Human Behaviour. doi:10.1038/s41562-024-02024-1 (öffnet eine externe Seite)
  8. Boulus-Rødje, N., Cranefield, J., Doyle, C., & Fleron, B. (2024). GenAI and Me: The Hidden Work of Building and Maintaining an Augmentative Partnership. Personal and Ubiquitous Computing. doi:10.1007/s00779-024-01810-y (öffnet eine externe Seite)
  9. Litvinova, Y., Mikalef, P., & Luo, X. (2024). Framework for Human-XAI Symbiosis: Extended Self from the Dual-Process Theory Perspective. Journal of Business Analytics. doi:10.1080/2573234X.2024.2396366 (öffnet eine externe Seite)
  10. Tong, R. J. (2026). From Augmentation to Symbiosis: A Review of Human-AI Collaboration Frameworks, Performance, and Perils. arXiv. arXiv:2601.06030 (öffnet eine externe Seite)
  11. Wang, P., Liu, H., Zou, L., & Paas, F. (2026). Overloaded Minds and Machines: A Cognitive Load Framework for Human-AI Symbiosis. Artificial Intelligence Review. doi:10.1007/s10462-026-11510-z (öffnet eine externe Seite)

Zweites Paper

Arbeitstitel

PermaIoT

Format
Positionspapier, Sprache Englisch.
Übersicht

Ausgehend von der Idee seit 2022 und dem Konzept von 2025 beschreibt das Papier, wie IoT und KI industrielle Landwirtschaft in tragfähige Permakultur überführen können; Praxisbezug ist die Fallstudie Landwirtschaft und Imkerei.

Wie wird Permakultur mit Sensorik und spezialisierter KI so nachvollziehbar und wirtschaftlich, dass sie industrieller Landwirtschaft nicht nur ökologisch, sondern auch betriebswirtschaftlich überlegen ist?

Fallstudie Landwirtschaft und Imkerei lesen

  • Gesundheit vor Ertrag. Zustand von Boden, Pflanzen und Tieren ist die erste Messgröße, Ertrag die zweite.
  • Messen statt vermuten. Sensorik macht Permakultur nachvollziehbar; was gemessen ist, lässt sich finanzieren und wiederholen.
  • Technik dient dem Hof, nicht umgekehrt. Module laufen beim Betrieb, bleiben verständlich und ohne laufende Abhängigkeit.

Hinweis zur KI-Nutzung Recherche und Entwürfe entstehen mit KI-Unterstützung; Inhalt und Freigabe verantworte ich als Autor.

AI Engineer · KI-Agenten und Automatisierung, sicher im Betrieb

Julius C. Gnädig

Inhaber Ahnenhain Systems

Werdegang

  1. seit 09/2026

    Inhaber, Ahnenhain Systems

    KI, Automatisierung und Datenanalyse für wenige ausgewählte Kunden.

  2. seit 04/2026

    Technische Verantwortung in einem Self-Service-Plattformprojekt

  3. seit 03/2026

    AI Champion in einem teamübergreifenden Netzwerk

    • Gemeinsamer Wissensspeicher, der KI-Agenten über MCP dauerhaft Kontext gibt, mit geprüften Entscheidungen, Nachvollziehbarkeit und Selbstverbesserung als Grundsätzen
    • Agentischer Engineering-Workflow vom Start-Prompt bis zur Dokumentation, mit Autonomiestufen, Freigaben und Prüfpunkten
    • Wiederkehrende Betriebsaufgaben als versionierte, testbare Agent Skills
    • KI-Dokumentations-Workflow mit Quellenprüfung: Unbelegtes geht zur menschlichen Prüfung
    • Governance in den Workflows: Datenklassen, Sandbox und Probeläufe, freigegebene MCP-Server, menschliche Freigabe; Kosten und Qualität gegen eine Basislinie gemessen
    • Workshops, Live-Demos und Einzeltermine je nach Kenntnisstand

  4. seit 07/2023

    Platform Engineer

    Die Rolle hieß bis 2026 Cloud Engineer.

    • Apache Kafka und Confluent Platform auf Kubernetes aktualisieren und betreiben
    • Rollouts mit Ansible und AWX automatisieren, mit Grafana und Confluent Control Center prüfen
    • Monitoring und Alarmbearbeitung im Team mit Grafana, Prometheus und Flux

  5. 09/2020 bis 06/2023

    Ausbildung zum Fachinformatiker für Systemintegration

    Duale Ausbildung mit IHK-Abschluss 2023.

    • Ab 2022 im Kafka- und Messaging-Team: Kubernetes, laufende Upgrades aller Kafka- und Confluent-Komponenten mit Ansible und AWX, Helm
    • IHK-Abschlussprojekt: ein Add-on, das DevOps-Aufgaben rund um Apache Kafka vereinfacht

Kurzprofil

Ich baue KI-Agenten und die Plattform darunter. Meine Wurzeln liegen in Kubernetes und Event-Streaming mit Apache Kafka und Confluent; seit 2026 trage ich die technische Verantwortung für ein Self-Service-Plattformprojekt. Als AI Champion entwickle ich agentische Werkzeuge für mehrere Teams. Seit 2022 arbeite ich täglich mit generativer KI, seit 2023 mit eigenen Workflows. Als Labor dienen mir eine selbst gehostete Automatisierungsumgebung (n8n, PostgreSQL, Docker) und eine eigene Entwicklungsplattform auf Kubernetes. Meine Grundsätze: geprüfte Entscheidungen, Nachvollziehbarkeit und Selbstverbesserung.

Werkzeuge

KI und Agenten
Generative KI, KI-Agenten, agentische Entwicklung, Agent Skills, Model Context Protocol (MCP), Claude Code, GitHub Copilot, Context Engineering, Prompt Engineering, Retrieval-Augmented Generation (RAG), Function Calling, KI-gestützte Entwicklung, KI-Governance, Human in the Loop, KI-Kostenoptimierung
Automatisierung
n8n, Workflow-Design, Telegram-Bots, Webhooks
Plattform
Kubernetes, k3s, Flux, GitOps, Kustomize, Helm, Crossplane, Kyverno, Policy as Code, Docker, Podman, Ansible, AWX, GitHub Actions, Grafana, Prometheus
Daten
PostgreSQL, pgvector, Kafka, Confluent, Datenpipelines, Datenanalyse
Sicherheit
RBAC, OIDC, Workload Identity Federation, Secrets Management mit SOPS und age, E-Mail-Sicherheit mit SPF, DKIM und DMARC
Programmiersprachen
Go, Python, TypeScript, Bash, SQL; Grundlagen in Java und C#; YAML für Konfiguration
Arbeitsweise
Wissenstransfer, Workshops, Architekturentscheidungen dokumentieren, Review und Freigabe, BDD-Tests, Scope und MVP

Ohne Selbsteinstufung in Stufen. Belege stehen in den Projekten.

Ausbildung und Weiterbildung

  • Kubernetes für Service-Provider, dreitägige Weiterbildung2024
  • Fachinformatiker für Systemintegration, IHK Nürnberg, Berufsschule Fürth mit Note 1,7 (deutsche Skala, 1 = beste)2023
  • Ansible Advanced, Orchestrierung im Detail, ExperTeach, viertägige Weiterbildung mit Zertifikat2022
  • Scrum2021
  • Test-Driven Development mit C#2021
  • Datenbankgrundlagen2021
  • Cambridge EnglishFirst Certificate

Sprachen

  • DeutschMuttersprache
  • Englischnahezu muttersprachlich, bilingualer Schulzweig (Klasse 5 bis 10)

Im Druckdialog können Sie die Ausgabe als PDF sichern.

Kontakt

Per E-Mail oder Telefon, auf Deutsch oder Englisch.

Freie Plätze: 1 von 2

Offener Knoten: frei. Geschlossener Knoten: belegt.

E-Mail
info@ahnenhain.de
Telefon
+49 160 2495853
LinkedIn
Julius C. Gnädig (öffnet eine externe Seite)

So ist diese Seite gebaut

Eine Seite über Sicherheit und KI sollte zeigen, wie sie selbst gebaut ist.

Was diese Seite nicht tut

  • Keine Cookies.
  • Kein Tracking, keine Statistik-Skripte, keine Besucherzählung durch Dritte.
  • Keine Abrufe bei fremden Servern: Schriften, Bilder und Skripte kommen von dieser Domain.
  • Keine Datenbank: Das Rückruf-Formular schickt Ihre Angaben als E-Mail an mich und speichert nichts.
  • Ohne JavaScript vollständig lesbar. Bewegung gibt es nur, wenn das System keine reduzierte Bewegung verlangt.

Messwerte

Lighthouse, mobil

  • 74Leistung
  • 100Barrierefreiheit
  • 100Best Practices
  • 100SEO

Gemessen beim Bau, automatisch eingesetzt. Keine Werte von Hand.

Live gemessen, in Ihrem Browser

Die Live-Messung braucht JavaScript. Ohne JavaScript bleibt sie leer, die Seite funktioniert trotzdem.

Übertragen, gesamt
wird gemessen

Summe von transferSize für das Dokument und alle Ressourcen, mit Kopfzeilen, so wie sie über das Netz kamen.

Dokument
wird gemessen

Die HTML-Datei selbst. Schriften, Stile und Skripte stecken bei dieser Seite darin.

Anfragen
wird gemessen

Das Dokument plus jede Ressource, die der Browser danach geladen hat.

Anfragen an fremde Herkunft
wird gemessen

Jede Anfrage, deren Herkunft (Schema, Host, Port) nicht die dieser Seite ist.

DOMContentLoaded
wird gemessen

Zeit ab Navigationsbeginn, bis das HTML gelesen und die Skripte gelaufen sind.

Load
wird gemessen

Zeit ab Navigationsbeginn, bis auch alle Ressourcen geladen sind.

Aus dem Cache
wird gemessen

transferSize 0 bei vorhandenem Inhalt heißt: Der Browser hat nichts übertragen, er hatte die Datei schon. Dann wird die Übertragung korrekt mit 0 angegeben.

Skripte
wird gemessen
Stilblöcke
wird gemessen

Gezählt im Dokument: eingebettet und als eigene Datei.

Prüfwerte beim Bauen

LighthousemobilDesktop
Leistung7498
Barrierefreiheit100100
Best Practices100100
SEO100100
axe-core Verstöße
0 in 204 Zuständen
Gemessen am
13.10.2026
Werkzeuge
Lighthouse 13.5.0, axe-core 4.13.0, Chromium 141.0.7390.37
Geprüft
Alle Seiten der Livefassung, Deutsch und Englisch

Gemessen mit Lighthouse und axe-core in einem Browser ohne Bildschirm, in der Prüfpipeline. Lighthouse: Median aus fünf Läufen.

Sicherheitsheader

Content-Security-Policy
Nur Inhalte von dieser Domain, Skripte und Stile nur von dieser Domain oder mit Prüfsumme in der CSP.
Strict-Transport-Security
Browser verbinden sich nur verschlüsselt.
X-Content-Type-Options
Dateien werden nur als das gelesen, was sie laut Server sind.
Referrer-Policy
Beim Verlassen wird höchstens die Domain weitergegeben.
Permissions-Policy
Kamera, Mikrofon, Standort, Bewegungssensoren, Zahlung und USB abgeschaltet.
X-Frame-Options
Die Seite lässt sich nicht in fremde Rahmen laden.

Gestaltung

Schriften
Cinzel für Wortmarke, EB Garamond für Text, Source Sans 3 für Bedienung. Alle unter SIL Open Font License, lokal ausgeliefert.
Farben
Aus der Markenrichtlinie: Tanne-tief, Tanne und Nadel für Flächen und Text, Elfenbein als Papier, Harzgold nur als Linie und Akzent.
Zeichen
Ein Baum, der durch einen Zahnradring wächst.
Bewegung
Ruhig und sparsam, nie bei eingestellter reduzierter Bewegung.

Werkzeuge

Wer was gemacht hat

Ich (Julius C. Gnädig)
Ziel, Inhalte, Entscheidungen, Prüfung und Freigabe jedes Textes, Commits, Veröffentlichung.
Claude
Recherche, Textentwürfe auf Deutsch und Englisch, Gestaltungsvorschläge.
Claude Code
Bau der Seite, Prüfskripte, Pipeline.
Maschinelle Prüfungen
Validierung, Geheimnisscan, Fremdabruf-Prüfung, Messwerte bei jedem Bau. Unabhängige Review-Agenten prüfen jede Änderung zusätzlich.

Jeder Entwurf ging durch meine Prüfung, bevor er online ging.

Lizenzen

Cinzel © The Cinzel Project Authors, EB Garamond © The EB Garamond Project Authors, Source Sans 3 © Adobe. Alle unter SIL Open Font License 1.1, der Lizenztext liegt bei den Schriftdateien. Die eingebettete Teilmenge von Source Sans 3 läuft unter dem Namen „Ahnenhain Grotesk“ (Namenstabelle angepasst, wie von der OFL für veränderte Fassungen vorgesehen); Herkunft und Lizenz bleiben Source Sans 3, Adobe, SIL Open Font License 1.1.

Kontakt

Per E-Mail oder Telefon, auf Deutsch oder Englisch.

Freie Plätze: 1 von 2

Offener Knoten: frei. Geschlossener Knoten: belegt.

E-Mail
info@ahnenhain.de
Telefon
+49 160 2495853
LinkedIn
Julius C. Gnädig (öffnet eine externe Seite)

Nur wenige Aufträge gleichzeitig.

Rückruf-Formular ohne Tracking, Daten nur per E-Mail an mich, nicht gespeichert.

Gespräch anfragen

Name, eine Möglichkeit zur Rückmeldung und ein Stichwort genügen. Ich melde mich im gewählten Zeitfenster.

Ihre Angaben gehen nur per E-Mail an mich und werden auf dem Server nicht gespeichert. Mehr in der Datenschutzerklärung. Alle Zeiten deutsche Zeit.

Wo lohnt sich ein Agent?

Fünf Fragen zu einer Aufgabe aus Ihrem Alltag. Die Einschätzung entsteht in Ihrem Browser. Es wird nichts übertragen und nichts gespeichert.

Die fünf Fragen

  1. Wie oft fällt die Aufgabe an? Mehrmals täglich · Täglich oder mehrmals pro Woche · Etwa einmal im Monat · Selten oder einmalig
  2. Wie lange dauert ein Durchgang? Länger als zwei Stunden · 30 Minuten bis zwei Stunden · 5 bis 30 Minuten · Unter 5 Minuten
  3. Wie strukturiert sind die Eingangsdaten? Fest aufgebaut, etwa Formulare oder Tabellen · Überwiegend einheitlich, mit Ausnahmen · Gemischt, etwa E-Mails und PDFs unterschiedlicher Herkunft · Frei oder nur im Kopf vorhanden
  4. Was kostet ein Fehler? Wenig: Er fällt auf und ist schnell korrigiert · Spürbar: Nacharbeit oder Ärger · Hoch: Geld, Vertrag oder Kundenvertrauen · Schwer: Recht, Sicherheit oder nicht rückholbar
  5. Wer kann das Ergebnis prüfen und freigeben? Eine fachkundige Person, schnell · Jemand, aber es kostet Zeit · Nur stichprobenartig · Niemand, das Ergebnis geht direkt raus

Ohne JavaScript gilt: Je häufiger und zeitaufwendiger die Aufgabe, je fester die Eingangsdaten und je besser jemand das Ergebnis prüft, desto eher lohnt sich ein Agent. Ist ein Fehler teuer und prüft niemand, lohnt er sich nicht.

Diese Seite gibt es nicht.

Vielleicht hat sich die Adresse geändert, oder sie enthält einen Tippfehler. Einer dieser Wege führt weiter:

Oder suchen Sie mit Strg + K beziehungsweise ⌘ + K.

Aufbauvorschlag · Kleine Betriebe und Handwerk

Anfragen lesen, sortieren, Antwort vorbereiten

Terminanfragen per E-Mail oder Sprachnachricht werden als Antwortvorschlag vorbereitet. Gesendet wird erst nach Ihrer Freigabe.

Ausgangslage

Anfragen kommen per E-Mail und als Sprachnachricht, oft zwischen zwei Terminen. Sie müssen gelesen, nach Dringlichkeit sortiert und beantwortet werden, während der Betrieb weiterläuft.

Zielbild

  1. Eingehende Anfragen werden erkannt, sortiert und mit einem Antwortvorschlag versehen.
  2. Terminvorschläge stammen aus dem echten Kalender, nicht aus der Vermutung eines Modells.
  3. Nichts wird ohne Ihre Freigabe versendet.
  4. Personenbezogene Daten bleiben auf das Nötige beschränkt und liegen in der EU oder auf Ihrem eigenen Server.

Architektur

Von der eingehenden Anfrage bis zur freigegebenen Antwort.

Wählen Sie eine Komponente. Die Erklärung erscheint daneben, ihre Datenflüsse werden hervorgehoben.

Architektur als Liste lesen

Keine Komponente gewählt.

Architektur als Liste lesen

Architektur als Text, als Vorschlag. Anfragen kommen als E-Mail oder Sprachnachricht in einem eigens eingerichteten Postfach an. Eine Workflow-Steuerung nimmt jede Anfrage entgegen und ruft die Schritte nacheinander auf. Sprachnachrichten werden von einer Spracherkennung in Text umgewandelt. Ein Sprachmodell liest den Text und liefert strukturierte Felder: Anliegen, Dringlichkeit, Wunschtermin; die Ausgabe wird gegen ein Schema geprüft. Feste Prüfregeln kontrollieren Felder und Absender. Freie Zeiten kommen lesend aus dem Kalender. Aus Feldern, Textbausteinen und freien Zeiten entsteht ein Antwortvorschlag. Eine Freigabe-Oberfläche zeigt Anfrage und Vorschlag nebeneinander; die Inhaberin oder der Inhaber sendet, ändert oder verwirft. Der Versand läuft nur für freigegebene Antworten. Eine Datenbank hält Anfragen, Entwürfe und Entscheidungen mit Löschfrist, ein Protokoll mit Überwachung macht Fehler und Kosten sichtbar.

  1. Eingang

    1. Postfach und Sprachnachricht Vorschlag

      Nimmt E-Mails und Sprachnachrichten in einem eigens eingerichteten Postfach oder Messenger-Kanal entgegen.

      Ausgehend:

  2. Steuerung

    1. Workflow-Steuerung Vorschlag

      Startet bei jeder Anfrage, ruft die Schritte nacheinander auf, wiederholt Fehlschläge und legt nichts Unvollständiges ab.

      Ausgehend:

  3. KI und Regeln

    1. Spracherkennung Vorschlag

      Wandelt Sprachnachrichten in Text um. Das Audio bleibt nicht dauerhaft liegen.

      Ausgehend:

    2. Sprachmodell mit Schema Vorschlag

      Liest die Anfrage und liefert Felder statt freier Prosa. Ungültige Ausgaben werden abgelehnt.

      Ausgehend:

    3. Prüfregeln Vorschlag

      Feste Regeln prüfen Felder, Absender und Grenzen, bevor etwas weitergeht.

      Ausgehend:

    4. Antwortvorschlag Vorschlag

      Formuliert den Entwurf in Ihrem Ton aus Textbausteinen, Feldern und freien Zeiten.

      Ausgehend:

  4. Daten

    1. Kalender, nur lesend Vorschlag

      Liefert freie Zeiten. Das Modell rät keine Termine.

      Ausgehend:

    2. Datenbank mit Löschfrist Vorschlag

      Hält Anfragen, Entwürfe und Entscheidungen. Nach der festgelegten Frist werden sie gelöscht.

  5. Mensch

    1. Freigabe durch Sie Vorschlag

      Zeigt Anfrage und Vorschlag nebeneinander. Sie senden, ändern oder verwerfen.

      Ausgehend:

  6. Ausgang

    1. Versand Vorschlag

      Sendet nur freigegebene Antworten über Ihr eigenes Postfach.

  7. Betrieb

    1. Protokoll und Überwachung Vorschlag

      Hält jeden Schritt mit Ergebnis fest und macht Fehler und Kosten sichtbar.

Zurück zum Diagramm

Bausteine

Bausteine
AufgabeTechnikWarum
EingangPostfach per Abruf oder Weiterleitung, Messenger-KanalAnfragen kommen dort an, wo sie ohnehin eintreffen.
SteuerungWorkflow-Werkzeug (zum Beispiel n8n), Warteschlange, WiederholungslogikJeder Schritt ist sichtbar, Fehlschläge werden wiederholt statt verschluckt.
Sprache zu TextSpracherkennungsmodellSprachnachrichten werden lesbar, ohne dass Audio liegen bleibt.
VerstehenSprachmodell mit strukturierter Ausgabe und Schema-PrüfungFelder statt Prosa: Ungültiges wird abgelehnt, nicht weitergereicht.
TermineKalender-Schnittstelle, nur lesendVorschläge beruhen auf echten freien Zeiten.
FreigabeFreigabe-Oberfläche oder Messenger-SchaltflächenSie entscheiden, bevor etwas den Betrieb verlässt.
DatenPostgreSQL, Löschfrist per ZeitplanEin Ort für Zustand und Entscheidungen, mit festem Ablauf der Aufbewahrung.
BetriebProtokolle, Tracing der Modellaufrufe, Dashboards mit GrafanaFehler und Kosten bleiben sichtbar.

Mensch in der Schleife

  • Der Antwortvorschlag verlässt das System nur über Ihre Freigabe: senden, ändern oder verwerfen.
  • Unklare oder dringliche Anfragen werden markiert und zuerst vorgelegt, nicht automatisch beantwortet.
  • Termine und Zusagen gelten erst, wenn Sie sie bestätigt haben.

Datenschutz in der Architektur

  • Datenminimierung: Das Modell erhält den Text der Anfrage, nicht Ihre Kundenstammdaten.
  • Hosting in der EU oder auf einem eigenen Server.
  • Mit jedem externen Modellanbieter wird vor dem Start ein Auftragsverarbeitungsvertrag geschlossen.
  • Löschfristen sind festgelegt: Anfragen und Entwürfe werden nach Ablauf gelöscht, Audio wird nicht aufbewahrt.

Technische Gestaltung, keine Rechtsberatung.

Betrieb und Sicherheit

  • Protokoll: Jeder Schritt wird mit Ergebnis festgehalten, damit sich nachvollziehen lässt, was vorgeschlagen wurde.
  • Überwachung: Fehler, Wartezeiten und Modellkosten werden angezeigt; eine Tagesgrenze für Kosten verhindert Ausreißer.
  • Tests und Bewertungen: Ein fester Satz echter Beispielanfragen prüft nach jeder Änderung, ob Sortierung und Entwürfe gut bleiben.
  • Geheimnisse: Zugangsdaten liegen in einem Geheimnisspeicher, nicht im Workflow.
  • Rechte: Zugriffe sind so eng wie möglich, der Kalender nur lesend, das Postfach nur für den Versand freigegebener Antworten.

Passt das zu Ihrem Betrieb? Im Kennenlernen klären wir es, kostenlos.

Gespräch anfragen

Aufbauvorschlag · Vereine und Organisationen

Mitgliederpost aus Notizen

Aus Ihren Notizen entsteht der Entwurf, etwa eine Terminänderung der Probe. Eine Person aus dem Vorstand liest und gibt jeden Text frei.

Ausgangslage

Im Verein schreibt meist eine Person nebenbei die Rundmails. Informationen liegen verstreut in Notizen, Chatnachrichten und Terminlisten, und jeder Text soll Ton und Fakten treffen.

Zielbild

  1. Notizen und Terminliste werden zu einem Entwurf in der gewohnten Form der Vereinspost.
  2. Termine, Orte und Namen im Entwurf stammen aus der Terminliste und werden gegen sie geprüft.
  3. Eine Person aus dem Vorstand liest und gibt jeden Text frei.
  4. Mitgliederdaten bleiben in der Mitgliederverwaltung; der Entwurf erhält nur, was er braucht.

Architektur

Von der Notiz bis zur freigegebenen Mitgliederpost.

Wählen Sie eine Komponente. Die Erklärung erscheint daneben, ihre Datenflüsse werden hervorgehoben.

Architektur als Liste lesen

Keine Komponente gewählt.

Architektur als Liste lesen

Architektur als Text, als Vorschlag. Notizen aus der Sitzung und eine gepflegte Terminliste sind die Quelle der Fakten. Eine Workflow-Steuerung startet bei neuen Notizen und ruft die Schritte nacheinander auf. Frühere, freigegebene Rundmails dienen als Muster für Ton und Aufbau. Ein Sprachmodell formuliert den Entwurf und liefert feste Felder: Betreff, Text, genannte Termine. Eine Faktenprüfung gleicht Termine, Orte und Namen mit der Terminliste ab; Abweichungen werden markiert, nicht still korrigiert. Der Entwurf sieht keine Adressen. Eine Person aus dem Vorstand liest den Entwurf mit den markierten Abweichungen, ändert ihn oder gibt ihn frei. Der Versand erfolgt nur für freigegebene Texte, über das Postfach des Vereins und an den Verteiler aus der Mitgliederverwaltung. Eine Ablage hält Entwürfe, Freigaben und Änderungen mit Löschfrist; ein Protokoll mit Überwachung macht Fehler sichtbar.

  1. Eingang

    1. Notizen und Terminliste Vorschlag

      Quelle der Fakten: Notizen aus der Sitzung und eine gepflegte Terminliste.

      Ausgehend:

  2. Steuerung

    1. Workflow-Steuerung Vorschlag

      Startet bei neuen Notizen, ruft die Schritte nacheinander auf und wiederholt Fehlschläge.

      Ausgehend:

  3. KI und Regeln

    1. Sprachmodell mit festen Feldern Vorschlag

      Formuliert den Entwurf. Die Ausgabe hat feste Felder: Betreff, Text, genannte Termine.

      Ausgehend:

    2. Faktenprüfung Vorschlag

      Gleicht Termine, Orte und Namen mit der Terminliste ab. Abweichungen werden markiert, nicht still korrigiert.

      Ausgehend:

  4. Daten

    1. Ablage mit Löschfrist Vorschlag

      Hält Entwürfe, Freigaben und Änderungen. Nach der festgelegten Frist werden sie gelöscht.

    2. Verteiler der Mitgliederverwaltung Vorschlag

      Hält die Adressen. Der Entwurf sieht sie nicht, nur der Versand.

      Ausgehend:

    3. Vorlagen und Tonvorgaben Vorschlag

      Frühere, freigegebene Rundmails als Muster für Ton und Aufbau.

      Ausgehend:

  5. Mensch

    1. Freigabe durch den Vorstand Vorschlag

      Eine Person liest den Entwurf mit den markierten Abweichungen, ändert ihn oder gibt ihn frei.

      Ausgehend:

  6. Ausgang

    1. Versand Vorschlag

      Sendet nur freigegebene Texte über das Postfach des Vereins.

  7. Betrieb

    1. Protokoll und Überwachung Vorschlag

      Hält jeden Schritt fest und macht Fehler und Kosten sichtbar.

Zurück zum Diagramm

Bausteine

Bausteine
AufgabeTechnikWarum
QuelleGemeinsames Notizdokument, Terminliste als Tabelle oder KalenderDie Fakten liegen an einem Ort, den der Verein ohnehin pflegt.
SteuerungWorkflow-Werkzeug (zum Beispiel n8n), Warteschlange, WiederholungslogikJeder Schritt ist sichtbar, Fehlschläge werden wiederholt statt verschluckt.
EntwurfSprachmodell mit Vorlage und strukturierter AusgabeTon und Aufbau folgen früheren Mailings, die Ausgabe hat feste Felder.
FaktenprüfungFeste Abgleichsregeln gegen die TerminlisteEin Modell schlägt vor, die Regeln entscheiden, was als abweichend gilt.
FreigabeFreigabe-Oberfläche oder Messenger-SchaltflächenEine Person mit Verantwortung entscheidet vor jedem Versand.
VersandVereinspostfach, Verteiler aus der MitgliederverwaltungAdressen bleiben im System, das sie ohnehin führt.
AblagePostgreSQL, Löschfrist per ZeitplanEntwürfe und Freigaben bleiben nachvollziehbar, aber nicht unbegrenzt.
BetriebProtokolle, Tracing der Modellaufrufe, Dashboards mit GrafanaFehler und Kosten bleiben sichtbar.

Mensch in der Schleife

  • Eine Person aus dem Vorstand liest jeden Text und gibt ihn frei. Ohne Freigabe geht nichts hinaus.
  • Abweichungen von der Terminliste sind im Entwurf markiert, damit die Prüfung gezielt erfolgt.
  • Wer freigibt, kann ändern und verwerfen; das System versendet nie von sich aus.

Datenschutz in der Architektur

  • Datenminimierung: Der Entwurf erhält Notizen und Terminliste, keine Adressen und keine Mitgliederlisten.
  • Vertrauliches wie Gesundheitsangaben oder Streitfälle gehört nicht in die Notizen, die das Modell liest.
  • Hosting in der EU oder auf einem eigenen Server; mit jedem externen Modellanbieter wird vor dem Start ein Auftragsverarbeitungsvertrag geschlossen.
  • Löschfristen sind festgelegt: Entwürfe und Notizen werden nach Ablauf gelöscht.

Technische Gestaltung, keine Rechtsberatung.

Betrieb und Sicherheit

  • Protokoll: Jeder Schritt wird mit Ergebnis festgehalten, damit sich nachvollziehen lässt, was vorgeschlagen und was freigegeben wurde.
  • Überwachung: Fehler und Modellkosten werden angezeigt; eine Tagesgrenze für Kosten verhindert Ausreißer.
  • Tests und Bewertungen: Ein fester Satz früherer Notizen prüft nach jeder Änderung, ob Entwürfe Termine und Namen korrekt treffen.
  • Geheimnisse: Zugangsdaten liegen in einem Geheimnisspeicher, nicht im Workflow.
  • Rechte: Der Versand ist die einzige Stelle mit Zugriff auf das Postfach und den Verteiler.

Passt das zu Ihrem Verein? Im Kennenlernen klären wir es, kostenlos.

Gespräch anfragen

Aufbauvorschlag · Teams und Selbstständige

Angebote nachfassen

Offene Angebote werden erkannt, das Nachfassen wird als Entwurf vorbereitet. Die Person, die das Angebot gemacht hat, liest den Entwurf und sendet ihn selbst.

Ausgangslage

Angebote gehen hinaus und verschwinden im Postfach. Das Nachfassen wird aufgeschoben, weil niemand den Überblick hat, wer noch auf eine Antwort wartet.

Zielbild

  1. Offene Angebote werden aus Postfach und einem einfachen Kundenverzeichnis erkannt.
  2. Zu jedem offenen Angebot liegt ein Entwurf zum Nachfassen bereit, der auf den bisherigen Verlauf Bezug nimmt.
  3. Die Person, die das Angebot gemacht hat, liest den Entwurf und sendet ihn selbst.
  4. Eine Aufgabe in der Aufgabenliste erinnert, wenn eine Rückmeldung ausbleibt.

Architektur

Vom offenen Angebot bis zum gesendeten Nachfassen.

Wählen Sie eine Komponente. Die Erklärung erscheint daneben, ihre Datenflüsse werden hervorgehoben.

Architektur als Liste lesen

Keine Komponente gewählt.

Architektur als Liste lesen

Architektur als Text, als Vorschlag. Ein zeitgesteuerter Workflow prüft regelmäßig, welche Angebote ohne Antwort geblieben sind. Er liest dafür lesend das Postfach und ein einfaches Kundenverzeichnis, etwa eine Tabelle oder ein schlankes CRM mit Angebotsstatus. Ein Sprachmodell liest den bisherigen Verlauf und stellt fest, ob ein Angebot offen ist; es liefert Felder und entscheidet nichts. Feste Prüfregeln legen fest, ob nachgefasst wird: Mindestabstand, keine doppelte Meldung, nichts an gesperrte Kontakte. Aus dem Verlauf entsteht ein Entwurf zum Nachfassen. Die Person, die das Angebot gemacht hat, liest den Entwurf und sendet ihn selbst, ändert ihn oder verwirft ihn. Eine Aufgabe in der Aufgabenliste erinnert, wenn eine Rückmeldung ausbleibt. Ein Protokoll mit Überwachung macht Fehler und Kosten sichtbar.

  1. Eingang

    1. Postfach, nur lesend Vorschlag

      Liefert den Verlauf zu jedem Angebot. Es wird nur gelesen, nie gesendet.

      Ausgehend:

  2. Steuerung

    1. Zeitgesteuerter Workflow Vorschlag

      Prüft regelmäßig auf Angebote ohne Antwort, ruft die Schritte nacheinander auf und wiederholt Fehlschläge.

      Ausgehend:

  3. KI und Regeln

    1. Sprachmodell als Leser Vorschlag

      Liest den Verlauf und stellt fest, ob ein Angebot offen ist. Es liefert Felder und entscheidet nichts.

      Ausgehend:

    2. Prüfregeln Vorschlag

      Feste Regeln: Mindestabstand, keine doppelte Meldung, nichts an gesperrte Kontakte.

      Ausgehend:

    3. Entwurf zum Nachfassen Vorschlag

      Formuliert einen kurzen Entwurf, der auf den bisherigen Verlauf Bezug nimmt.

      Ausgehend:

  4. Daten

    1. Aufgabenliste Vorschlag

      Erinnert die zuständige Person, wenn eine Rückmeldung ausbleibt.

    2. Einfaches Kundenverzeichnis Vorschlag

      Eine Tabelle oder ein schlankes CRM mit Angebotsstatus: offen, beantwortet, abgesagt.

      Ausgehend:

  5. Mensch

    1. Lesen und selbst senden Vorschlag

      Die Person, die das Angebot gemacht hat, liest den Entwurf und sendet ihn selbst, ändert ihn oder verwirft ihn.

      Ausgehend:

  6. Betrieb

    1. Protokoll und Überwachung Vorschlag

      Hält jeden Schritt fest und macht Fehler und Kosten sichtbar.

Zurück zum Diagramm

Bausteine

Bausteine
AufgabeTechnikWarum
QuellePostfach (lesend), einfaches Kundenverzeichnis als Tabelle oder CRMDer Überblick entsteht aus Daten, die ohnehin vorhanden sind.
SteuerungZeitgesteuerter Workflow (zum Beispiel n8n), WiederholungslogikDie Prüfung läuft regelmäßig, ohne dass jemand daran denken muss.
VerstehenSprachmodell mit strukturierter Ausgabe und Schema-PrüfungFelder statt Prosa: Ungültiges wird abgelehnt, nicht weitergereicht.
RegelnFeste Prüfregeln in Code oder WorkflowOb nachgefasst wird, entscheiden Regeln, nicht das Modell.
EntwurfSprachmodell mit Vorlage im Ton der PersonDer Entwurf klingt nach Ihnen und nimmt Bezug auf den Verlauf.
FreigabeFreigabe-Oberfläche oder Messenger-SchaltflächenDie Person entscheidet und sendet selbst.
ErinnerungAufgabenliste oder KalenderEine ausbleibende Antwort wird sichtbar, ohne dass etwas automatisch hinausgeht.
BetriebProtokolle, Tracing der Modellaufrufe, Dashboards mit GrafanaFehler und Kosten bleiben sichtbar.

Mensch in der Schleife

  • Der Entwurf wird nie automatisch gesendet. Die Person, die das Angebot gemacht hat, liest, ändert oder verwirft ihn.
  • Wer ein Angebot nicht nachfassen möchte, sperrt den Kontakt; das System respektiert das.
  • Der Status im Kundenverzeichnis ändert sich erst, wenn die Person ihn bestätigt.

Datenschutz in der Architektur

  • Datenminimierung: Das Modell sieht den Verlauf eines einzelnen Angebots, nicht das ganze Postfach.
  • Hosting in der EU oder auf einem eigenen Server; mit jedem externen Modellanbieter wird vor dem Start ein Auftragsverarbeitungsvertrag geschlossen.
  • Löschfristen sind festgelegt: Zwischenstände und Entwürfe werden nach Ablauf gelöscht.
  • Das Postfach wird nur gelesen; für den Versand gibt es keinen Zugang aus dem System heraus.

Technische Gestaltung, keine Rechtsberatung.

Betrieb und Sicherheit

  • Protokoll: Jeder Schritt wird mit Ergebnis festgehalten, damit sich nachvollziehen lässt, warum ein Angebot als offen galt.
  • Überwachung: Fehler und Modellkosten werden angezeigt; eine Tagesgrenze für Kosten verhindert Ausreißer.
  • Tests und Bewertungen: Ein fester Satz echter Verläufe prüft nach jeder Änderung, ob offene Angebote richtig erkannt werden.
  • Geheimnisse: Zugangsdaten liegen in einem Geheimnisspeicher, nicht im Workflow.
  • Rechte: So eng wie möglich, das Postfach nur lesend, das Verzeichnis nur für die Statusfelder.

Passt das zu Ihrer Arbeit? Im Kennenlernen klären wir es, kostenlos.

Gespräch anfragen

Impressum

Das Impressum steht auf einer eigenen Seite.

Impressum öffnen

Datenschutz

Die Datenschutzerklärung steht auf einer eigenen Seite.

Datenschutzerklärung öffnen

Glossar

Fachbegriffe und Markennamen sind im Lesetext hervorgehoben. Diese Seite erklärt sie gesammelt und alphabetisch, ohne Wertung.

A

Admission-Validierung

Fachbegriff

Admission-Validierung prüft jede Änderung an einem Kubernetes-Cluster automatisch gegen festgelegte Regeln, bevor sie wirksam wird.

Agent Skills

Fachbegriff

Agent Skills sind vorbereitete Anleitungen und Werkzeuge, die einem KI-Agenten zeigen, wie er eine bestimmte, wiederkehrende Aufgabe erledigt.

ALKIS

Fachbegriff

ALKIS ist das amtliche deutsche Liegenschaftskatasterinformationssystem, das Flurstücke und Gebäude bundesweit einheitlich beschreibt.

Ansible

Marke

Ansible ist eine Software zur Automatisierung von Konfiguration und Betrieb, die Abläufe in einfachen Textdateien beschreibt.

API

Fachbegriff

Eine API (Programmierschnittstelle) legt fest, wie Programme miteinander Daten austauschen und Funktionen aufrufen.

Architecture Decision Records

Fachbegriff

Architecture Decision Records sind kurze, versionierte Dokumente, die eine Entscheidung, ihren Kontext, die Abwägung und ihre Folgen festhalten.

Architekturrichtlinie

Fachbegriff

Eine Architekturrichtlinie ist eine schriftlich festgehaltene Regel dafür, wie technische Systeme in einem Unternehmen aufgebaut werden sollen.

Arduino

Marke

Arduino ist eine offene Plattform aus Mikrocontroller-Hardware und zugehöriger Entwicklungsumgebung für elektronische Projekte.

Ausrollen

Fachbegriff

Ausrollen (auch Rollout oder Deployment) heißt, eine neue Version einer Software auf dem System zu veröffentlichen, das sie tatsächlich nutzt.

AWX

Marke

AWX ist eine Weboberfläche und Plattform für Ansible, über die sich Automatisierungsabläufe planen, ausführen und nachverfolgen lassen.

axe-core

Marke

axe-core ist eine Bibliothek, die Webseiten automatisch auf Verstöße gegen Regeln der Barrierefreiheit prüft.

B

Bash

Fachbegriff

Bash ist eine verbreitete Shell, mit der sich Befehle und kleine Skripte auf der Kommandozeile ausführen lassen.

Best Practices

Fachbegriff

Best Practices sind bewährte Vorgehensweisen, die sich in der Praxis als zuverlässig und empfehlenswert erwiesen haben.

Bot

Fachbegriff

Ein Bot ist ein Programm, das selbstständig Nachrichten annimmt oder verschickt und dabei wie ein automatischer Teilnehmer auftritt.

Branch

Fachbegriff

Ein Branch ist eine eigene, parallele Version des Codes, in der sich Änderungen ausprobieren lassen, ohne die Hauptversion zu berühren.

C

C#

Fachbegriff

C# ist eine objektorientierte Programmiersprache von Microsoft, die vor allem im .NET-Umfeld eingesetzt wird.

Caddy

Marke

Caddy ist ein Webserver, der eingehende Anfragen entgegennimmt und unter anderem als Reverse Proxy verschlüsselte Verbindungen und Sicherheitsheader verwaltet.

CEL

Fachbegriff

CEL (Common Expression Language) ist eine einfache Ausdruckssprache, mit der sich Bedingungen etwa für Prüfregeln formulieren lassen.

Checkout

Fachbegriff

Ein Checkout holt den Code eines Repositorys auf einen Rechner, damit er dort geprüft oder ausgerollt werden kann.

Chromium

Marke

Chromium ist das quelloffene Browser-Projekt, auf dem unter anderem Google Chrome aufbaut und das für automatisierte Prüfungen ohne Bildschirm genutzt wird.

Claude

Marke

Claude ist eine Familie von KI-Sprachmodellen des Unternehmens Anthropic für Text, Recherche und Programmierung.

Claude Code

Marke

Claude Code ist ein Werkzeug von Anthropic, das Claude in der Kommandozeile für Programmieraufgaben einsetzt, etwa zum Schreiben, Prüfen und Bauen von Code.

Cloud Engineer

Fachbegriff

Ein Cloud Engineer plant, baut und betreibt Infrastruktur und Plattformen für Cloud-Umgebungen.

Cluster

Fachbegriff

Ein Cluster ist eine Gruppe von Rechnern, die als ein gemeinsames System zusammenarbeiten und Aufgaben untereinander verteilen.

Commit

Fachbegriff

Ein Commit ist eine gespeicherte, dauerhaft nachvollziehbare Änderung am Code in einem Repository. Ein signierter Commit trägt zusätzlich eine digitale Unterschrift, die belegt, von wem er stammt.

Confluent

Marke

Confluent ist eine kommerzielle Plattform rund um Apache Kafka mit zusätzlichen Werkzeugen für Betrieb und Verwaltung.

Container

Fachbegriff

Ein Container ist eine abgeschlossene Betriebsumgebung für eine einzelne Anwendung, mit allem, was sie zum Laufen braucht.

Context Engineering

Fachbegriff

Context Engineering bedeutet, einem KI-System gezielt die richtigen Hintergrundinformationen und Unterlagen bereitzustellen, damit es eine Aufgabe zuverlässig lösen kann.

Crossplane

Marke

Crossplane ist eine Erweiterung für Kubernetes, mit der sich Cloud- und Plattformressourcen über dieselben Kubernetes-Schnittstellen verwalten lassen.

CSP

Fachbegriff

Die Content Security Policy (CSP) ist eine Sicherheitsregel eines Browsers, die festlegt, von welchen Quellen eine Seite Skripte und andere Inhalte laden darf.

CSS

Fachbegriff

CSS ist die Sprache, mit der das Aussehen einer Webseite festgelegt wird, etwa Farben, Abstände und Schrift.

CSV

Fachbegriff

CSV ist ein einfaches Textformat für Tabellendaten, bei dem Werte durch ein Trennzeichen wie ein Komma getrennt sind.

D

Datenanalyse

Fachbegriff

Datenanalyse bedeutet, aus gesammelten Daten Muster oder Erkenntnisse herauszuarbeiten, auf denen Entscheidungen aufbauen können.

Datenbank-Trigger

Fachbegriff

Ein Datenbank-Trigger ist eine hinterlegte Regel, die eine Datenbank automatisch ausführt, sobald ein bestimmtes Ereignis eintritt.

Datenpipeline

Fachbegriff

Eine Datenpipeline ist eine Kette automatisierter Schritte, die Daten von einer Quelle abholt, aufbereitet und an ihr Ziel weiterleitet.

DKIM

Fachbegriff

DKIM versieht ausgehende Mails mit einer digitalen Signatur, mit der sich Absender und Unversehrtheit prüfen lassen.

DMARC

Fachbegriff

DMARC legt fest, wie empfangende Server mit Mails umgehen sollen, die SPF- oder DKIM-Prüfungen einer Domain nicht bestehen.

DNS

Fachbegriff

DNS (Domain Name System) übersetzt Domainnamen in technische Adressen und weitere Einträge, etwa für Mail-Zustellung.

DNSSEC

Fachbegriff

DNSSEC versieht DNS-Einträge mit einer digitalen Signatur, damit sich gefälschte Antworten erkennen lassen.

Docker

Marke

Docker ist eine Software, mit der sich Anwendungen samt ihrer Umgebung in Containern verpacken und einheitlich betreiben lassen.

Docker Compose

Marke

Docker Compose ist ein Werkzeug, mit dem mehrere zusammengehörige Docker-Container über eine gemeinsame Konfigurationsdatei gestartet und verwaltet werden.

Domain

Fachbegriff

Eine Domain ist die eindeutige Adresse einer Website im Internet, zum Beispiel ahnenhain.de.

DOMContentLoaded

Fachbegriff

DOMContentLoaded ist der Zeitpunkt, zu dem der Browser eine Seite gelesen und ihre Skripte ausgeführt hat, auch wenn Bilder noch nachladen.

E

Embeddings

Fachbegriff

Embeddings sind Zahlenvektoren, die die Bedeutung von Text so abbilden, dass sich ähnliche Inhalte rechnerisch vergleichen lassen.

F

Flux

Marke

Flux ist ein GitOps-Werkzeug für Kubernetes, das einen Cluster fortlaufend mit dem Stand in einem Git-Repository abgleicht.

Freigabeliste

Fachbegriff

Eine Freigabeliste enthält alle Absender oder Adressen, die ausdrücklich zugelassen sind; alles andere wird automatisch abgewiesen.

Function Calling

Fachbegriff

Beim Function Calling wählt ein Sprachmodell aus einer festen Liste vorgegebener Werkzeuge aus und nennt die Parameter; ausgeführt wird das Werkzeug vom Programm, nicht vom Modell.

Funktionstest

Fachbegriff

Ein Funktionstest prüft ein System als Ganzes anhand eines echten Ablaufs, statt nur einzelne Programmteile zu betrachten.

G

Generative KI

Fachbegriff

Generative KI bezeichnet Systeme, die selbstständig neue Texte, Bilder oder anderen Inhalt erzeugen, statt nur vorhandene Daten auszuwerten.

GeoServer

Marke

GeoServer ist eine quelloffene Software, die Geodaten über Standardschnittstellen wie WFS bereitstellt.

GitHub

Marke

GitHub ist eine Plattform zur Versionsverwaltung von Code mit Git, mit Funktionen für Zusammenarbeit, Prüfungen und Automatisierung.

GitHub Actions

Marke

GitHub Actions ist eine in GitHub eingebaute Automatisierung, die bei Ereignissen im Repository, etwa einem Commit, festgelegte Abläufe wie Tests oder ein Ausrollen startet.

gitleaks

Marke

gitleaks ist ein Werkzeug, das ein Repository nach versehentlich eingecheckten Zugangsdaten und Geheimnissen durchsucht.

GitOps

Fachbegriff

GitOps ist ein Vorgehen, bei dem der gewünschte Zustand eines Systems in einem Git-Repository beschrieben wird und Änderungen darüber ausgerollt werden.

Go

Fachbegriff

Go ist eine Programmiersprache, die von Google entwickelt wurde und häufig für Server- und Infrastruktursoftware verwendet wird.

Governance

Fachbegriff

Governance sind die festgelegten Regeln und Zuständigkeiten, mit denen eine Organisation ein Thema wie Daten oder KI verantwortungsvoll steuert.

GPG

Marke

GPG (GNU Privacy Guard) ist eine Software für Verschlüsselung und digitale Signaturen, etwa um Commits nachweisbar einer Person zuzuordnen.

gzip

Fachbegriff

gzip ist ein Verfahren, das Dateien vor der Übertragung verkleinert, damit sie schneller beim Browser ankommen.

H

Handstart

Fachbegriff

Handstart heißt, dass ein Vorgang nicht automatisch beginnt, sondern erst durch einen bewussten Klick eines Menschen ausgelöst wird.

Healthcheck

Fachbegriff

Ein Healthcheck ist eine automatische, wiederkehrende Prüfung, ob ein Programm noch richtig läuft, mit automatischem Neustart, falls nicht.

Helm

Marke

Helm ist ein Paketmanager für Kubernetes, mit dem sich Anwendungen aus vorbereiteten Vorlagen installieren und verwalten lassen.

HSTS

Fachbegriff

HSTS ist eine Anweisung an den Browser, eine Website für eine bestimmte Zeit ausschließlich verschlüsselt aufzurufen.

HTML

Fachbegriff

HTML ist die Auszeichnungssprache, mit der Inhalte und Struktur einer Webseite beschrieben werden.

html-validate

Marke

html-validate ist ein Werkzeug, das HTML-Dateien gegen Regeln für gültiges und konsistentes Markup prüft.

HTTPS

Fachbegriff

HTTPS ist die verschlüsselte Variante des Webprotokolls HTTP.

Human in the Loop

Fachbegriff

Human in the Loop bezeichnet ein Vorgehen, bei dem ein Mensch Ergebnisse eines KI-Systems prüft und freigibt, bevor sie wirksam werden.

I

IBM MQ

Marke

IBM MQ ist ein Message Broker von IBM für den zuverlässigen Nachrichtenaustausch zwischen Unternehmensanwendungen.

IHK

Fachbegriff

Die IHK (Industrie- und Handelskammer) ist in Deutschland unter anderem für Prüfungen und Abschlüsse der beruflichen Ausbildung zuständig.

Infrastructure as Code

Fachbegriff

Infrastructure as Code bedeutet, Server und andere technische Ressourcen nicht von Hand einzurichten, sondern in einer Textdatei zu beschreiben, aus der sie automatisch entstehen.

IP-Adresse

Fachbegriff

Eine IP-Adresse ist die technische Anschrift eines Geräts im Internet, über die es erreichbar ist.

IRT

Fachbegriff

Item-Response-Theorie (IRT) ist ein statistisches Verfahren, mit dem eine Lernanwendung die Schwierigkeit von Fragen an den Kenntnisstand anpassen kann.

J

Java

Fachbegriff

Java ist eine weitverbreitete, objektorientierte Programmiersprache für Anwendungen auf vielen Plattformen.

JavaScript

Fachbegriff

JavaScript ist die Programmiersprache, mit der Webseiten im Browser interaktives Verhalten erhalten.

Jest

Marke

Jest ist ein Testrahmen für JavaScript, mit dem sich automatisierte Tests schreiben und ausführen lassen.

JSON

Fachbegriff

JSON ist ein textbasiertes Datenformat, das strukturierte Daten zwischen Programmen und Systemen austauscht.

K

k3s

Marke

k3s ist eine schlanke Kubernetes-Distribution, die sich auch auf einem einzelnen Server betreiben lässt.

Kafka

Marke

Apache Kafka ist eine Plattform für das Streaming von Daten, die Nachrichten zwischen Systemen zuverlässig und in großer Menge weiterleitet.

Kartenlayer

Fachbegriff

Ein Kartenlayer ist eine eigene, überlagerbare Ebene mit Informationen auf einer digitalen Karte, etwa Flächengrenzen.

KI-Agent

Fachbegriff

Ein KI-Agent ist ein Programm, das mit einem Sprachmodell Aufgaben eigenständig in mehreren Schritten bearbeitet, statt nur einzelne Anfragen zu beantworten.

KI-Einführung

Fachbegriff

KI-Einführung bezeichnet den Prozess, mit dem ein Team oder Unternehmen anfängt, KI-Werkzeuge im Alltag zu nutzen.

KI-gestützt

Fachbegriff

KI-gestützt heißt, dass eine KI bei einer Aufgabe hilft, ein Mensch aber die Ergebnisse prüft und entscheidet.

KI-Governance

Fachbegriff

KI-Governance sind die Regeln und Zuständigkeiten, die festlegen, wie ein Unternehmen KI-Systeme verantwortungsvoll einsetzt und kontrolliert.

KI-Kostenoptimierung

Fachbegriff

KI-Kostenoptimierung bedeutet, für jede Aufgabe ein möglichst günstiges, aber noch ausreichend gutes KI-Modell zu wählen, um die laufenden Kosten gering zu halten.

KI-Verordnung

Fachbegriff

Die KI-Verordnung ist ein Gesetz der Europäischen Union, das Regeln für Entwicklung und Einsatz von KI-Systemen festlegt, etwa zur Kennzeichnung von KI-erzeugten Inhalten.

KML

Fachbegriff

KML ist ein Dateiformat für Geodaten, das viele Kartenanwendungen lesen können.

Kubernetes

Marke

Kubernetes ist eine Plattform zur Orchestrierung von Containern, die deren Verteilung, Skalierung und Betrieb auf mehreren Rechnern übernimmt.

Kustomize

Marke

Kustomize ist ein Werkzeug, das Kubernetes-Konfigurationen ohne Vorlagensprache an verschiedene Umgebungen anpasst.

Kyverno

Marke

Kyverno ist eine Software für Kubernetes, die Regeln durchsetzt und eingehende Änderungen an Ressourcen vor der Übernahme prüft.

L

Leitplanken

Fachbegriff

Leitplanken sind feste Regeln und Grenzen, innerhalb derer ein KI-System oder ein KI-Agent arbeiten darf.

Lighthouse

Marke

Lighthouse ist ein Prüfwerkzeug für Websites, das Leistung, Barrierefreiheit, Best Practices und Suchmaschinentauglichkeit misst.

Lint

Fachbegriff

Lint ist ein Werkzeug, das Code automatisch auf typische Fehler und unsauberen Stil prüft, ohne ihn auszuführen.

M

Mail-Sicherheit

Fachbegriff

Mail-Sicherheit umfasst die technischen Maßnahmen, die verhindern, dass Fremde E-Mails im Namen einer Domain fälschen oder mitlesen.

MCP

Fachbegriff

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen einheitlich auf externe Werkzeuge und Datenquellen zugreifen können.

Messaging

Fachbegriff

Messaging bezeichnet den technischen Austausch von Nachrichten zwischen Programmen, meist über eine Warteschlange statt direkt.

Messenger-Bot

Fachbegriff

Ein Messenger-Bot ist ein Bot, der über einen Chat-Dienst wie Telegram oder WhatsApp Nachrichten annimmt und beantwortet.

Microsoft 365

Marke

Microsoft 365 ist ein Abonnementdienst von Microsoft mit Mail, Office-Anwendungen und weiteren Cloud-Diensten.

Monitoring

Fachbegriff

Monitoring ist die laufende, automatische Beobachtung eines Systems, um Störungen frühzeitig zu erkennen.

MVP

Fachbegriff

Ein MVP (Minimum Viable Product) ist die kleinste Fassung eines Produkts, die bereits echten Nutzen bringt und sich damit prüfen lässt.

MX

Fachbegriff

Ein MX-Eintrag ist ein DNS-Eintrag, der festlegt, welcher Server Mails für eine Domain annimmt.

N

n8n

Marke

n8n ist eine Software zur Automatisierung von Abläufen, bei der einzelne Schritte als Knoten in einem Workflow verbunden werden.

O

Offene Geodaten

Fachbegriff

Offene Geodaten sind amtliche, ortsbezogene Daten wie Flurstücksgrenzen, die Behörden frei zur Nutzung veröffentlichen.

Offline-Webanwendung

Fachbegriff

Eine Offline-Webanwendung läuft im Browser, speichert aber alles auf dem Gerät selbst und funktioniert deshalb auch ohne Netzverbindung.

OIDC

Fachbegriff

OpenID Connect (OIDC) ist ein Standard, mit dem sich eine Identität gegenüber einem Dienst nachweisen lässt, ohne ein eigenes Passwort bei ihm zu hinterlegen.

Open Food Facts

Marke

Open Food Facts ist eine offene, gemeinschaftlich gepflegte Datenbank mit Informationen zu Lebensmittelprodukten.

OpenAI

Marke

OpenAI ist ein Unternehmen, das KI-Sprachmodelle und verwandte Dienste wie Spracherkennung und Bildanalyse anbietet.

P

Passkey

Fachbegriff

Ein Passkey ist ein Anmeldeverfahren ohne Passwort, das auf einem Gerät gespeichert ist und sich nicht abfangen lässt wie ein Passwort.

Permissions-Policy

Fachbegriff

Die Permissions-Policy ist eine Browseranweisung, die einzelne Funktionen wie Kamera oder Standort für eine Seite abschaltet.

pgvector

Marke

pgvector ist eine Erweiterung für PostgreSQL, mit der sich Vektoren speichern und nach Ähnlichkeit durchsuchen lassen.

Pipeline

Fachbegriff

Eine Pipeline ist eine Kette automatisierter Schritte, etwa Prüfungen und Ausrollen, die bei jeder Änderung nacheinander laufen.

Podman

Marke

Podman ist eine Software zum Bauen und Betreiben von Containern, ähnlich wie Docker, aber ohne dauerhaft laufenden Hintergrunddienst.

PostgreSQL

Marke

PostgreSQL ist ein quelloffenes relationales Datenbanksystem, das Daten strukturiert in Tabellen speichert.

Probelauf

Fachbegriff

Ein Probelauf führt einen Vorgang testweise aus und zeigt, was passieren würde, ohne die tatsächliche Wirkung auszulösen.

Prompt Engineering

Fachbegriff

Prompt Engineering ist das gezielte Formulieren der Anweisung an ein Sprachmodell, damit es die gewünschte Antwort liefert.

Provider

Fachbegriff

Ein Provider ist ein Anbieter, der eine bestimmte Ressource oder einen Dienst bereitstellt, etwa eine Software-Komponente, die eine Cloud-Ressource verwaltet.

Pull Request

Fachbegriff

Ein Pull Request ist ein Vorschlag, eine bestimmte Codeänderung in die Hauptversion zu übernehmen, über den erst nach Prüfung entschieden wird.

Python

Fachbegriff

Python ist eine vielseitig eingesetzte Programmiersprache, unter anderem für Automatisierung, Datenanalyse und KI.

R

RabbitMQ

Marke

RabbitMQ ist ein Message Broker, der Nachrichten zwischen Systemen in Warteschlangen vermittelt.

RAG (Retrieval-Augmented Generation)

Fachbegriff

RAG heißt, dass ein Sprachmodell vor der Antwort passende Textstellen aus einer eigenen Wissensquelle nachschlägt und seine Antwort darauf stützt.

Ratenbegrenzung

Fachbegriff

Ratenbegrenzung erlaubt einem Absender nur eine begrenzte Anzahl von Anfragen in einem Zeitraum, um Missbrauch oder Überlastung zu verhindern.

RBAC

Fachbegriff

RBAC (rollenbasierte Zugriffskontrolle) vergibt Rechte an Rollen statt an einzelne Personen, denen dann Rollen zugewiesen werden.

React

Marke

React ist eine JavaScript-Bibliothek zum Bau von Benutzeroberflächen aus wiederverwendbaren Komponenten.

Referrer-Policy

Fachbegriff

Die Referrer-Policy ist eine Browseranweisung, die begrenzt, welche Adresse beim Wechsel zu einer anderen Website weitergegeben wird.

Repository

Fachbegriff

Ein Repository ist ein Ordner mit dem gesamten Code eines Projekts, in dem auch jede frühere Fassung gespeichert bleibt.

Reverse Proxy

Fachbegriff

Ein Reverse Proxy nimmt eingehende Anfragen stellvertretend entgegen und leitet sie an die passende Anwendung dahinter weiter, meist mit verschlüsselter Verbindung und Sicherheitsregeln.

Review-Agent

Fachbegriff

Ein Review-Agent ist ein KI-Agent, der Änderungen an Code unabhängig prüft, etwa auf Tests, Konfigurationsfehler und Sicherheitsprobleme. Die Freigabe bleibt bei einem Menschen.

Root

Fachbegriff

Root ist das Nutzerkonto auf einem Computer mit uneingeschränkten Rechten, das im Alltagsbetrieb bewusst vermieden wird.

Router

Fachbegriff

Ein Router ist hier ein Programmschritt, der eine eingehende Nachricht prüft und an den richtigen weiteren Schritt weiterleitet.

S

Sandbox

Fachbegriff

Eine Sandbox ist eine abgeschottete Testumgebung, in der ein Programm ausprobiert werden kann, ohne echte Daten oder Systeme zu gefährden.

Scope

Fachbegriff

Scope bezeichnet den festgelegten Umfang eines Projekts, also was ausdrücklich dazugehört und was nicht.

Scrum

Fachbegriff

Scrum ist ein Vorgehensmodell für Projekte, das Arbeit in festen, kurzen Zeitabschnitten mit klaren Rollen und Ritualen organisiert.

Secrets Management

Fachbegriff

Secrets Management ist der sichere, geregelte Umgang mit Passwörtern, Schlüsseln und anderen Zugangsdaten, damit sie nicht offen einsehbar sind.

Self-Service

Fachbegriff

Self-Service heißt, dass Nutzerinnen und Nutzer eine Ressource selbst über ein Formular oder Werkzeug anfordern können, ohne dass eine andere Abteilung sie manuell einrichten muss.

SEO

Fachbegriff

SEO (Suchmaschinenoptimierung) sind Maßnahmen, die eine Website in den Ergebnissen von Suchmaschinen wie Google besser auffindbar machen.

ShellCheck

Marke

ShellCheck ist ein Werkzeug, das Shell-Skripte auf typische Fehler und unsichere Muster prüft.

Sicherheitsheader

Fachbegriff

Sicherheitsheader sind zusätzliche Anweisungen, die eine Website beim Aufruf an den Browser mitsendet, um bestimmte Angriffe zu verhindern.

SOPS

Marke

SOPS verschlüsselt Geheimnisse in Konfigurationsdateien, sodass sie sicher in einem Git-Repository liegen können. Als Schlüsselverfahren dient dabei oft age, ein schlankes Verschlüsselungswerkzeug.

SPF

Fachbegriff

SPF ist ein DNS-Eintrag, der festlegt, welche Server im Namen einer Domain Mails versenden dürfen.

Sprachmodell

Fachbegriff

Ein Sprachmodell ist ein KI-System, das auf großen Textmengen trainiert wurde und Sprache versteht, erzeugt und einordnet.

SQL

Fachbegriff

SQL ist die Abfragesprache, mit der Daten in relationalen Datenbanken gelesen und verändert werden.

SSH

Fachbegriff

SSH ist ein Protokoll für verschlüsselte Verbindungen zwischen Rechnern, etwa für Fernzugriff oder signierte Commits.

SSH-Tunnel

Fachbegriff

Ein SSH-Tunnel ist eine verschlüsselte Verbindung, durch die sich ein System aus der Ferne sicher erreichen lässt, ohne es offen ins Internet zu stellen.

Statische Analyse

Fachbegriff

Statische Analyse prüft den Code automatisch auf typische Fehler und verdächtige Muster, ohne ihn dafür auszuführen.

Stockkarte

Fachbegriff

Eine Stockkarte ist die Karteikarte oder digitale Aufzeichnung zu einem einzelnen Bienenvolk, etwa zu Fütterung und Gesundheit.

Streaming

Fachbegriff

Streaming bedeutet hier, dass Daten fortlaufend in kleinen Einheiten verarbeitet werden, statt zu warten, bis alle Daten vollständig vorliegen.

T

Tailscale

Marke

Tailscale ist eine Software, die Geräte über ein privates, verschlüsseltes Netzwerk miteinander verbindet.

Telegram Bot API

Marke

Die Telegram Bot API ist eine Programmierschnittstelle des Messengers Telegram, über die sich automatisierte Konten mit Chats verbinden lassen.

TLS

Fachbegriff

TLS ist das Protokoll, das Verbindungen im Web verschlüsselt und so HTTPS ermöglicht.

Token

Fachbegriff

Ein Token ist ein zeitlich begrenzter digitaler Ausweis, mit dem sich ein Programm gegenüber einem anderen System ausweist, ohne ein dauerhaftes Passwort zu speichern.

Toolfreigabe

Fachbegriff

Eine Toolfreigabe legt fest, welche einzelnen Werkzeuge ein KI-Agent verwenden darf, statt ihm uneingeschränkten Zugriff zu geben.

transferSize

Fachbegriff

transferSize ist ein Messwert des Browsers für die tatsächlich über das Netz übertragene Datenmenge einer Datei, einschließlich Kopfzeilen.

TypeScript

Marke

TypeScript ist eine Programmiersprache, die JavaScript um Typen erweitert und vor der Ausführung in JavaScript übersetzt wird.

U

Unit-Test

Fachbegriff

Ein Unit-Test prüft automatisch, ob ein einzelner, kleiner Teil eines Programms genau das tut, was er soll.

Uptime Kuma

Marke

Uptime Kuma ist eine quelloffene Software, die die Erreichbarkeit von Diensten überwacht und bei Ausfällen alarmiert.

V

Vektordatenbank

Fachbegriff

Eine Vektordatenbank speichert Inhalte als Zahlenvektoren und findet dazu ähnliche Einträge, statt nach exakten Übereinstimmungen zu suchen.

Vertraulichkeitsklasse

Fachbegriff

Eine Vertraulichkeitsklasse stuft Daten danach ein, wie sensibel sie sind, und legt damit fest, wer oder was sie sehen darf.

W

Webhook

Fachbegriff

Ein Webhook ist eine Adresse, an die ein Dienst automatisch eine Nachricht schickt, sobald ein bestimmtes Ereignis eintritt.

WFS

Fachbegriff

WFS (Web Feature Service) ist eine standardisierte Schnittstelle, über die sich Geodaten wie Flurstücke von einem Server abfragen lassen.

Whisper

Marke

Whisper ist ein Modell von OpenAI, das gesprochene Sprache in Text umwandelt.

Wissenstransfer

Fachbegriff

Wissenstransfer bedeutet, Fachwissen gezielt an andere Personen weiterzugeben, damit es nicht an eine einzelne Person gebunden bleibt.

Workflow

Fachbegriff

Ein Workflow ist eine festgelegte Abfolge von Schritten, mit der ein Vorgang automatisiert oder strukturiert abläuft.

Workflow-Design

Fachbegriff

Workflow-Design ist die Tätigkeit, die einzelnen Schritte eines Workflows so zu planen, dass sie zuverlässig und nachvollziehbar zusammenwirken.

Workload Identity Federation

Fachbegriff

Workload Identity Federation lässt eine Anwendung ihre Identität aus der Betriebsumgebung ableiten und gegen kurzlebige Tokens eintauschen, statt dauerhafte Zugangsschlüssel zu speichern.

X

X-Content-Type-Options

Fachbegriff

X-Content-Type-Options ist eine Browseranweisung, die verhindert, dass eine Datei als ein anderer, gefährlicherer Dateityp behandelt wird.

X-Frame-Options

Fachbegriff

X-Frame-Options ist eine Browseranweisung, die verhindert, dass eine Seite unsichtbar in eine fremde Seite eingebettet wird.

xAI Grok

Marke

Grok ist ein KI-Sprachmodell des Unternehmens xAI.

Y

YAML

Fachbegriff

YAML ist ein für Menschen gut lesbares Textformat, das häufig für Konfigurationsdateien verwendet wird.

Z

Zugriffsprotokoll

Fachbegriff

Ein Zugriffsprotokoll zeichnet auf, wer oder was wann auf ein System zugegriffen hat, damit sich ungewöhnliche Versuche nachträglich erkennen lassen.

Zwei-Faktor

Fachbegriff

Zwei-Faktor-Sicherung verlangt beim Anmelden zusätzlich zum Passwort einen zweiten Nachweis, etwa einen Code auf dem Handy.

Zweitdomain

Fachbegriff

Eine Zweitdomain ist eine zusätzliche, selbst nicht genutzte Adresse, die absichtlich gegen Mail-Fälschung gesperrt wird, damit niemand in ihrem Namen Nachrichten verschickt.

Ahnenhain Systems · Julius C. Gnädig

AI Engineer · agentic automation, built to run safely

AI agents and automation for production use.

I set up AI agents for small businesses, clubs, and teams: self-hosted, tested, and signed off by a person. The foundation is platform engineering and operations: Kubernetes, automation, security.

I have worked with generative AI daily since 2022 and with my own AI workflows since 2023.

Request a conversationView case studies

How this site gets built

The real workflow, simplified

  1. PlanA planning model splits the work into tasks and writes a separate assignment for each.
  2. BuildSeveral coding agents (Claude Code) work in parallel. Each delivers its task as a pull request.
  3. ChecksOn every pull request, GitHub Actions builds the site from source and checks the site and the repository. Independent review agents check the change as well.
  4. MeasurementLighthouse, axe-core, and Playwright measure performance, accessibility, overflow, third-party requests, and size.
  5. ApprovalI review the result and merge it. Nothing goes live without my approval.
  6. LiveOnly then does the change appear on the site.

What I build with

How this site is built

How it works

Four steps, from the first conversation to a running system.

  1. Intro call

    20 minutes, free

    We talk through what takes your time and whether an agent is a fit.

  2. Assessment

    A report you keep

    The written report shows where an agent helps, where it does not, and who signs off.

  3. Implementation

    Fixed price, tested

    I set up the system and test it before rollout. A person signs off.

  4. Handover

    Runs on your side, with training

    The system runs on your side, not mine. I walk you and your team through it.

Case studies

Architecture, decisions, operations.

  1. No. 01

    Self-hosted: data and logic

    Symbiont

    Messenger input, AI as interpreter, human confirmation.

    Status
    In daily use
  2. No. 02

    Automation for my own needs

    Farming and beekeeping

    Hive record and parcels from open geodata.

    Status
    Prototype in my own use
  3. No. 03

    Verifiable from outside

    Company IT and this website

    Mail security, verification pipeline. Much of it can be checked with public tools.

    Status
    Live since September 2026

All projects

Currently working on

What is in use and what I am building right now.

Status: In use

Agents build, checks decide, I approve

Several AI agents build in parallel, automated checks measure every version, and nothing is published until I approve it. Overnight too: agents work through a bug list on their own branches, and nothing ships until I approve it the next day.

Stack Claude Code · Playwright · Lighthouse · axe-core · Python

Status: In use

Questions about my own documentation, with sources

A messenger bot answers questions about my own project documentation, redacted beforehand, using a hybrid of full-text and vector search. The answer names its sources, the evidence is checked in code, and statements about production are marked as such.

Stack PostgreSQL · pgvector · hybrid search · evidence check · Telegram bot

Read the Symbiont case study

Status: In use

My own development platform with GitOps and review agents

Symbiont is developed on my own Kubernetes cluster, reachable only on a private network. After approval the cluster pulls the new state itself. Independent review agents check every change. Only what I have approved reaches main, and the same applies to production.

Stack Kubernetes (k3s) · Flux · GitOps · Kustomize · SOPS/age · GitHub Actions · container registry

Status: In use

An archive that outlasts AI conversations

Results from AI conversations go into a single archive with a visible version number, a completeness check, setting aside instead of deleting, and a one-way backup to a second drive. New conversations continue from this archive.

Stack Python · Markdown · Version scheme · Check scripts

Status: Prototype

Local models with tool calls

An orchestrator agent routes requests to specialized sub-agents. Their tools are described in a registry and called through web requests, for example to an open data API; the models run locally.

Stack TypeScript · Node.js/Express · Ollama · Open WebUI · Docker

Status: In preparation

First paper: human-AI symbiosis from long-term practice

A position paper on a long-standing working partnership with AI, written from the inside and based on records from my own system. Three principles turn tool use into symbiosis: validation, auditability, self-improvement.

Format Position paper · case study (N = 1) · English

Go to Publications

Status: In use

Questions about my own data with fixed tools

A language model answers questions about my own nutrition data, choosing only from fixed, read-only tools, such as daily totals or averages. It never writes SQL itself, and whose data is queried is decided by the code, not the model.

Stack function calling · PostgreSQL · Telegram bot

Status: In progress

Document brain: scan mail, understand it locally, answer with provenance

Paper mail is scanned with a phone and processed on a small computer at home, with personal details pseudonymized first. A local language model answers through the messenger and always cites its sources, tested so far with synthetic letters.

Stack Raspberry Pi · PostgreSQL · pgvector · Graph (relational, Apache AGE optional) · local language model · n8n

Worked-out case studies are under Projects. All projects

Who it is for

Three typical starting points. In each, a person reviews and approves.

  • Small businesses and trades

    ExampleAppointment requests by email or voice message are read, sorted, and prepared as a draft reply.

    Reviews and approvesYou, before any reply goes out.

    View proposed architecture

  • Clubs and nonprofits

    ExampleFrom your notes, the agent drafts the member mailing, such as a rehearsal date change.

    Reviews and approvesA member of the board reads and approves every text.

    View proposed architecture

  • Teams and freelancers

    ExampleOpen quotes are spotted and the follow-up is prepared as a draft.

    Reviews and approvesThe person who made the quote reads the draft and sends it themselves.

    View proposed architecture

Where does an agent pay off?

Five questions about one task from your day. The assessment is calculated in your browser. Nothing is sent and nothing is stored.

The five questions

  1. How often does the task come up? Several times a day · Daily or several times a week · About once a month · Rarely or once
  2. How long does one run take? More than two hours · 30 minutes to two hours · 5 to 30 minutes · Under 5 minutes
  3. How structured is the input? Fixed layout, such as forms or tables · Mostly uniform, with exceptions · Mixed, such as emails and PDFs from many sources · Free-form or only in someone’s head
  4. What does a mistake cost? Little: it gets noticed and is quickly fixed · Noticeable: rework or friction · High: money, contracts or customer trust · Severe: legal, safety or irreversible
  5. Who can review and approve the result? A knowledgeable person, quickly · Someone, but it takes time · Spot checks only · Nobody, the result goes straight out

Without JavaScript, the rule of thumb is: the more frequent and time-consuming the task, the more fixed the input and the better someone can review the result, the more an agent pays off. If a mistake is costly and nobody reviews, it does not.

Pricing

You know the cost before we start.

Intro call20 minutes
free
AI assessment90 minutes plus written report
€450
Team workshop “AI in Daily Work”Half day, up to 8 people
€1,490
Implementation packageFixed price after the assessment
from €1,950
Hourly consultingBilled in 30-minute incrementsIntroductory rate through December 31, 2026
€115 per hour
TalkConference, club, or team, on site or onlinePlus €50 per hour for confidential client material. Plus travel at cost. Preparation is billed only if I may not reuse the material. For nonprofit clubs and organizations, available for a small expense fee.
€150 per hour of talk time

Prices are in euros (EUR). No VAT is charged under the German small business exemption (Section 19 of the German VAT Act, UStG). Send your request for hourly consulting or a talk through the callback form.

Frequently asked questions

Where does the system run?

On your side, not mine. I set it up there and hand it over with training. The case studies show self-hosted systems in detail.

To the case studies

What happens to my data?

The confidentiality class of the data decides which model may see it. I process clients’ personal, health, and biometric data only with a documented data protection plan and a data processing agreement. This site sets no cookies and makes no requests to third-party servers.

Guardrails in detail

What does it cost?

The intro call is free. The assessment costs €450, the team workshop €1,490. An implementation package starts at €1,950 and is quoted as a fixed price after the assessment. Hourly consulting costs €115 per hour (introductory rate through December 31, 2026), billed in 30-minute increments. A talk costs €150 per hour of talk time, plus €50 per hour if it draws on the client’s confidential material (your own company examples, nondisclosure). Travel is billed at cost, and online talks carry no travel charge. I charge for preparation only if I may not reuse the talk material myself, then at the consulting rate of €115 per hour in 30-minute increments. For nonprofit clubs and organizations, a talk is possible for a small expense fee. Please get in touch. Send your request through the callback form. All prices are final: no VAT is charged under the German small business rule (Section 19 of the German VAT Act).

To the price list

What do I not build, or only with limits?

No systems that select job applicants or make personnel decisions, and no credit scoring. Analysis of employee performance or behavior only after a prior legal review.

To how I work

Who is responsible if the agent gets it wrong?

The person who signs off. The AI drafts, a person reviews and approves before anything takes effect. For Symbiont and this website, independent review agents also check every change. Agents get only the access the current step needs, and every failure becomes a rule or a test.

Who does what

What do I need up front?

A question or a problem is enough. In the intro call we use 20 minutes to find out what is on your mind and whether an agent is a fit. Everything else follows from the assessment.

Request a conversation

How can I see that you can do this?

The three case studies show architecture and decisions, and Symbiont also shows incidents and the rules that came out of them. This site is evidence in itself: measurements, security headers, and tools are published openly on the page “How this site is built”.

How this site is built

In 20 minutes we find out whether an agent makes sense for you. Free of charge.

Request a conversation

Contact

By email or phone, in German or English.

Open spots: 1 of 2

Open knot: available. Closed knot: taken.

Email
info@ahnenhain.de
Phone
+49 160 2495853
LinkedIn
Julius C. Gnädig (opens an external site)

Request a conversation

Your details go to me by email only and are not stored on the server. More in the privacy policy (in German). All times Central European Time.

Projects

The three case studies grew out of my own needs, and I use them myself. The further projects show what else I have designed, tested, and built. The standard is the same throughout: solutions that work and can be traced.

SymbiontFarmingCompany ITWorkload IdentityCouncil of AgentsGitOpsfixed toolsSuccess ForgeLearning toolsAI content labelingServer room

11 projects · 3 case studies · 8 more

Each node opens its project. Lines connect projects that share a technology or topic.

Case studies

  1. No. 01

    Case study · Self-hosted: data and logic

    Symbiont

    An AI system for everyday life, run like a small production system.

    Symbiont is my AI system for everyday data. It grew out of the idea of running my own life with a system that learns from my own data. Data and logic are self-hosted; I call the language models at external providers. Text, a voice message, or a photo arrives through a messenger and a language model turns it into a structured entry. Fixed rules check every proposal; when it is ambiguous, I confirm with a button. Run like a production system, developed with specialized Claude agents. Alongside it runs my own development platform on Kubernetes.

    No. 01In daily use

    Role
    Idea, architecture, operations, development with agents
    Since
    Idea 2022, architecture concept late 2025, in daily use since 2026
    Core
    n8n, PostgreSQL with pgvector, language models, Docker
  2. No. 02

    Case study · automation for my own needs

    Farming and beekeeping

    A hive record and land parcels from open geodata, built as modules that run on the farm.

    Bee colonies at several apiaries and forested parcels need managing, and until now that was done on paper. I built a digital hive record and turned the parcels from open geodata into a map layer, both as modules for the farm.

    No. 02Prototype in my own use

    Role
    Need, concept, AI-assisted build, own use
    Since
    July 2026 (parcels), September 2026 (hive record)
    Core
    offline web app, WFS, KML
  3. No. 03

    Case study · verifiable from outside

    Company IT and this website

    Small, but built the way I would recommend to a client.

    In September 2026 I built Ahnenhain Systems’ IT from scratch: mail with proper sender authentication, a secondary domain locked against spoofing, this website with no cookies or third-party requests, a private repository with signed commits and a verification pipeline. Claude prepared, I reviewed and approved; much of it you can check with public tools.

    No. 03Live since September 2026

    Role
    Planning, build with Claude, sign-off
    Since
    September 2026
    Core
    Microsoft 365, DNS, GitHub Actions, static HTML

More projects

  • 2026tested

    Workload Identity Federation for AI on Kubernetes

    AI services access resources without stored keys: identity comes from the cluster, and short-lived tokens replace long-lived secrets. Built on my own demo cluster and tested automatically in CI.

    Kubernetes · OIDC · Workload Identity Federation

    • Kubernetes
    • Security
    • Agents

  • prototype

    Council of Agents

    Several AI agents with different roles debate a question in a structured way, and a final step merges their positions into a recommendation. Roles and modes are set in configuration. A custom skill generates the agents’ roles and personalities from a description.

    n8n · xAI Grok · YAML configuration · web search · Docker

    • Agents
    • n8n
    • Self-hosted

  • 2026in use

    My own development platform with GitOps and review agents

    Symbiont is developed on my own Kubernetes cluster, reachable only on a private network. Everything is rolled out through GitOps: every change is a pull request, and after approval the cluster pulls the new state itself. Secrets are stored encrypted in the repository. Independent review agents check every pull request. Only what I have approved reaches main, and the same applies to production.

    Kubernetes (k3s) · Flux · Kustomize · SOPS/age · GitHub Actions

    • Kubernetes
    • Agents
    • Security

  • 2026in use

    Questions about my own data with fixed tools

    A language model answers questions about my own nutrition data, choosing only from fixed, read-only tools, such as daily totals or averages. It never writes SQL itself, and whose data is queried is decided by the code, not the model.

    Function calling · PostgreSQL · Telegram bot

    • Agents
    • Data

  • in my own useprototype

    Success Forge

    AI-assisted goal management with a decision compass across several areas of life. Guiding idea: the AI supports decisions without making them for you, and guards against over-automation.

    n8n · PostgreSQL

    • Agents
    • n8n
    • Data

  • 2026completed

    Interactive learning tools

    Learning tools that help others get up to speed on new AI tools themselves: a learning path for an AI workspace, one with audio narration on remote-controlling AI sessions, and a trainer that adapts difficulty to the learner’s level.

    React · text to speech · adaptive testing (IRT)

    • Enablement
    • Agents

  • 2026completed

    One-pager on AI content labeling

    A guide for businesses on when and how AI-generated content must be labeled under Article 50 of the EU AI Act, on a single page (in German).

    Research · guide for businesses in the EU

    • Enablement

  • Apprenticeship 2023completed

    Server room monitoring with a microcontroller

    Apprenticeship project: monitoring a server room with sensors and a microcontroller, organized, documented and presented as a team using Scrum.

    Arduino · sensors · Scrum

    • IoT

Working on something similar?

Request a conversation

Case study · Self-hosted: data and logic

Symbiont

An AI system for everyday life, run like a small production system.

No. 01In daily use

Role
Idea, architecture, operations, development with agents
Since
Idea 2022, architecture concept late 2025, in daily use since 2026
Core
n8n, PostgreSQL with pgvector, language models, Docker

Summary

Symbiont is my AI system for everyday data. It grew out of the idea of running my own life with a system that learns from my own data. Data and logic are self-hosted; I call the language models at external providers. Text, a voice message, or a photo arrives through a messenger and a language model turns it into a structured entry. Fixed rules check every proposal; when it is ambiguous, I confirm with a button. Run like a production system, developed with specialized Claude agents. Alongside it runs my own development platform on Kubernetes.

Starting point

I wanted to record nutrition, training, and other everyday data in one place, without handing it to someone else’s platform. Instead of forms and a vendor account: send a message or a photo, and the system does the rest. Data and logic run on my server. For speech, images, and text understanding I use external models, and messages arrive through a messenger.

Goals and constraints

  1. Data ownership: data and logic on my own server, no platform lock-in; external models only for speech, images, and text understanding.
  2. Input as easy as a message; buttons instead of forms.
  3. The AI may interpret but not decide silently: proposals must be checkable and correctable.
  4. One user, daily use: reliability before features.
  5. Model calls cost money per request; cost is part of every decision.
  6. Run in my spare time: failures have to announce themselves instead of waiting to be found.

Architecture

A message always takes the same path: input, interpretation by a model, checks by fixed rules, confirmation by a human, storage. Operations and development are separate layers with their own alert channel. Alongside them sits a development platform.

Select a component. Its description appears alongside and its data flows are highlighted.

Read the architecture as a list

No component selected.

Read the architecture as a list

Symbiont architecture as text. Messenger bots send messages and photos over HTTPS to a reverse proxy that exposes only the necessary endpoints. An n8n router checks the sender and the rate, then routes: voice becomes text, photos go to image analysis, free text goes to a language model for structured proposals. Deterministic guards check date, year, and plausibility; the system matches known input against past entries and an open product database. The human confirms, corrects, or discards anything ambiguous with a button; only then does PostgreSQL with pgvector store it. Nightly workflows cross-check totals, and a second model writes summaries in parallel. In development, Claude agents with fixed roles work on feature branches; I approve the plan, review, and merge before a pipeline checks it prior to deployment. Backups and monitoring work as described under Operations.

  1. Input

    1. Messenger bots in production

      Entry point for text, voice messages, photos, and buttons.

      Outgoing:

    2. Reverse proxy (Caddy) in production

      Terminates TLS, sets security headers, lets only the necessary endpoints through from outside.

      Outgoing:

  2. Orchestration

    1. Commands and buttons in production

      Status, undo, reports, corrections.

      Outgoing:

    2. Router workflow (n8n) in production

      Checks the sender and the rate, routes the input to the right path.

      Outgoing:

  3. AI and rules

    1. Speech to text in production

      Turns the voice message into text.

      Outgoing:

    2. Language model as interpreter in production

      Breaks free-form language into structured entries; proposes, does not decide.

      Outgoing:

    3. Image analysis in production

      Recognizes products and amounts in photos and returns a proposal.

      Outgoing:

    4. Summaries (second model) in production

      Writes daily and weekly summaries, in parallel to the reply.

      Outgoing:

    5. Deterministic guards in production

      Fixed rules check every proposal for date, year, and plausibility; missing values are flagged.

      Outgoing:

    6. Matching against known items in production

      Searches the user’s own entries, then an open product database.

      Outgoing:

  4. Human

    1. Human confirmation

      Anything ambiguous appears as a proposal with confirm, correct, or discard.

      Outgoing:

  5. Data

    1. PostgreSQL with pgvector in production

      Holds entries, totals, and vectors for similarity search, with no port exposed.

      Outgoing:

    2. Scheduled workflows in production

      Nightly aggregation, cross-check of totals, reminders.

      Outgoing:

  6. Operations

    1. Encrypted backup in production

      Backed up daily, encrypted, with an off-site copy; restore has been tested.

    2. Monitoring in production

      Container health, availability, host metrics.

      Outgoing:

    3. System bot in production

      One channel for everything operational: deployments, errors, monitoring.

  7. Development

    1. Me (developer)

      Writes the brief, approves the plan, reviews and merges.

      Outgoing:

    2. Claude agents with roles in use

      Specialized agents implement, look for flaws, and review security and tests.

      Outgoing:

    3. Repository with verification pipeline in use

      Workflows as JSON, versioned. Before deployment: analysis, lint, tests, secret scanning.

      Outgoing:

    4. Deployment in use

      Through an SSH tunnel with a dedicated non-root user; webhooks are checked afterwards.

      Outgoing:

Back to the diagram

Decisions

In the style of architecture decision records: context, decision, trade-off, consequence.

Decision 01Self-host data and logic instead of using a platform
Context
Personal everyday data is sensitive; off-the-shelf services store it with the vendor.
Decision
Own Linux server with Docker Compose, images pinned to fixed versions.
Trade-off
Security and updates are my job instead of a platform’s.
Consequence
Hardening as a phase of its own: firewall, two-factor authentication, encrypted backups with a restore test.
Decision 02n8n for orchestration
Context
Many input channels, many small flows, frequent changes in daily use.
Decision
Flows as n8n workflows, versioned as JSON and deployed by a pipeline.
Trade-off
Logic inside workflow nodes is hard to test.
Consequence
Custom lint rules; testable logic moves into modules with unit tests.
Decision 03AI interprets, rules set limits, a human confirms
Context
Language models return plausible but wrong values: a date in the future, the wrong year.
Decision
Model output is always a structured proposal, checked by deterministic guards.
Trade-off
One more tap in daily use; known input goes straight through and can be undone.
Consequence
Model errors do not end up silently in the data; missing values stay visible.
Decision 04PostgreSQL with pgvector instead of a separate vector database
Context
Matching against past entries needs similarity search; everything else is relational data.
Decision
One database for both: tables, JSONB and a vector index in PostgreSQL.
Trade-off
Fewer specialized features than a dedicated vector database.
Consequence
One backup, one schema; all user input goes through parameterized queries only.
Decision 05Development with agents and fixed review tiers
Context
A single agent misses the same things a single person does.
Decision
Specialized agents with roles, a plan before every step, a review tier based on risk.
Trade-off
More model calls and more to read.
Consequence
Flaws are found before deployment, and every decision can be traced later.

Human in the loop

Exactly where a human signs off:

  • Multi-item or ambiguous input and photos: the system shows a proposal with confirm, correct, or discard. Nothing is stored before that confirmation.
  • Known, unambiguous input goes straight through. Each entry can be undone from the interface.
  • The model’s summaries and hints are suggestions. Decisions about nutrition and training are mine.
  • Development: no agent implements anything before I have read and approved the plan. Overnight agent runs work on feature branches; merging and deployment happen after my review.
  • Data corrections in production only with a backup first and a dry run that is rolled back.
  • After every deployment, a real functional test: a real message, a real reply.

Operations and quality

  • Containers with pinned versions, resource limits, health checks and automatic restart.
  • Only the necessary endpoints are reachable from outside; administration only through approved access, additionally with two-factor authentication.
  • Sender allow list, rate limiting, and access log with an alert on unauthorized attempts.
  • All user input reaches SQL only as parameters; a lint rule prevents regressions.
  • Pipeline before every deployment: static analysis, lint rules, syntax checks, unit tests, ShellCheck. Secret scanning already before each commit.
  • Deployment through an SSH tunnel with a dedicated non-root user, followed by a webhook check and a report to the system bot.
  • Daily encrypted backup of database and workflow data, off-site copy, restore tested.
  • Nightly cross-check of daily totals against single entries; discrepancies raise an alert.
  • Credentials live in n8n’s encrypted store, not in the repository. Error messages are stripped of tokens and database details before they are sent.

Development platform

The development platform is running. Production works as described under Operations and quality.

  • My own server as a development cluster on Kubernetes, reachable only on the private network, not public.
  • GitOps with Flux: every change is a pull request, and after approval the cluster pulls the new state itself.
  • Secrets are stored encrypted in the repository (SOPS with age).
  • Images are built on every commit and stored in a private registry.
  • Tasks are tracked as issues. For each task, a visible coding-agent session builds a pull request.
  • Independent review agents then check every pull request: tests, manifest validation, a search for secrets and hostnames, and security. Only what I have approved reaches main and the cluster. The same applies to production.
  • The same pattern builds this website.

Select a component. Its description appears alongside and its data flows are highlighted.

Read the architecture as a list

No component selected.

Read the architecture as a list

On the development platform, my own Kubernetes cluster on the private network only, GitOps with Flux rolls out approved pull requests; secrets are stored encrypted in the repository, and images are built on every commit and kept in a private registry. Coding agents build pull requests, independent review agents check them, and only what I have approved reaches main and the cluster. An operations bot and a monitoring page only read the cluster.

  1. Development platform

    1. Monitoring page running in development

      Read-only monitoring of the cluster, only on the private network.

      Outgoing:

    2. Coding and review agents running in development

      For each task a visible session builds a pull request, and independent review agents check it. Only what I approve reaches main.

      Outgoing:

    3. Encrypted secrets (SOPS, age) running in development

      Secrets are stored encrypted in the repository.

      Outgoing:

    4. GitOps (Flux) running in development

      Every change is a pull request; after approval the cluster pulls the new state itself.

      Outgoing:

    5. Build per commit, private registry running in development

      Images are built on every commit and stored in a private registry.

      Outgoing:

    6. Operations bot running in development

      Reports incidents and answers questions about status, read-only; no write access to the cluster.

      Outgoing:

    7. Development cluster (Kubernetes) running in development

      My own server, reachable only on the private network, not public.

Back to the diagram

Further capabilities

What the platform and operations additionally provide, and how it is secured:

  • Questions about my own documentation, asked in the messenger. A hybrid search (vector plus full text) runs over the project documentation, redacted beforehand. The answer cites its sources, evidence is verified in code, and statements about production are labeled as such.
  • Questions about my own nutrition data. The language model only chooses from fixed, read-only tools, such as daily totals and averages. It never writes SQL itself, and whose data is queried is decided by the code, not the model.
  • An operations bot for the cluster reports incidents on its own and answers questions about status through read-only tools (cluster, code repositories, documentation). It has no write access to the cluster.
  • A read-only monitoring page for the cluster, reachable only on the private network.
  • The training module runs as a service of its own (TypeScript, with extensive automated tests against a real database) and replaces the previous workflow solution on the development platform.

Incidents and the rules derived from them

Symbiont runs every day, so it has real faults and outages. I write each one up as an incident: what happened, the cause, and the rule that prevents it. A selection, including some from development.

  1. Incident 01Green does not mean healthy
    What happened
    After a deployment the bots went silent, even though the pipeline was green and every container healthy.
    Cause
    A logging step overwrote the data the next step relied on: the infrastructure was fine, the application was not.
    What I built from it
    A mandatory functional test after every deployment, plus a written rule for explicit references between workflow steps.
  2. Incident 02The night that erased the totals
    What happened
    The nightly aggregation overwrote correct daily totals with zero; by morning the status showed nothing.
    Cause
    Several components read the same values, one of them from the wrong place in the JSON. The nightly cross-check had detected the discrepancy, but its alert was never delivered.
    What I built from it
    One consistent read path, a repaired alert chain, and an aggregation that recomputes past days and so heals itself.
  3. Incident 03Daylight saving time in many places
    What happened
    In summer, entries were off by an hour. The first fix only covered the reported spot; I noticed the same pattern elsewhere.
    Cause
    A hard-coded winter-time offset, copied into JavaScript and SQL across several workflows.
    What I built from it
    The rule: search for the pattern end to end, fix every instance. One central time module, plus guards against wrong model-supplied dates.
  4. Incident 04When the cache learns mistakes
    What happened
    Wrong model estimates ended up in the cache and were served again for the next identical input.
    Cause
    Model output was reused without being checked.
    What I built from it
    A verifier outside the reply path re-checks stored values with a second model call.
  5. Incident 05The data loss that wasn’t
    What happened
    Gaps in record IDs looked like silent data loss; the first analysis confirmed the suspicion.
    Cause
    A closer investigation refuted that: the gaps came from intentional deletions via cancel and undo.
    What I built from it
    A deletion log via database trigger; refuted findings stay in the documentation, marked as refuted, instead of disappearing.
  6. Incident 06Fix the automation, don’t bypass it
    What happened
    Automatic deployment failed silently. The agent suggested deploying by hand. I said no.
    Cause
    A shallow checkout could not compare changes, and the error was swallowed.
    What I built from it
    Full checkout, a manual trigger for a full deployment. And the rule: faulty automation is repaired, not bypassed.
  7. Incident 07The bug list, overnight
    What happened
    A list of open bugs had been sitting longer than it should. Overnight, agents worked through it, each bug on its own branch with its own checks.
    Cause
    The bugs were not the problem; the problem was that fixing and approving depended on the same person on the same day.
    What I built from it
    Agents may fix and test at night. Nothing ships until I have approved it the next day.
  8. Incident 08One dollar sign too few
    What happened
    A check job after a database migration failed in the cluster, although it had worked without Kubernetes. The same flaw sat in a second job and was fixed there before rollout.
    Cause
    Kubernetes replaces $$ with $ in container commands, so the commands differed from how they were written.
    What I built from it
    $$ is escaped or replaced by named delimiters. The rule: whatever the platform rewrites in commands belongs in the tests.
  9. Incident 09File names as links
    What happened
    In replies, Telegram turned file names ending in .md into links to unrelated websites.
    Cause
    Telegram read the file names as web addresses, because .md is a country domain.
    What I built from it
    File names are formatted as code and link previews are off. The rule: language model output is display data and is shaped before it is sent.

Rules that came out of it

  1. A plan before every step, checked against the actual state of the repository.
  2. Review tier by risk; security changes only with a test and an in-depth review.
  3. A backup without a restore test is not a backup.
  4. Before creating a secret, check whether the name is already in use.
  5. Least privilege by default: never as root, always through a dedicated deploy user.
  6. Nothing is created directly on the server. Repository first, then deploy.
  7. Triage review findings one by one; defer only with a reason.
  8. Whatever the platform rewrites in commands belongs in the tests.
  9. Language model output is display data and is shaped before it is sent.

Stack

Status

In daily use.

This page deliberately shows no measurements and no personal data from the system.

Case study · automation for my own needs

Farming and beekeeping

A hive record and land parcels from open geodata, built as modules that run on the farm.

No. 02Prototype in my own use

Role
Need, concept, AI-assisted build, own use
Since
July 2026 (parcels), September 2026 (hive record)
Core
offline web app, WFS, KML

Summary

Bee colonies at several apiaries and forested parcels need managing, and until now that was done on paper. I built a digital hive record and turned the parcels from open geodata into a map layer, both as modules for the farm.

Starting point

My family keeps bees and manages land. Who fed how much and when, how high the mite drop was, and exactly where a parcel ends lived on paper or in people’s heads, often with no reliable signal at the apiary.

Goals and constraints

  1. Record at the apiary in a few taps, even without a signal.
  2. The data belongs to the farm and stays readable in open formats.
  3. No false confidence: what has not been measured does not count as done.
  4. The modules run on the farm, not with me: short setup, no ongoing service afterwards.

Architecture

Two modules: the hive record for work at the apiary, and parcels from open geodata.

Select a component. Its description appears alongside and its data flows are highlighted.

Read the architecture as a list

No component selected.

Read the architecture as a list

Architecture as text. At the apiary, the beekeeper records an entry per colony in the hive record on a phone, a single-file web app that saves on the device immediately and so works without a network. The data stays on the device. Evaluation rules convert feed into sugar equivalent against a target per colony, calculate mite drop per day, and count days since the sticky board went in; the result returns as an overview. An export produces CSV and JSON as a backup. Separately, official cadastral parcel data is queried through WFS, converted to KML, and shown as a map layer.

  1. Human

    1. Beekeeper at the apiary

      Records what happens at each colony and decides on feeding, treatment and harvest.

      Outgoing:

  2. Capture

    1. Hive record on the phone prototype

      Web app in a single file: apiaries, colonies, and entries such as feeding, weighing, varroa check, treatment, and harvest.

      Outgoing:

    2. On-device storage in use

      Keeps data in the browser so the record works without a network.

      Outgoing:

  3. Evaluation

    1. Evaluation rules in use

      Converts feed into sugar equivalent, calculates mite drop per day, and derives the queen marking color.

      Outgoing:

  4. Data

    1. CSV and JSON export in use

      CSV for records, JSON as a backup, readable without the app.

  5. Geodata

    1. Open geodata (ALKIS via WFS) in use

      Official cadastral parcel data, queried through a standard interface.

      Outgoing:

    2. Query and conversion in use

      Queries the relevant parcels and converts them into KML.

      Outgoing:

    3. Map layer in use

      Shows the parcels on a phone in a common map app.

      Outgoing:

Back to the diagram

Decisions

Context, decision, trade-off, consequence.

Decision 01Offline first, a single file
Context
There is often no signal at the apiary; nothing should need installing.
Decision
A single-file web app, with no framework and no dependencies. Saved on the device.
Trade-off
The data stays on the individual device until it is exported.
Consequence
The record works without a network and without a server.
Decision 02Open formats instead of a data silo
Context
Records must stay readable for years, independently of my app.
Decision
Export as CSV for records and as JSON for a complete backup.
Trade-off
Backup runs through the export, not in the background.
Consequence
The data can move to any other system without loss.
Decision 03Rules instead of guesses
Context
A colony is easily assumed fully fed although nobody has weighed it.
Decision
Feed is converted into sugar equivalent using documented factors and compared with a target.
Trade-off
Stricter, and one more step of work.
Consequence
The overview shows openly what is missing; the human still makes the call.
Decision 04Parcels from official open data
Context
Tracing parcel boundaries by hand is imprecise and dates quickly.
Decision
Query parcels through the open WFS interface, as KML for common map apps.
Trade-off
The parcels are only as current as the official data.
Consequence
Boundaries match the official record.
Decision 05Runs on the farm, not on my servers
Context
A small farm does not need to depend on a service provider.
Decision
Modules are installed on the farm, set up briefly, then run without ongoing service.
Trade-off
Updates and backups are the farm’s responsibility, so everything has to be documented.
Consequence
No account with me, no running costs for me.

Human in the loop

  • The hive record rates the mite drop and shows a hint. Whether and how to treat is the beekeeper’s decision.
  • The app does not guess: if a measurement is missing, it shows the gap rather than an assumption.
  • The hive record was built with Claude. I try new features at a real apiary before they go into use.

Operations and quality

  • Every entry is saved on the device immediately and is kept even without a network.
  • Feed conversion factors are visible in the code, along with the source for the manufacturer’s value.
  • JSON backup after every day that has entries.

Transferable to other farms

The same approach can be set up for other farms and beekeeping associations: modules installed on site, set up quickly, and handed over with brief instructions, then run without ongoing service.

The hive record can be extended with sensing at the apiary (weight, temperature, humidity). There are experiments, but no finished prototype yet.

Stack

Status

Parcels are in use as a map layer. The hive record is a prototype in my own use.

No locations, colony data, or parcel numbers on this page.

Case study · verifiable from outside

Company IT and this website

Small, but built the way I would recommend to a client.

No. 03Live since September 2026

Role
Planning, build with Claude, sign-off
Since
September 2026
Core
Microsoft 365, DNS, GitHub Actions, static HTML

Summary

In September 2026 I built Ahnenhain Systems’ IT from scratch: mail with proper sender authentication, a secondary domain locked against spoofing, this website with no cookies or third-party requests, a private repository with signed commits and a verification pipeline. Claude prepared, I reviewed and approved; much of it you can check with public tools.

Starting point

A new sole proprietorship needs mail, domains, a website, and a place for code, with little upkeep. At the same time it should serve as evidence: anyone I ask to trust me with security should be able to see it in my own IT.

Goals and constraints

  1. Email sent in the company’s name has to be verifiable, and nobody should be able to spoof email through the secondary domain.
  2. The website loads nothing from third-party servers: no external fonts, no scripts, no tracking.
  3. Nothing goes online without my approval.
  4. Business and private identities stay technically separate.
  5. Email must not break during any change; it is checked immediately after every DNS change.

Architecture

From signed commit to the page in the browser, plus domains and mail.

Select a component. Its description appears alongside and its data flows are highlighted.

Read the architecture as a list

No component selected.

Read the architecture as a list

Architecture as text. Claude prepares files, check scripts and instructions. I decide on sign-off and deployment; Claude only carries out steps on DNS or web space in a session I oversee. I review and commit on a workstation with a separate business identity and sign every commit with an SSH key. The private repository lives in a dedicated organization. Every pull request goes through a verification pipeline: HTML validation, internal links, no third-party requests, legal notice, secret scanning, a size budget. Deployment happens only after my approval, never automatically. The hosting enforces HTTPS and strict security headers, and visitors load files from this domain only. The main domain points to the site and to mail at Microsoft 365 with SPF, DKIM, and DMARC. The secondary domain never sends mail, is locked with SPF, DMARC, and null MX, and redirects to the English version.

  1. People and AI

    1. Claude

      Prepares files, check scripts, workflows, DNS target values and instructions. Has no rights to approve or deploy.

      Outgoing:

      • Me: proposal for review

    2. Me

      Approve content, commit with a signature, merge, and start deployments.

      Outgoing:

  2. Development

    1. Workstation with separate identities in use

      A dedicated company account, separate from the private one; commits signed with an SSH key.

      Outgoing:

    2. Private repository in use

      In a dedicated organization, with two-factor authentication and a passkey on the account.

      Outgoing:

  3. Pipeline

    1. Verification pipeline in use

      HTML validation, internal links, no third-party requests, secret scanning, size budget.

      Outgoing:

    2. Deployment after approval in use

      Nothing goes live automatically. Deployment happens only after my approval.

      Outgoing:

  4. Web

    1. Web hosting with security headers in production

      Enforces HTTPS, sends the headers on redirects and error pages too.

      Outgoing:

      • Visitor: page without third-party requests

    2. Visitor

      Loads files from this domain only. No cookies, no tracking.

  5. Domains and mail

    1. Locked secondary domain in production

      Never sends mail: SPF with no permitted senders, DMARC set to reject, null MX.

      Outgoing:

    2. DNS of the main domain in production

      Web records for the site, mail records for Microsoft 365: MX, SPF, DKIM, DMARC.

      Outgoing:

    3. Mail (Microsoft 365) in production

      Company mailboxes. Outgoing mail passes SPF, DKIM and DMARC.

  6. Operations

    1. Archive of every release in production

      Every published state is archived with a checksum.

Back to the diagram

Decisions

Context, decision, trade-off, consequence.

Decision 01All repositories private
Context
A public repository would have allowed mandatory approvals at no cost.
Decision
Everything stays private; nothing extra gets published.
Trade-off
No required reviewers, no branch rules.
Consequence
The approval sits on the deployment start button (see decision 02).
Decision 02Deploy by manual start only
Context
Without required reviewers, a merge would otherwise go live automatically.
Decision
Deployment only by manual start after my approval, never automatically after a merge.
Trade-off
One deliberate extra step before every release.
Consequence
Nothing goes live by accident.
Decision 03No third-party requests, strict CSP
Context
One external font already shares the visitor’s IP with a third party.
Decision
Fonts served locally, no CDN. Scripts and styles live in the document and are allowed in the CSP by hash; otherwise the CSP allows only the site’s own origin.
Trade-off
Code inside the document needs a hash in the CSP, otherwise it does not run.
Consequence
The pipeline checks this automatically; the launch check counted zero third-party requests.
Decision 04Lock secondary domain against spoofing
Context
The secondary domain sends no mail but could still be spoofed without records.
Decision
SPF with no senders, DMARC set to reject, null MX; redirects to the English site.
Trade-off
Sending mail from there would require deliberately reverting the DNS records.
Consequence
Spoofed mail in the secondary domain’s name is rejected.
Decision 05Separate identities, signed commits
Context
A private developer account must never appear on company commits.
Decision
A dedicated company account; the folder selects the identity, commits are signed.
Trade-off
Two identities to maintain, one more subscription.
Consequence
Every commit is verifiable; private and business work stay separate.

Human in the loop

  • Claude writes files, check scripts, workflow drafts, DNS target values and step-by-step instructions.
  • I commit and sign, merge and start deployments.
  • I change DNS myself or explicitly approve each single change. Mail is checked immediately after every change.
  • Accounts, payments, passwords, keys, contracts and legal texts are mine alone.

Operations and quality

  • Acceptance after launch: all pages reachable, custom error page, internal files blocked, redirects in a single hop, headers on redirects and error pages too, no third-party requests, mail DNS unchanged.
  • HSTS with a one-year max-age, no preload.
  • The DMARC policy of the main domain can be queried publicly (see “Check it yourself”).
  • Budgets for paid add-on services set to zero with a hard stop. Only what is deliberately booked gets billed.
  • Every published state is archived with a checksum and an acceptance record.

Check it yourself

These queries show the public state. All you need is a terminal or your browser’s developer tools.

  2. dig +short TXT _dmarc.ahnenhain.de

    DMARC policy of the main domain.

  3. dig +short TXT ahnenhain.com

    SPF of the secondary domain: no permitted senders.

  4. dig +short MX ahnenhain.com

    Null MX: the secondary domain accepts no mail.

  5. Browser: developer tools, Network tab, reload the page

    Every request goes to ahnenhain.de. No other domain.

Stack

Status

Online since September 24, 2026, in German and English.

How I work with AI

Human in the loop: nothing goes live without review.

Who does what

The human

defines
The task, goal, sources and limits.
reviews
Every result against source and goal.
corrects
Whatever is wrong or unsupported.
signs off
And takes responsibility for it.

The machine

generates
Drafts, code, alternatives.
tests
Tests, linting and validation run on every change.
measures
Metrics, cross-checks, monitoring.
reviews independently
For Symbiont and this website, review agents check every change, separate from the agent that built it.

The process

  1. Brief

    Goal, sources, limits.

  2. Plan

    The machine proposes a plan. I review and approve it before anything is implemented.

  3. Generate

    Often with separate roles: one agent implements, a second looks for flaws, a third reviews.

  4. Automated checks

    Tests, static analysis, secret scanning. Red means starting over.

  5. Human review

    I check against the source; anything unsupported gets flagged.

  6. Sign off

    Only then is it used, published or deployed.

  7. Learn

    Every failure becomes a rule or a test.

Guardrails

Data first, then the model
The confidentiality class of the data decides which model may see it.
No sensitive data without a plan
Clients’ personal, health, and biometric data only with a documented data protection plan and a data processing agreement.
Least privilege for agents
Only the tools and access the current step needs. Real effects only after a dry run, risky steps in a sandbox.
Sign-off before use
No text, code or analysis goes out to third parties without human sign-off.
Building and reviewing kept apart
In my own projects, agents build, independent agents review, and only what I have approved reaches main.
Label openly
If an AI generated something, I say so; overnight agent runs are labeled as such.
Keep cost in view
Cheaper models for many parallel checks, stronger ones for synthesis.

What I don’t build, or only with limits

I do not prepare decisions about people with a model whose output cannot be checked.

  • Systems that select job applicants or make personnel decisions.
  • Credit scoring.
  • Analysis of employee performance or behavior only after a prior legal review.

This site was made this way

The content and text were drafted by Claude and built with Claude Code. I checked every sentence against the sources and approved it; every change goes online as a signed commit from me.

How this site is built

Contact

By email or phone, in German or English.

Open spots: 1 of 2

Open knot: available. Closed knot: taken.

Email
info@ahnenhain.de
Phone
+49 160 2495853
LinkedIn
Julius C. Gnädig (opens an external site)

Publications

In preparation. Publications will appear here once released.

First paper

Working title

Living in Symbiosis

Format
Position paper with a first-person longitudinal case study (N = 1), in English.
Overview

The starting point is J. C. R. Licklider’s 1960 idea of human-computer symbiosis. The paper describes a long-standing working partnership with AI from the inside, based on records from my own system, Symbiont.

It distinguishes two layers: a personal record that the human keeps, and a rented interaction with AI services. Why is the gap widening between people who work with AI and people who merely use it? The paper looks for the answer in what people hold, not in what they can access.

Read the Symbiont case study

Three principles turn tool use into symbiosis when they bind human and system alike.

  • Validation
  • Auditability
  • Self-improvement

AI disclosure Research and drafts are produced with AI assistance; I am responsible for the content and its release as the author.

Selected references

  1. Licklider, J. C. R. (1960). Man-Computer Symbiosis. IRE Transactions on Human Factors in Electronics. doi:10.1109/THFE2.1960.4503259 (opens an external site)
  2. Clark, A., & Chalmers, D. J. (1998). The Extended Mind. Analysis. doi:10.1093/analys/58.1.7 (opens an external site)
  3. Jarrahi, M. H. (2018). Artificial Intelligence and the Future of Work: Human-AI Symbiosis in Organizational Decision Making. Business Horizons. doi:10.1016/j.bushor.2018.03.007 (opens an external site)
  4. Green, B., & Chen, Y. (2019). The Principles and Limits of Algorithm-in-the-Loop Decision Making. Proceedings of the ACM on Human-Computer Interaction. doi:10.1145/3359152 (opens an external site)
  5. Lucero, A., Desjardins, A., Neustaedter, C., Höök, K., Hassenzahl, M., & Cecchinato, M. E. (2019). A Sample of One: First-Person Research Methods in HCI. DIS ’19 Companion.
  6. Zahedi, Z., & Kambhampati, S. (2021). Human-AI Symbiosis: A Survey of Current Approaches. arXiv. arXiv:2103.09990 (opens an external site)
  7. Vaccaro, M., Almaatouq, A., & Malone, T. (2024). When Combinations of Humans and AI Are Useful: A Systematic Review and Meta-Analysis. Nature Human Behaviour. doi:10.1038/s41562-024-02024-1 (opens an external site)
  8. Boulus-Rødje, N., Cranefield, J., Doyle, C., & Fleron, B. (2024). GenAI and Me: The Hidden Work of Building and Maintaining an Augmentative Partnership. Personal and Ubiquitous Computing. doi:10.1007/s00779-024-01810-y (opens an external site)
  9. Litvinova, Y., Mikalef, P., & Luo, X. (2024). Framework for Human-XAI Symbiosis: Extended Self from the Dual-Process Theory Perspective. Journal of Business Analytics. doi:10.1080/2573234X.2024.2396366 (opens an external site)
  10. Tong, R. J. (2026). From Augmentation to Symbiosis: A Review of Human-AI Collaboration Frameworks, Performance, and Perils. arXiv. arXiv:2601.06030 (opens an external site)
  11. Wang, P., Liu, H., Zou, L., & Paas, F. (2026). Overloaded Minds and Machines: A Cognitive Load Framework for Human-AI Symbiosis. Artificial Intelligence Review. doi:10.1007/s10462-026-11510-z (opens an external site)

Second paper

Working title

PermaIoT

Format
Position paper, written in English.
Overview

Starting from the idea (2022) and the concept (2025), the paper describes how IoT and AI can turn industrial farming into viable permaculture; the practical reference is the farming and beekeeping case study.

How can sensors and specialized AI make permaculture so measurable and profitable that it beats industrial farming on economics, not just on ecology?

Read the farming and beekeeping case study

  • Health before yield. The condition of soil, plants and animals is the first metric, yield the second.
  • Measure, don’t assume. Sensors make permaculture traceable; what is measured can be financed and repeated.
  • Technology serves the farm, not the other way around. Modules run on the farm, stay understandable and create no ongoing dependency.

AI disclosure Research and drafts are produced with AI assistance; I am responsible for the content and its release as the author.

AI Engineer · agentic automation, built to run safely

Julius C. Gnädig

Owner, Ahnenhain Systems

Experience

  1. since September 2026

    Owner, Ahnenhain Systems

    AI, automation and data analysis for a small number of selected clients.

  2. since April 2026

    Technical owner, self-service platform project (Kubernetes, Crossplane)

  3. since March 2026

    AI Champion in a cross-team network

    • A shared knowledge store that gives AI agents persistent context through MCP, built on validated decisions, auditability, and self-improvement
    • An agentic engineering workflow from kickoff prompt to documentation, with autonomy levels, approvals, and checkpoints
    • Recurring operations packaged as versioned, testable agent skills
    • An AI documentation workflow with source checks: anything unverified goes to human review
    • Governance built into the workflows: data classes, sandboxing and dry runs, approved MCP servers, human sign-off; cost and quality measured against a baseline
    • Workshops, live demos, and one-on-ones at each person’s level

  4. since July 2023

    Platform Engineer

    The role was titled Cloud Engineer until 2026.

    • Upgrade and run Apache Kafka and Confluent Platform on Kubernetes
    • Automate rollouts with Ansible and AWX, validate them with Grafana and Confluent Control Center
    • Monitoring and alert triage with the team using Grafana, Prometheus, and Flux

  5. September 2020 to June 2023

    Apprenticeship: IT specialist for system integration

    Fachinformatiker für Systemintegration: a dual apprenticeship, normally three years, combining vocational school with on-the-job training, certified by the Chamber of Commerce and Industry (IHK). Qualified 2023.

    • From 2022 on the Kafka and messaging team: Kubernetes, ongoing upgrades of all Kafka and Confluent components with Ansible and AWX, Helm
    • Final IHK project: an add-on that simplifies DevOps tasks around Apache Kafka

Summary

I build AI agents and the platform underneath them. My roots are in Kubernetes and event streaming with Apache Kafka and Confluent, and since 2026 I have held technical responsibility for a self-service platform project. As an AI Champion I build agentic tooling for several teams. I have worked with generative AI daily since 2022 and with my own workflows since 2023. A self-hosted automation environment (n8n, PostgreSQL, Docker) and my own development platform on Kubernetes serve as my lab. My principles: validated decisions, auditability, and self-improvement.

Tools

AI and agents
Generative AI, AI agents, agentic development, agent skills, Model Context Protocol (MCP), Claude Code, GitHub Copilot, context engineering, prompt engineering, retrieval-augmented generation (RAG), function calling, AI-assisted development, AI governance, human in the loop, AI cost optimization
Automation
n8n, workflow design, Telegram bots, webhooks
Platform
Kubernetes, k3s, Flux, GitOps, Kustomize, Helm, Crossplane, Kyverno, policy as code, Docker, Podman, Ansible, AWX, GitHub Actions, Grafana, Prometheus
Data
PostgreSQL, pgvector, Kafka, Confluent, data pipelines, data analysis
Security
RBAC, OIDC, Workload Identity Federation, secrets management with SOPS and age, mail security with SPF, DKIM and DMARC
Programming languages
Go, Python, TypeScript, Bash, SQL; basics in Java and C#; YAML for configuration
Ways of working
Knowledge transfer, workshops, documenting architecture decisions, review and sign-off, BDD tests, scope and MVP

No self-rated skill levels. The evidence is in the projects.

Education and training

  • Kubernetes for service providers, three-day course2024
  • IT specialist for system integration (Fachinformatiker für Systemintegration), IHK Nuremberg, vocational school in Fürth with grade 1.7 (German scale, 1 = best)2023
  • Ansible Advanced, orchestration in depth, ExperTeach, four-day course with certificate2022
  • Scrum2021
  • Test-driven development with C#2021
  • Database fundamentals2021
  • Cambridge EnglishFirst Certificate

Languages

  • Germannative
  • Englishnear-native, bilingual school program (grades 5 to 10)

In the print dialog you can save the output as a PDF.

Contact

By email or phone, in German or English.

Open spots: 1 of 2

Open knot: available. Closed knot: taken.

Email
info@ahnenhain.de
Phone
+49 160 2495853
LinkedIn
Julius C. Gnädig (opens an external site)

How this site is built

A site about security and AI should itself show how it is built.

What this site does not do

  • No cookies.
  • No tracking, no analytics scripts, no third-party visitor counting.
  • No requests to third-party servers: fonts, images and scripts come from this domain.
  • No database: the callback form sends your details to me as an email and stores nothing.
  • Fully readable without JavaScript. Motion only if your system has not asked for reduced motion.

Measurements

Lighthouse, mobile

Measured at build time and inserted automatically. No hand-entered values.

Measured live, in your browser

The live measurement needs JavaScript. Without it the values stay empty; the site still works.

Total transferred
measuring

Sum of transferSize for the document and all resources, including headers, as they came over the network.

Document
measuring

The HTML file itself. On this site fonts, styles and scripts are part of it.

Requests
measuring

The document plus every resource the browser loaded after it.

Requests to other origins
measuring

Every request whose origin (scheme, host, port) differs from this page.

DOMContentLoaded
measuring

Time from the start of navigation until the HTML is parsed and scripts have run.

Load
measuring

Time from the start of navigation until all resources have loaded as well.

From cache
measuring

A transferSize of 0 with content present means the browser transferred nothing because it already had the file. The transfer is therefore counted as 0.

Scripts
measuring
Style blocks
measuring

Counted in the document: inline and as separate files.

Checks at build time

Lighthousemobiledesktop
Performance7498
Accessibility100100
Best practices100100
SEO100100
axe-core violations
0 in 204 states
Measured on
October 13, 2026
Tools
Lighthouse 13.5.0, axe-core 4.13.0, Chromium 141.0.7390.37
Checked
All pages of the live build, German and English

Measured with Lighthouse and axe-core in a headless browser, in the verification pipeline. Lighthouse: median of five runs.

Security headers

Content-Security-Policy
Content from this domain only, scripts and styles only from this domain or with a hash in the CSP.
Strict-Transport-Security
Browsers connect only over encrypted connections.
X-Content-Type-Options
Files are only interpreted as the type the server declares.
Referrer-Policy
When you leave the site, at most the domain is passed on.
Permissions-Policy
Camera, microphone, location, motion sensors, payment and USB are switched off.
X-Frame-Options
The site cannot be loaded inside another site’s frame.

Design

Typefaces
Cinzel for the wordmark, EB Garamond for text, Source Sans 3 for the interface. All under the SIL Open Font License, served locally.
Colors
From the brand guidelines: deep fir, fir and needle green for surfaces and text, ivory as paper, resin gold only for rules and accents.
Mark
A tree growing through a gear ring.
Motion
Calm and sparing, never when reduced motion is set.

Tools

Who did what

Me (Julius C. Gnädig)
Goals, content, decisions. Review and sign-off of every text, commits, publishing.
Claude
Research, draft text in German and English, design proposals.
Claude Code
Building the site, check scripts, pipeline.
Automated checks
Validation, secret scanning, third-party request check, measurements on every build. Independent review agents check every change as well.

Every draft went through my review before it went live.

Licenses

Cinzel © The Cinzel Project Authors, EB Garamond © The EB Garamond Project Authors, Source Sans 3 © Adobe. All under the SIL Open Font License 1.1; the license text is included with the font files. The embedded subset of Source Sans 3 runs under its own name “Ahnenhain Grotesk” (name table adjusted, as the OFL provides for modified versions); origin and license remain Source Sans 3, Adobe, SIL Open Font License 1.1.

Contact

By email or phone, in German or English.

Open spots: 1 of 2

Open knot: available. Closed knot: taken.

Email
info@ahnenhain.de
Phone
+49 160 2495853
LinkedIn
Julius C. Gnädig (opens an external site)

Only a few projects at a time.

Callback form without tracking. Your details go to me by email only and are not stored.

Request a conversation

A name, a way to reach you and a few words are enough. I will get back to you in the time window you choose.

Your details go to me by email only and are not stored on the server. More in the privacy policy (in German). All times Central European Time.

Where does an agent pay off?

Five questions about one task from your day. The assessment is calculated in your browser. Nothing is sent and nothing is stored.

The five questions

  1. How often does the task come up? Several times a day · Daily or several times a week · About once a month · Rarely or once
  2. How long does one run take? More than two hours · 30 minutes to two hours · 5 to 30 minutes · Under 5 minutes
  3. How structured is the input? Fixed layout, such as forms or tables · Mostly uniform, with exceptions · Mixed, such as emails and PDFs from many sources · Free-form or only in someone’s head
  4. What does a mistake cost? Little: it gets noticed and is quickly fixed · Noticeable: rework or friction · High: money, contracts or customer trust · Severe: legal, safety or irreversible
  5. Who can review and approve the result? A knowledgeable person, quickly · Someone, but it takes time · Spot checks only · Nobody, the result goes straight out

Without JavaScript, the rule of thumb is: the more frequent and time-consuming the task, the more fixed the input and the better someone can review the result, the more an agent pays off. If a mistake is costly and nobody reviews, it does not.

This page does not exist.

The address may have changed, or it may contain a typo. One of these will get you further:

Or search with Ctrl + K or ⌘ + K.

Proposed architecture · Small businesses and trades

Reading, sorting, and drafting replies to inquiries

Appointment requests by email or voice message are prepared as a draft reply. Nothing is sent until you approve it.

Starting point

Inquiries arrive by email and as voice messages, often between two appointments. They have to be read, sorted by urgency, and answered while the business keeps running.

Target picture

  1. Incoming inquiries are recognized, sorted, and given a draft reply.
  2. Appointment suggestions come from the real calendar, not from a model’s guess.
  3. Nothing is sent without your approval.
  4. Personal data stays limited to what is needed and is hosted in the EU or on your own server.

Architecture

From the incoming inquiry to the approved reply.

Select a component. Its description appears alongside and its data flows are highlighted.

Read the architecture as a list

No component selected.

Read the architecture as a list

Architecture as text, as a proposal. Inquiries arrive as email or voice message in a mailbox set up for the purpose. A workflow orchestrator accepts every inquiry and calls the steps in order. Speech recognition turns voice messages into text. A language model reads the text and returns structured fields: topic, urgency, preferred date; the output is checked against a schema. Fixed validation rules check fields and sender. Free times are read from the calendar. Fields, text modules and free times become a draft reply. An approval interface shows inquiry and draft side by side; the owner sends, edits, or discards. Sending runs only for approved replies. A database holds inquiries, drafts, and decisions with a retention period, and a log with monitoring makes errors and costs visible.

  1. Input

    1. Mailbox and voice message Proposal

      Accepts emails and voice messages in a mailbox or messenger channel set up for the purpose.

      Outgoing:

  2. Orchestration

    1. Workflow orchestration Proposal

      Starts on every inquiry, calls the steps in order, retries failures, and stores nothing incomplete.

      Outgoing:

  3. AI and rules

    1. Speech recognition Proposal

      Turns voice messages into text. The audio is not kept.

      Outgoing:

    2. Language model with schema Proposal

      Reads the inquiry and returns fields instead of free prose. Invalid output is rejected.

      Outgoing:

    3. Validation rules Proposal

      Fixed rules check fields, sender, and limits before anything moves on.

      Outgoing:

    4. Draft reply Proposal

      Writes the draft in your tone from text modules, fields, and free times.

      Outgoing:

  4. Data

    1. Calendar, read only Proposal

      Provides free times. The model does not guess appointments.

      Outgoing:

    2. Database with retention period Proposal

      Holds inquiries, drafts, and decisions. They are deleted after the set period.

  5. Human

    1. Your approval Proposal

      Shows inquiry and draft side by side. You send, edit, or discard.

      Outgoing:

  6. Output

    1. Sending Proposal

      Sends approved replies only, from your own mailbox.

  7. Operations

    1. Log and monitoring Proposal

      Records every step with its result and makes errors and costs visible.

Back to the diagram

Components

Components
TaskTechnologyWhy
InputMailbox via fetch or forwarding, messenger channelInquiries arrive where they already do.
OrchestrationWorkflow tool (for example n8n), queue, retry logicEvery step is visible, failures are retried instead of swallowed.
Speech to textSpeech recognition modelVoice messages become readable without keeping audio.
UnderstandingLanguage model with structured output and schema validationFields instead of prose: invalid output is rejected, not passed on.
AppointmentsCalendar interface, read onlySuggestions rest on real free times.
ApprovalApproval interface or messenger buttonsYou decide before anything leaves the business.
DataPostgreSQL, retention enforced by scheduleOne place for state and decisions, with a fixed end to retention.
OperationsLogs, tracing of model calls, dashboards with GrafanaErrors and costs stay visible.

Human in the loop

  • The draft reply leaves the system only through your approval: send, edit, or discard.
  • Unclear or urgent inquiries are flagged and shown first, not answered automatically.
  • Appointments and commitments count only once you have confirmed them.

Privacy in the architecture

  • Data minimization: the model receives the text of the inquiry, not your customer master data.
  • Hosting in the EU or on your own server.
  • A data processing agreement is signed with every external model provider before the start.
  • Retention periods are set: inquiries and drafts are deleted when they expire, audio is not kept.

Technical design, not legal advice.

Operations and security

  • Log: every step is recorded with its result so it is possible to trace what was proposed.
  • Monitoring: errors, wait times, and model costs are shown; a daily cost cap prevents runaway usage.
  • Tests and evaluations: a fixed set of real sample inquiries checks after every change that sorting and drafts stay good.
  • Secrets: credentials live in a secrets store, not in the workflow.
  • Permissions: access is as narrow as possible, the calendar read only, the mailbox only for sending approved replies.

Does this fit your business? We find out in the intro call, free of charge.

Request a conversation

Proposed architecture · Clubs and nonprofits

Member mailings from notes

A draft is created from your notes, such as a rehearsal date change. A member of the board reads and approves every text.

Starting point

In a club, one person usually writes the mailings on the side. Information is scattered across notes, chat messages, and schedules, and every text has to get the tone and the facts right.

Target picture

  1. Notes and the schedule become a draft in the usual shape of the club’s mailings.
  2. Dates, places, and names in the draft come from the schedule and are checked against it.
  3. A member of the board reads and approves every text.
  4. Member data stays in the membership system; the draft receives only what it needs.

Architecture

From the note to the approved member mailing.

Select a component. Its description appears alongside and its data flows are highlighted.

Read the architecture as a list

No component selected.

Read the architecture as a list

Architecture as text, as a proposal. Notes from the meeting and a maintained schedule are the source of facts. A workflow orchestrator starts on new notes and calls the steps in order. Earlier, approved mailings serve as a pattern for tone and structure. A language model writes the draft and returns fixed fields: subject, body, dates mentioned. A fact check compares dates, places, and names with the schedule; deviations are flagged, not silently corrected. The draft sees no addresses. A member of the board reads the draft with the flagged deviations and edits or approves it. Sending happens only for approved texts, from the club’s mailbox and to the distribution list from the membership system. A store holds drafts, approvals, and changes with a retention period; a log with monitoring makes errors visible.

  1. Input

    1. Notes and schedule Proposal

      Source of facts: notes from the meeting and a maintained schedule.

      Outgoing:

  2. Orchestration

    1. Workflow orchestration Proposal

      Starts on new notes, calls the steps in order, and retries failures.

      Outgoing:

  3. AI and rules

    1. Language model with fixed fields Proposal

      Writes the draft. The output has fixed fields: subject, body, dates mentioned.

      Outgoing:

    2. Fact check Proposal

      Compares dates, places, and names with the schedule. Deviations are flagged, not silently corrected.

      Outgoing:

  4. Data

    1. Store with retention period Proposal

      Holds drafts, approvals, and changes. They are deleted after the set period.

    2. Distribution list from the membership system Proposal

      Holds the addresses. The draft does not see them, only sending does.

      Outgoing:

    3. Templates and tone guidelines Proposal

      Earlier, approved mailings as a pattern for tone and structure.

      Outgoing:

  5. Human

    1. Approval by the board Proposal

      One person reads the draft with the flagged deviations and edits or approves it.

      Outgoing:

  6. Output

    1. Sending Proposal

      Sends approved texts only, from the club’s mailbox.

  7. Operations

    1. Log and monitoring Proposal

      Records every step and makes errors and costs visible.

Back to the diagram

Components

Components
TaskTechnologyWhy
SourceShared notes document, schedule as a table or calendarThe facts live in one place the club already maintains.
OrchestrationWorkflow tool (for example n8n), queue, retry logicEvery step is visible, failures are retried instead of swallowed.
DraftLanguage model with template and structured outputTone and structure follow earlier mailings, the output has fixed fields.
Fact checkFixed matching rules against the scheduleA model proposes, the rules decide what counts as a deviation.
ApprovalApproval interface or messenger buttonsA responsible person decides before every mailing.
SendingClub mailbox, distribution list from the membership systemAddresses stay in the system that already manages them.
StorePostgreSQL, retention enforced by scheduleDrafts and approvals stay traceable, but not indefinitely.
OperationsLogs, tracing of model calls, dashboards with GrafanaErrors and costs stay visible.

Human in the loop

  • A member of the board reads every text and approves it. Nothing goes out without approval.
  • Deviations from the schedule are flagged in the draft so the review can be targeted.
  • Whoever approves can edit and discard; the system never sends on its own.

Privacy in the architecture

  • Data minimization: the draft receives notes and the schedule, no addresses and no member lists.
  • Confidential matters such as health information or disputes do not belong in the notes the model reads.
  • Hosting in the EU or on your own server; a data processing agreement is signed with every external model provider before the start.
  • Retention periods are set: drafts and notes are deleted when they expire.

Technical design, not legal advice.

Operations and security

  • Log: every step is recorded with its result so it is possible to trace what was proposed and what was approved.
  • Monitoring: errors and model costs are shown; a daily cost cap prevents runaway usage.
  • Tests and evaluations: a fixed set of earlier notes checks after every change that drafts get dates and names right.
  • Secrets: credentials live in a secrets store, not in the workflow.
  • Permissions: sending is the only place with access to the mailbox and the distribution list.

Does this fit your club? We find out in the intro call, free of charge.

Request a conversation

Proposed architecture · Teams and freelancers

Following up on quotes

Open quotes are spotted and the follow-up is prepared as a draft. The person who made the quote reads the draft and sends it themselves.

Starting point

Quotes go out and disappear into the inbox. Following up gets put off because nobody has an overview of who is still waiting for an answer.

Target picture

  1. Open quotes are identified from the inbox and a simple customer directory.
  2. For every open quote a follow-up draft is ready that refers to the conversation so far.
  3. The person who made the quote reads the draft and sends it themselves.
  4. A task in the task list reminds you when a reply is missing.

Architecture

From the open quote to the follow-up that is sent.

Select a component. Its description appears alongside and its data flows are highlighted.

Read the architecture as a list

No component selected.

Read the architecture as a list

Architecture as text, as a proposal. A scheduled workflow regularly checks which quotes have gone unanswered. For that it reads the inbox, read only, and a simple customer directory, such as a table or a lean CRM with quote status. A language model reads the conversation so far and determines whether a quote is open; it returns fields and decides nothing. Fixed validation rules determine whether to follow up: minimum interval, no duplicate flag, nothing to blocked contacts. From the conversation a follow-up draft is created. The person who made the quote reads the draft and sends it themselves, edits it, or discards it. A task in the task list reminds you when a reply is missing. A log with monitoring makes errors and costs visible.

  1. Input

    1. Inbox, read only Proposal

      Provides the conversation for each quote. It is only read, never used for sending.

      Outgoing:

  2. Orchestration

    1. Scheduled workflow Proposal

      Regularly checks for quotes without a reply, calls the steps in order, and retries failures.

      Outgoing:

  3. AI and rules

    1. Language model as reader Proposal

      Reads the conversation and determines whether a quote is open. It returns fields and decides nothing.

      Outgoing:

    2. Validation rules Proposal

      Fixed rules: minimum interval, no duplicate flag, nothing to blocked contacts.

      Outgoing:

    3. Follow-up draft Proposal

      Writes a short draft that refers to the conversation so far.

      Outgoing:

  4. Data

    1. Task list Proposal

      Reminds the responsible person when a reply is missing.

    2. Simple customer directory Proposal

      A table or lean CRM with quote status: open, answered, declined.

      Outgoing:

  5. Human

    1. Read and send yourself Proposal

      The person who made the quote reads the draft and sends it themselves, edits it, or discards it.

      Outgoing:

  6. Operations

    1. Log and monitoring Proposal

      Records every step and makes errors and costs visible.

Back to the diagram

Components

Components
TaskTechnologyWhy
SourceInbox (read only), simple customer directory as a table or CRMThe overview comes from data that already exists.
OrchestrationScheduled workflow (for example n8n), retry logicThe check runs regularly without anyone having to remember it.
UnderstandingLanguage model with structured output and schema validationFields instead of prose: invalid output is rejected, not passed on.
RulesFixed validation rules in code or workflowRules decide whether to follow up, not the model.
DraftLanguage model with a template in the person’s toneThe draft sounds like you and refers to the conversation.
ApprovalApproval interface or messenger buttonsThe person decides and sends themselves.
ReminderTask list or calendarA missing reply becomes visible without anything going out automatically.
OperationsLogs, tracing of model calls, dashboards with GrafanaErrors and costs stay visible.

Human in the loop

  • The draft is never sent automatically. The person who made the quote reads, edits, or discards it.
  • Anyone who does not want to follow up on a quote blocks the contact; the system respects that.
  • The status in the customer directory changes only once the person confirms it.

Privacy in the architecture

  • Data minimization: the model sees the conversation of a single quote, not the whole inbox.
  • Hosting in the EU or on your own server; a data processing agreement is signed with every external model provider before the start.
  • Retention periods are set: intermediate states and drafts are deleted when they expire.
  • The inbox is only read; the system has no access for sending.

Technical design, not legal advice.

Operations and security

  • Log: every step is recorded with its result so it is possible to trace why a quote counted as open.
  • Monitoring: errors and model costs are shown; a daily cost cap prevents runaway usage.
  • Tests and evaluations: a fixed set of real conversations checks after every change that open quotes are correctly identified.
  • Secrets: credentials live in a secrets store, not in the workflow.
  • Permissions: as narrow as possible, the inbox read only, the directory only for the status fields.

Does this fit the way you work? We find out in the intro call, free of charge.

Request a conversation

Legal notice

The legal notice (Impressum) is provided in German.

Legal notice and privacy policy are available in German only. The German version is legally binding.

Open the German version

Privacy policy

The privacy policy is provided in German.

Legal notice and privacy policy are available in German only. The German version is legally binding.

Open the German version

Glossary

Technical terms and brand names are highlighted throughout the site. This page explains them together, in alphabetical order and without endorsement.

A

access log

term

An access log records who or what accessed a system and when, so unusual attempts can be spotted afterwards.

admission validation

term

Admission validation automatically checks every change to a Kubernetes cluster against fixed rules before it takes effect.

agent skills

term

Agent skills are prepared instructions and tools that show an AI agent how to carry out a specific, recurring task.

AI adoption

term

AI adoption is the process by which a team or organization starts using AI tools in everyday work.

AI agent

term

An AI agent is a program that uses a language model to carry out tasks across multiple steps on its own, rather than just answering single queries.

AI cost optimization

term

AI cost optimization means choosing the cheapest AI model that is still good enough for each task, to keep running costs low.

AI governance

term

AI governance is the set of rules and responsibilities that define how an organization uses and controls AI systems responsibly.

AI-assisted

term

AI-assisted means an AI helps with a task, while a person still reviews the results and makes the decisions.

ALKIS

term

ALKIS is Germany's official cadastral information system, describing land parcels and buildings nationwide in a consistent format.

allow list

term

An allow list contains every sender or address that is explicitly permitted; everything else is rejected automatically.

Ansible

brand

Ansible is configuration and operations automation software that describes procedures in plain text files.

API

term

An API defines how programs exchange data and call each other's functions.

architecture decision records

term

Architecture decision records are short, versioned documents that capture a decision, its context, the trade-offs and its consequences.

architecture guideline

term

An architecture guideline is a written rule for how technical systems in an organization should be built.

Arduino

brand

Arduino is an open hardware and software platform built around microcontroller boards for electronics projects.

AWX

brand

AWX is a web interface and platform for Ansible, used to schedule, run and track automation jobs.

axe-core

brand

axe-core is a library that automatically checks web pages for accessibility rule violations.

B

Bash

term

Bash is a widely used shell for running commands and small scripts from the command line.

best practices

term

Best practices are proven methods that have been shown to work reliably and are widely recommended.

bot

term

A bot is a program that sends or receives messages on its own, acting like an automated participant in a conversation.

branch

term

A branch is a separate, parallel version of the code where changes can be tried out without touching the main version.

C

C#

term

C# is an object-oriented programming language from Microsoft, used mainly within the .NET ecosystem.

Caddy

brand

Caddy is a web server that handles incoming requests and, used as a reverse proxy, manages encrypted connections and security headers.

CEL

term

CEL (Common Expression Language) is a simple expression language used to write conditions, for example for validation rules.

checkout

term

A checkout pulls a repository's code onto a machine so it can be checked or deployed there.

Chromium

brand

Chromium is the open-source browser project that Google Chrome and others build on, used here for headless automated checks.

Claude

brand

Claude is a family of AI language models from Anthropic, used for text, research and coding tasks.

Claude Code

brand

Claude Code is a command-line tool from Anthropic that puts Claude to work on coding tasks, such as writing, reviewing and building code.

Cloud Engineer

term

A cloud engineer designs, builds, and operates infrastructure and platforms for cloud environments.

cluster

term

A cluster is a group of computers that work together as one system and share tasks among themselves.

commit

term

A commit is a saved, permanently traceable change to the code in a repository. A signed commit also carries a digital signature that proves who made it.

confidentiality class

term

A confidentiality class rates data by how sensitive it is, which in turn decides who or what is allowed to see it.

Confluent

brand

Confluent is a commercial platform built around Apache Kafka, adding tools for operating and managing it.

container

term

A container is a self-contained environment for a single application, packaged with everything it needs to run.

context engineering

term

Context engineering means deliberately supplying an AI system with the right background information and materials so it can complete a task reliably.

Crossplane

brand

Crossplane is a Kubernetes extension that lets teams manage cloud and platform resources through the same Kubernetes interfaces.

CSP

term

The Content Security Policy (CSP) is a browser security rule that defines which sources a page may load scripts and other content from.

CSS

term

CSS is the language that defines how a web page looks, including colors, spacing and typography.

CSV

term

CSV is a plain text format for tabular data in which values are separated by a delimiter such as a comma.

D

data analysis

term

Data analysis means working out patterns or insights from collected data that decisions can then be based on.

data pipeline

term

A data pipeline is a chain of automated steps that collects data from a source, processes it, and delivers it to its destination.

database trigger

term

A database trigger is a stored rule that a database runs automatically as soon as a certain event happens.

deployment

term

A deployment (also called a rollout) is the act of publishing a new version of software onto the system that actually uses it.

DKIM

term

DKIM adds a digital signature to outgoing mail so the sender and its integrity can be verified.

DMARC

term

DMARC tells receiving servers how to handle mail that fails a domain's SPF or DKIM checks.

DNS

term

DNS (Domain Name System) translates domain names into technical addresses and other records, for example for mail delivery.

DNSSEC

term

DNSSEC adds a digital signature to DNS records so that forged answers can be detected.

Docker

brand

Docker is software that packages applications together with their environment into containers that run consistently anywhere.

Docker Compose

brand

Docker Compose is a tool that starts and manages several related Docker containers from one shared configuration file.

domain

term

A domain is the unique address of a website on the internet, for example ahnenhain.de.

DOMContentLoaded

term

DOMContentLoaded is the moment when the browser has read a page and run its scripts, even if images are still loading.

dry run

term

A dry run carries out a process as a test and shows what would happen, without actually triggering the real effect.

E

embeddings

term

Embeddings are numeric vectors that represent the meaning of text so that similar content can be compared computationally.

EU AI Act

term

The EU AI Act is a European Union law that sets rules for developing and using AI systems, including labeling content that AI has generated.

F

Flux

brand

Flux is a GitOps tool for Kubernetes that continuously reconciles a cluster with the state kept in a Git repository.

function calling

term

With function calling, a language model picks from a fixed list of predefined tools and supplies the parameters; the program, not the model, runs the tool.

functional test

term

A functional test checks a system as a whole by running a real scenario through it, rather than looking at isolated parts.

G

generative AI

term

Generative AI refers to systems that create new text, images or other content on their own, rather than just analyzing existing data.

GeoServer

brand

GeoServer is open-source software that serves geographic data through standard interfaces such as WFS.

GitHub

brand

GitHub is a platform for hosting and version-controlling code with Git, with features for collaboration, reviews and automation.

GitHub Actions

brand

GitHub Actions is GitHub's built-in automation, running defined workflows such as tests or a deployment when events happen in a repository, for example a commit.

gitleaks

brand

gitleaks is a tool that scans a repository for accidentally committed credentials and secrets.

GitOps

term

GitOps is an approach where a system's desired state is described in a Git repository and changes are deployed from it.

Go

term

Go is a programming language developed at Google, commonly used for server and infrastructure software.

governance

term

Governance is the set of established rules and responsibilities an organization uses to steer a topic such as data or AI responsibly.

GPG

brand

GPG (GNU Privacy Guard) is software for encryption and digital signatures, for example to verifiably attribute commits to a person.

guardrails

term

Guardrails are fixed rules and limits within which an AI system or AI agent is allowed to operate.

gzip

term

gzip is a method that shrinks files before they are sent, so they reach the browser faster.

H

health check

term

A health check is an automatic, recurring test of whether a program is still running correctly, with an automatic restart if it is not.

Helm

brand

Helm is a package manager for Kubernetes that installs and manages applications from prepared templates.

hive record

term

A hive record is the card or digital log kept for a single bee colony, covering things like feeding and health.

HSTS

term

HSTS instructs the browser to reach a website only over an encrypted connection for a set period of time.

HTML

term

HTML is the markup language used to describe a web page's content and structure.

html-validate

brand

html-validate is a tool that checks HTML files against rules for valid and consistent markup.

HTTPS

term

HTTPS is the encrypted variant of the HTTP web protocol.

human in the loop

term

Human in the loop describes a setup in which a person reviews and approves an AI system's output before it takes effect.

I

IBM MQ

brand

IBM MQ is IBM's message broker for reliable messaging between enterprise applications.

IHK

term

The IHK (Chamber of Commerce and Industry) is a German body responsible for, among other things, vocational examinations and qualifications.

infrastructure as code

term

Infrastructure as code means describing servers and other technical resources in a text file instead of setting them up by hand, so they can be created automatically from it.

IP address

term

An IP address is the numeric address that identifies a device on the internet.

IRT

term

Item response theory (IRT) is a statistical method that lets a learning application adapt question difficulty to the learner's level.

J

Java

term

Java is a widely used, object-oriented programming language for applications across many platforms.

JavaScript

term

JavaScript is the programming language that gives web pages interactive behavior in the browser.

Jest

brand

Jest is a JavaScript testing framework used to write and run automated tests.

JSON

term

JSON is a text-based data format used to exchange structured data between programs and systems.

K

k3s

brand

k3s is a lightweight Kubernetes distribution that can also run on a single server.

Kafka

brand

Apache Kafka is a data streaming platform that reliably passes messages between systems at high volume.

KML

term

KML is a geographic data file format that many map applications can read.

knowledge transfer

term

Knowledge transfer means deliberately passing expertise on to other people so it does not stay tied to just one person.

Kubernetes

brand

Kubernetes is a container orchestration platform that handles distributing, scaling and running containers across multiple machines.

Kustomize

brand

Kustomize is a tool that adapts Kubernetes configuration files for different environments without a templating language.

Kyverno

brand

Kyverno is Kubernetes software that enforces policies and validates incoming resource changes before they are accepted.

L

language model

term

A language model is an AI system trained on large amounts of text that understands, generates and classifies language.

Lighthouse

brand

Lighthouse is a website auditing tool that measures performance, accessibility, best practices and search engine friendliness.

lint

term

Lint is a tool that automatically checks code for common mistakes and messy style without running it.

M

mail security

term

Mail security covers the technical measures that stop outsiders from forging or reading email sent in a domain's name.

manual start

term

A manual start means a process does not begin automatically but only after a person deliberately triggers it.

map layer

term

A map layer is a separate, overlayable layer of information on a digital map, such as parcel boundaries.

MCP

term

The Model Context Protocol (MCP) is an open standard that lets AI applications access external tools and data sources in a consistent way.

messaging

term

Messaging refers to the technical exchange of messages between programs, usually through a queue rather than directly.

messenger bot

term

A messenger bot is a bot that receives and answers messages through a chat service such as Telegram or WhatsApp.

Microsoft 365

brand

Microsoft 365 is Microsoft's subscription service bundling mail, office applications and other cloud services.

monitoring

term

Monitoring is the ongoing, automated observation of a system to catch problems early.

MVP

term

An MVP (minimum viable product) is the smallest version of a product that already delivers real value and so can be tested.

MX

term

An MX record is a DNS record that specifies which server accepts mail for a domain.

N

n8n

brand

n8n is workflow automation software in which individual steps are connected as nodes in a workflow.

O

offline web app

term

An offline web app runs in the browser but stores everything on the device itself, so it keeps working without a network connection.

OIDC

term

OpenID Connect (OIDC) is a standard for proving an identity to a service without storing a separate password with it.

Open Food Facts

brand

Open Food Facts is an open, collaboratively maintained database of information about food products.

open geodata

term

Open geodata is official, location-based data such as parcel boundaries that government bodies publish freely for anyone to use.

OpenAI

brand

OpenAI is a company that provides AI language models and related services such as speech recognition and image analysis.

P

passkey

term

A passkey is a passwordless sign-in method stored on a device that cannot be intercepted the way a password can.

Permissions-Policy

term

The Permissions-Policy is a browser instruction that switches off individual features such as camera or location for a page.

pgvector

brand

pgvector is a PostgreSQL extension that stores vectors and supports similarity search over them.

pipeline

term

A pipeline is a chain of automated steps, such as checks and deployment, that run in sequence on every change.

Podman

brand

Podman is software for building and running containers, similar to Docker but without a permanently running background service.

PostgreSQL

brand

PostgreSQL is an open-source relational database system that stores data in structured tables.

prompt engineering

term

Prompt engineering is the deliberate wording of the instruction given to a language model so it produces the desired answer.

provider

term

A provider supplies a particular resource or service, for example a software component that manages a cloud resource.

pull request

term

A pull request is a proposal to merge a specific code change into the main version, which is decided on only after review.

Python

term

Python is a widely used programming language, applied among other things to automation, data analysis and AI.

R

RabbitMQ

brand

RabbitMQ is a message broker that routes messages between systems through queues.

RAG (retrieval-augmented generation)

term

RAG means that a language model first looks up relevant passages in a knowledge source of its own and bases its answer on them.

rate limiting

term

Rate limiting allows a sender only a limited number of requests in a given time, to prevent abuse or overload.

RBAC

term

RBAC (role-based access control) grants permissions to roles rather than individual people, who are then assigned to those roles.

React

brand

React is a JavaScript library for building user interfaces out of reusable components.

Referrer-Policy

term

The Referrer-Policy is a browser instruction that limits which address is passed on when moving to another website.

repository

term

A repository is a folder holding a project's entire code, with every earlier version kept alongside it.

reverse proxy

term

A reverse proxy receives incoming requests on behalf of the applications behind it and forwards them, typically adding an encrypted connection and security rules.

review agent

term

A review agent is an AI agent that independently checks code changes, for example for tests, configuration errors, and security issues. Sign-off stays with a person.

root

term

Root is the user account on a computer with unrestricted rights, which is deliberately avoided for everyday operation.

router

term

A router here is a program step that checks an incoming message and forwards it to the correct next step.

S

sandbox

term

A sandbox is an isolated test environment where a program can be tried out without putting real data or systems at risk.

scope

term

Scope is the defined extent of a project, meaning what is explicitly included and what is not.

Scrum

term

Scrum is a project framework that organizes work into fixed, short iterations with defined roles and routines.

secondary domain

term

A secondary domain is an extra address that is not used itself but is deliberately locked against mail spoofing, so nobody can send messages in its name.

secrets management

term

Secrets management is the secure, controlled handling of passwords, keys and other credentials so they are never left openly visible.

security header

term

Security headers are extra instructions a website sends to the browser when it loads, to block certain kinds of attacks.

self-service

term

Self-service means users can request a resource themselves through a form or tool, without another team having to set it up by hand.

SEO

term

SEO (search engine optimization) covers the measures that make a website easier to find in search engine results such as Google's.

ShellCheck

brand

ShellCheck is a tool that checks shell scripts for common mistakes and unsafe patterns.

SOPS

brand

SOPS encrypts secrets in configuration files so they can safely live in a Git repository. It often uses age, a lightweight encryption tool, as the key mechanism.

SPF

term

SPF is a DNS record that specifies which servers are allowed to send mail on behalf of a domain.

SQL

term

SQL is the query language used to read and modify data in relational databases.

SSH

term

SSH is a protocol for encrypted connections between computers, used for example for remote access or signing commits.

SSH tunnel

term

An SSH tunnel is an encrypted connection that lets a system be reached securely from a distance, without exposing it openly to the internet.

static analysis

term

Static analysis automatically checks code for common mistakes and suspicious patterns without actually running it.

streaming

term

Streaming here means processing data continuously in small pieces, instead of waiting until all of it has arrived.

T

Tailscale

brand

Tailscale is software that connects devices to each other over a private, encrypted network.

Telegram Bot API

brand

The Telegram Bot API is an interface provided by the Telegram messenger that connects automated accounts to chats.

TLS

term

TLS is the protocol that encrypts connections on the web and makes HTTPS possible.

token

term

A token is a time-limited digital pass that lets a program prove its identity to another system without storing a permanent password.

tool approval

term

A tool approval defines exactly which tools an AI agent is allowed to use, instead of giving it unrestricted access.

transferSize

term

transferSize is a browser measurement of the amount of data actually sent over the network for a file, including headers.

two-factor authentication

term

Two-factor authentication asks for a second proof besides the password when signing in, such as a code on a phone.

TypeScript

brand

TypeScript is a programming language that adds types to JavaScript and is compiled to JavaScript before it runs.

U

unit test

term

A unit test automatically checks whether one small part of a program does exactly what it is supposed to do.

Uptime Kuma

brand

Uptime Kuma is open-source software that monitors whether services are reachable and alerts on outages.

V

vector database

term

A vector database stores content as numeric vectors and finds similar entries, rather than searching for exact matches.

W

webhook

term

A webhook is an address that a service automatically sends a message to as soon as a specific event happens.

WFS

term

WFS (Web Feature Service) is a standardized interface for querying geographic data, such as land parcels, from a server.

Whisper

brand

Whisper is an OpenAI model that transcribes spoken audio into text.

workflow

term

A workflow is a defined sequence of steps that automates or structures a process.

workflow design

term

Workflow design is the work of planning the individual steps of a workflow so they work together reliably and traceably.

Workload Identity Federation

term

Workload Identity Federation lets an application derive its identity from its runtime environment and exchange it for short-lived tokens, instead of storing long-lived access keys.

X

X-Content-Type-Options

term

X-Content-Type-Options is a browser instruction that stops a file from being treated as a different, more dangerous file type.

X-Frame-Options

term

X-Frame-Options is a browser instruction that prevents a page from being embedded invisibly inside another site.

xAI Grok

brand

Grok is an AI language model from the company xAI.

Y

YAML

term

YAML is a human-readable text format commonly used for configuration files.

Pfeiltasten wählen · Eingabe öffnet · Esc schließt

Tastenkürzel

Strg + K oder ⌘ + K
Befehlspalette öffnen
Esc
Palette, Menü oder Dialog schließen
Tab und Umschalt + Tab
durch Links und Bedienelemente gehen
Pfeiltasten
in Palette, Filter und Diagramm wählen
Eingabe oder Leertaste
gewähltes Element öffnen oder umschalten

Einzeltasten

/
Befehlspalette öffnen
?
Diese Übersicht öffnen

Diese beiden Tasten wirken nur außerhalb von Eingabefeldern. Wenn sie Ihnen in die Quere kommen, schalten Sie sie hier ab.

Es gibt bewusst keine Kürzel mit einzelnen Buchstaben. Sie würden Bildschirmlesern und Spracheingabe in die Quere kommen.

Arrow keys to select · Enter to open · Esc to close

Keyboard shortcuts

Ctrl + K or ⌘ + K
Open command palette
Esc
Close palette, menu or dialog
Tab and Shift + Tab
move through links and controls
Arrow keys
select in palette, filters and diagram
Enter or Space
open or toggle the selected item

Single keys

/
Open command palette
?
Open this overview

These two keys only work outside input fields. If they get in your way, switch them off here.

There are deliberately no single-letter shortcuts. They would get in the way of screen readers and voice input.