Sindy: ein KI-Agent als Kollegin im Betrieb einer Zahnklinik

Über KI-Agenten wird heute vor allem im Zusammenhang mit Kundensupport und Softwareentwicklung gesprochen. Uns hat eine langweiligere und vielleicht nützlichere Frage interessiert: Was würde ein KI-Agent als ganz normaler Kollege im Betrieb einer kleineren Firma tun? Kein Chatbot auf der Website, sondern jemand, der einmal pro Woche das Mittagessen bestellt, morgens eine Zusammenfassung schickt und abends Unterlagen für die Leitung vorbereitet.

Ausprobiert haben wir das in einer Zahnklinik. Entstanden ist Sindy, eine interne KI-Assistentin, mit der das Team im Chat schreibt wie mit allen anderen auch. Sie ist ein Prototyp, gebaut in wenigen Wochen, kein fertiges Produkt. Gerade deshalb sieht man an ihr gut, was funktioniert, was nicht und wo ein KI-Agent im Betriebsalltag wirklich Sinn ergibt.

Was Sindy macht

Sindy ist das Gesicht, das das Team kennt. Hinter ihr läuft eine kleine Plattform aus mehreren spezialisierten Agenten, die Daten und Werkzeuge teilen:

• Mittagessen: Jede Woche verarbeitet sie den Speiseplan des Lieferanten, startet die Abstimmung, schließt am Montagmorgen die Bestellung ab, schickt sie an den Lieferanten und erstellt am Monatsende die Kostenaufteilung.
• Berichte für die Leitung: tägliche Übersichten nach Bereichen (Personal, Betrieb, Finanzen, Marketing), eine laufende Liste offener Punkte und eine Montagszusammenfassung der Woche für das ganze Team.
• HR-System: Der HR-Agent arbeitet über dessen offiziellen MCP-Server mit dem HR-System der Klinik, der Montagsbericht holt sich daraus die gearbeiteten Stunden.
• Alltägliche Kommunikation: Im Team-Chat antwortet Sindy, wenn man sie anspricht, und reagiert ab und zu kurz auf einen Geburtstag oder einen guten Witz. Sonst schweigt sie.

Mittagessen: der dankbarste Use Case

Die Essensbestellung wirkt wie eine Kleinigkeit, hat aber einen festen Wochenrhythmus, Fristen, E-Mails mit dem Lieferanten und viele kleine Ausnahmen. Der ganze Ablauf ist jetzt automatisiert:

• Der Lieferant schickt den Speiseplan für die nächste Woche als Excel-Datei per E-Mail. Sindy prüft täglich um 16 Uhr das Postfach und verarbeitet einen neuen Plan.
• Sie postet eine Einleitungsnachricht in den Team-Chat, darunter eine Abstimmung für jeden Tag (Montag bis Freitag), und pinnt die Nachricht an, damit sie im Verlauf nicht untergeht.
• Das Änderungsfenster schließt am Montag um 7 Uhr. Bis dahin kann jeder seine Wahl ändern. Dann zählt Sindy die Stimmen, erzeugt die Bestellung für den Lieferanten und einen Ausdruck für die Rezeption, verschickt beides per E-Mail und löst die Abstimmung wieder.
• An jedem Werktag um 11 Uhr schickt sie eine kurze Übersicht, wer heute welches Essen bekommt. Während des Arbeitstags prüft sie, ob sich nach dem Versand der Bestellung etwas geändert hat, und meldet Änderungen per E-Mail an die Rezeption.
• Am Monatsersten erstellt sie die Kostenaufteilung des Vormonats als Excel-Datei.

Am spannendsten ist die Essensbörse. Nach der Frist ist das Essen bezahlt, wird also nicht storniert, sondern nur weitergegeben. Wer nicht kann, sagt es Sindy, sie bietet das Essen den anderen an, und wer zuerst „nehme ich“ schreibt, bekommt es. Die Übergabe fließt automatisch in die Tagesübersicht und die monatliche Kostenaufteilung ein.

Entscheidend ist, wie Sindy Bestellungen ändert. Sie darf nur die Bestellung der Person bearbeiten, die ihr gerade schreibt. Die Identität leitet nicht das Modell aus dem Text ab, sondern das Werkzeug aus der Nachrichten-ID: Nachricht, Absender, Mitarbeiter. Fremde Bestellungen zu ändern ist in ihren Berechtigungen ausdrücklich verboten. Und ihre Persona schreibt vor, dass sie nicht „erledigt“ sagen darf, bevor das Werkzeug OK zurückgibt.

Berichte: aus Gesprächen eine Übersicht für die Leitung

Die andere Hälfte der Arbeit ist analytisch. Tagsüber schreibt das Team über Schichten, ein defektes Gerät, ausgehendes Material oder eine Rückfrage der Krankenkasse. Daraus kann die Leitung kaum eine Übersicht machen. Sindy schon:

• Jede Stunde geht ein kleineres Modell (Claude Haiku) die neuen Nachrichten durch und sortiert sie nach Bereichen in Signale: Personal, Betrieb, Finanzen, Marketing, Sonstiges. Für jedes bestimmt es die Wichtigkeit und ob Handlungsbedarf besteht.
• Jeden Abend um 20 Uhr erstellt ein größeres Modell (Claude Sonnet) daraus einen Tagesbericht pro Bereich und aktualisiert die laufende Liste offener Punkte.
• Am Montag um 8 Uhr bekommt das ganze Team eine Zusammenfassung der Vorwoche: wie viele verschiedene Patienten behandelt wurden, Behandlungsstunden aus der Praxissoftware (nur Aggregate, keine Namen), gearbeitete Stunden aus dem HR-System und mit einem Augenzwinkern die besten Witzbolde der Woche nach Emoji-Reaktionen.

Die Berichte erscheinen auf einem einfachen internen Dashboard, das nur auf localhost lauscht und über Cloudflare Tunnel mit Anmeldung über Cloudflare Access erreichbar ist. Der Finanz- und der Marketing-Agent beantworten außerdem Ad-hoc-Fragen an die Betriebsdatenbank der Klinik, etwa neue Patienten nach Monaten, und schicken das Ergebnis als Excel-Datei.

Das HR-System und die anderen Agenten

Die Agenten haben klar getrennte Rollen: HR, Betrieb, Finanzen, Marketing und ein Admin-Agent, der sich um die Plattform selbst kümmert. Die Leitung spricht mit ihnen über Claude Code Remote Control, im Browser oder auf dem Handy, jeder Agent in einer eigenen Session mit eigenen Berechtigungen.

Der HR-Agent ist an den offiziellen MCP-Server des HR-Systems der Klinik angebunden. Er kann Daten lesen und ändern (etwa Abwesenheiten), seine Persona erlaubt Schreibzugriffe aber nur auf ausdrückliche Anweisung und mit vorheriger Zusammenfassung der Änderung. Das HR-System hilft auch anderswo: Sindy ordnet darüber Personen im Chat den Mitarbeitenden zu, damit Bestellung und Kostenaufteilung echte Namen tragen. Telefonnummern werden dabei nur intern zum Abgleich verwendet und erscheinen nie in einer Ausgabe.

Für den Montagsbericht sind wir allerdings von MCP auf die REST-API desselben Systems umgestiegen. Eine Abfrage in natürlicher Sprache über MCP ist bequem für einen Menschen, der etwas fragt. Ein Bericht, der jede Woche dieselben Zahlen auf dieselbe Weise liefern soll, braucht deterministische Aufrufe.

Wie sie gebaut ist

An Sindy ist nichts exotisch, und das ist Absicht:

• Eine Linux-VM in Azure; alle Prozesse laufen unter einem einzigen unprivilegierten Benutzer als systemd-Services und -Timer. Ein verpasster Lauf wird nach einem Neustart der VM nachgeholt.
• Claude Code als Laufzeitumgebung der Agenten. Geplante Jobs rufen claude -p im nicht-interaktiven Modus auf, interaktive Agenten laufen als Remote-Control-Sessions. Jeder Agent ist ein Verzeichnis mit Anweisungen und einer Berechtigungsdatei.
• Eine einzige SQLite-Datenbank (WAL) als gemeinsamer Bus: Nachrichten, Abstimmungen, Signale. Drumherum kleine Skripte in Node.js und Python; die ganze Plattform hat rund 2.300 Zeilen Code.
• Die Gesprächsschleife schaut alle 5 Sekunden nach neuen Nachrichten, antwortet aber erst 20 Sekunden nach der letzten, damit sie nicht auf einen halben Gedanken reagiert. Sie bekommt die letzten 30 Nachrichten als Kontext und liefert entweder eine Aktion oder NOOP. Als Schutz vor Endlosschleifen gilt pro Agent ein Limit von 40 gesendeten Nachrichten pro Stunde, die Session wird täglich zurückgesetzt.
• Nur lesender Zugriff auf die Betriebsdatenbank: passwortlose Anmeldung über die Managed Identity der VM, eine Datenbankrolle mit Read-only-Transaktionen und reinen SELECT-Rechten, Timeout von 20 Sekunden. Die Prüfung im Skript sehen wir als Bonus, der eigentliche Schutz liegt in der Datenbank.

Zwei Details halten wir für die wichtigsten. Erstens werden E-Mail-Adressen, Telefonnummern, Geburtsnummern und Versichertennummern aus dem Text entfernt, bevor er an das Modell geht. Zweitens ist die Installation in einen unprivilegierten Teil und ein Root-Skript aufgeteilt, das einmalig von Hand installiert wird und nur systemd-Units akzeptiert, die festen Regeln entsprechen. Ein Agent, der unter demselben Benutzer läuft wie die Plattform, kann sich so nicht selbst mehr Rechte verschaffen.

Persönlichkeit in Markdown, Regeln in der Konfiguration

Die „Persönlichkeit“ eines Agenten ist nichts Geheimnisvolles. Es sind ein paar Markdown-Dateien im Repository:

• Gemeinsame Regeln für alle Agenten (keine Patientennamen, keine Kontaktdaten ausgeben, nichts erfinden, Quelle nennen).
• Eine kurze Rollen-Persona für den Abendbericht, z. B. „Betriebsassistent des Managers: nach Themen gruppieren, dringend / diese Woche / irgendwann unterscheiden“.
• Eine Gesprächs-Persona: bei Sindy „nett, freundlich und ein bisschen witzig, schreibt kurz, duzt, ab und zu ein Emoji, nicht geschwätzig“. Vor allem aber regelt sie, wann gesprochen wird: Antworte, wenn du angesprochen wirst; bei einem besonderen geselligen Moment darfst du kurz reagieren; sonst tu nichts. Gib dich nie als Mensch aus.

Die Anweisungen jedes Agenten werden mit einem einzigen Befehl aus diesen Teilen zusammengesetzt, gemeinsame Regeln werden also nie von Hand kopiert. Neben der Persona liegt eine Berechtigungsdatei: welche Befehle der Agent ausführen darf, wohin er schreiben darf und was verboten ist (Löschen, sudo, Netzwerktools, Secrets). Die Persona beschreibt, wie sich der Agent verhalten soll. Die Berechtigungen legen fest, was er technisch überhaupt tun kann. Auf das Erste kann man sich meistens verlassen, auf das Zweite immer.

Was wir gelernt haben

• Die meisten Fehler macht nicht das Modell, sondern die Integration. Einmal kamen Burger statt Spaghetti. Wir hatten die Bestellung als Vorlage des Lieferanten verschickt, die eine Bibliothek neu gespeichert hatte, und Excel meldete sie als beschädigt. Der Lieferant nutzte den Anhang nicht, und im E-Mail-Text standen nur Gerichtsnummern, die bei ihm anders nummeriert waren. Die Lösung war eine saubere neue Arbeitsmappe und die Namen der Gerichte direkt im E-Mail-Text, damit die Bestellung auch ohne Anhang eindeutig ist.
• Identität ist schwieriger, als sie aussieht. Eine Person hat von zwei Geräten abgestimmt, und eine leere Auswahl auf dem einen überschrieb die Bestellung vom anderen. Jetzt gewinnt die neueste echte Wahl, und Abwählen überschreibt nichts.
• Wo dasselbe Ergebnis gebraucht wird, gehört deterministischer Code hin. Der Namensabgleich über das Modell schwankte zwischen den Läufen, also bleibt ein einmal gefundener Name erhalten, und die Liste wird nie von einer Version mit weniger Namen überschrieben. Der Bericht holt seine Zahlen über REST, nicht über ein Gespräch.
• Idempotenz überall, wo etwas nach außen geht. Der Bestellabschluss speichert seinen Fortschritt Schritt für Schritt, sodass die Bestellung nach einem Ausfall nie doppelt an den Lieferanten geht.
• Betriebsgrundlagen ab dem ersten Tag: Ein Watchdog prüft alle 10 Minuten Dienste und Festplatte und schickt eine E-Mail; tägliche Backups werden 14 Tage aufbewahrt. Eine Off-site-Kopie der Backups steht noch auf der Aufgabenliste, das gehört bei einem Prototyp ehrlicherweise dazu.

Wann es sinnvoll ist (und wann nicht)

Sindy ist schnell entstanden: Das Repository hat 54 Commits, der erste vom 10. September 2026, und der Großteil der Arbeit fiel in die erste Woche. Die Geschwindigkeit kam aber nicht von der KI, sondern davon, dass wir Aufgaben mit klaren Grenzen gewählt haben.

Sinnvoll ist es, wenn sich ein Prozess jede Woche wiederholt, einen klaren Anfang und ein klares Ende hat (Frist, Bericht), die Eingaben schon existieren (E-Mail, Chat, Datenbank) und ein Fehler umkehrbar ist oder ein Mensch ihn sieht, bevor er Folgen hat. Mittagessen, Wochenübersichten und das Sortieren der Betriebskommunikation erfüllen alles.

Nicht sinnvoll ist es, wo der Agent ohne menschliche Kontrolle über etwas Unumkehrbares entscheiden würde, wo Daten fehlen oder wo es um medizinische oder rechtliche Beratung geht. Sindys Persona verbietet solche Dinge ausdrücklich, und technisch hat sie darauf keinen Zugriff.

Wenn Sie über einen ähnlichen Assistenten nachdenken, beginnen Sie mit einem langweiligen Prozess, der heute jemanden eine Stunde pro Woche kostet. Versuchen Sie aufzuschreiben, was genau der Agent tun soll, aus welchen Daten und wer das Ergebnis sieht. Passt das auf eine halbe Seite, ist es ein guter Kandidat. Bei Konzept und Umsetzung helfen wir gern, siehe KI-Agenten und Automatisierung.