biotools GmbH

AI-as-a-Service für die Bio-Branche

biotools baut spezialisierte KI-Werkzeuge für Bio-Betriebe im DACH-Raum. Wir verbinden Compliance-Begleitung, Operations-Software und Vertriebskonzepte zu einem integrierten System — gesteuert von Agenten, kontrolliert von Menschen.

Unser Fokus: Bio-Lieferdienste, Hofläden, Erzeuger und kleine Manufakturen, die regulatorische Sicherheit und effiziente Abläufe brauchen, ohne eigene IT-Abteilung.

Geplante Konstellation: Thomas Siepmann · Kurt Lorenz · Lukas
Projekt in Vorbereitung — noch keine gegründete Gesellschaft

Was wir bauen

Drei Produktlinien für die Bio-Branche

Kistengenerator

Abo-Kisten-Verwaltung für Bio-Lieferdienste. Automatisiert Zusammenstellung, Bestellverwaltung und Auslieferungsplanung. Pro Kunde eigene Instanz mit separater Datenbank.

In Entwicklung

Nachbarschaft-Hub

Komplettes Beratungs- und Software-Paket für Bio-Lieferdienste, die über Botschafter-Abholpunkte wachsen wollen. Konzept-Workshop, App-Vorlage, 12 Wochen Pilot-Begleitung.

Geplant

BioZert-Begleiter

KI-gestützter Compliance-Agent für die EU-Öko-Verordnung 2018/848. Beantwortet Zertifizierungsfragen aus einer geprüften Wissensbasis — immer mit Verweis an die zuständige Kontrollstelle.

Prototyp aktiv

Wie wir arbeiten

Agenten-Hierarchie mit menschlicher Kontrolle

BOARD (MENSCH) CEO-AGENT PRODUKT-AGENTEN (PRO MANDANT) Thomas · Kurt · Lukas Helios CEO-AGENT 5 €/Tag · 4h Heartbeat Vesta SALES-MANAGER Lead-Suche · Outreach · Hub AKTIV Faber PRODUCT-MANAGER Kistengenerator · QA · Hub-Tech GEPLANT Lyra MARKETING-MANAGER Content · Social · SEO GEPLANT Norma OPERATIONS-MANAGER Rechnungen · Support GEPLANT Lead-Scout Recherche AKTIV Outreach Erst-Mails GEPLANT Hub-Berater Qualifizierung GEPLANT + Angebot-Drafter · Follow-up-Agent (geplant) BioZert-Begleiter COMPLIANCE-AGENT EU-Öko-VO · RAG · Enforcer PROTOTYP AKTIV Audit-Vorbereiter COMPLIANCE Audit-Checklisten GEPLANT DSGVO-Begleiter COMPLIANCE DSGVO · BDSG GEPLANT AI Act-Begleiter COMPLIANCE Risikoklassen GEPLANT Aktiv Geplant Produkt-Agent Berichtsweg

biotools folgt einer Paperclip-Architektur: Ein CEO-Agent (Helios) plant die Woche, verteilt Aufgaben als Tickets an vier Manager-Agenten, die jeweils spezialisierte Worker koordinieren. Jeder Agent hat ein festes Budget, einen regelmäßigen Heartbeat und klare Einschränkungen.

Menschliche Kontrolle ist zentral. Das Board (drei Gründer) setzt die Ziele, genehmigt Eskalationen und hat jederzeit die Möglichkeit zur Notfall-Abschaltung. Helios sieht nur aggregierte Manager-Reports — nie einzelne Worker-Logs oder Mandanten-Daten.

Produkt-Agenten wie der BioZert-Begleiter stehen außerhalb der internen Hierarchie. Sie laufen pro Mandant in eigenen Instanzen, mit eigener Wissensbasis und immer hinter dem Disclaimer-Enforcer. Keine Antwort erreicht den Nutzer ohne Qualitätsprüfung.

Budget-Leitplanken: Helios hat ein Drei-Stufen-Budget (5 €/Tag, 25 €/Woche, 80 €/Monat). Bei 80 % Auslastung wird automatisch ans Board eskaliert. Zwischen zwei Worker-Einstellungen müssen mindestens 48 Stunden liegen.

Workflow-Demo

Kistengenerator-Vermarktung in 7 Schritten — klicken Sie auf einen Schritt für Details

1
Auftrag eingeht
Board → Helios

Das Board formuliert ein Quartalsziel in config/board-goals.yaml: „Vermarkte den Kistengenerator an Bio-Lieferdienste in DACH." Helios liest dieses Ziel bei seinem nächsten Heartbeat-Zyklus.

helios.reviewBoardGoals()

Erzeugte Daten: Board-Ziel mit Priorität, Deadline und zuständigem Manager wird im Audit-Log protokolliert.

Grenze: Helios plant nur — er kontaktiert nie selbst Kunden und sieht keine Mandanten-Daten.
2
Helios teilt auf
Helios → Vesta (Ticket)

Helios erstellt einen Wochenplan per LLM-Call und übersetzt das Board-Ziel in konkrete Aufgaben. Für die Kistengenerator-Vermarktung erzeugt er ein Ticket an Vesta mit dem Auftrag, Leads in der DACH-Region zu identifizieren.

helios.planWeek(kwNumber, schwerpunkt)
helios.assignToManager('vesta', titel, beschreibung)

Erzeugte Daten: Wochenplan als Markdown-Draft in /drafts/helios/wochenplan-KW*.md. Ticket in der PostgreSQL-Datenbank mit von_agent: 'helios', an_agent: 'vesta', Status 'open'.

Grenzen: Tages-Budget 500 Cent (5 €). Bei 80 % Auslastung automatische Eskalation ans Board via checkAndEscalateBudget(). Heartbeat prüft Panic-State vor jedem LLM-Call.
3
Vesta verteilt an Worker
Vesta → Lead-Scout (Sub-Ticket)

Bei Vestas nächstem Heartbeat (alle 2 Stunden) liest sie offene Tickets. Die Keyword-basierte Routing-Logik erkennt „Leads" + „DACH" und weist das Ticket dem Lead-Scout zu. Ein Sub-Ticket wird mit parent_ticket_id-Verknüpfung erstellt.

vesta.processIncomingTickets()
vesta.routeToWorker(titel, beschreibung)
vesta.delegateToWorker('lead-scout', ...)

Erzeugte Daten: Sub-Ticket in PostgreSQL mit an_agent: 'lead-scout' und den Worker-Einschränkungen im payload_json: „Keine Cold-Calls", „Nicht in Profile einbrechen".

Grenze: Parent-Ticket wird auf 'in_progress' gesetzt. Vestas Heartbeat prüft bei jedem Zyklus, ob Sub-Tickets blockiert sind — wenn ja, wird der Parent ebenfalls blockiert.
4
Lead-Scout recherchiert und qualifiziert
Lead-Scout → CSV-Lead-Liste

Der Lead-Scout verarbeitet sein Ticket, ruft das LLM auf und generiert eine Lead-Liste im CSV-Format: Name, Kategorie, Region, Eignungs-Score (1–10), Quelle, Notizen. Im Dummy-Modus werden realistische aber fiktive Leads erzeugt.

leadScout.searchLeads({ region: 'DACH' })
leadScout.parseCsvResponse(llmOutput)

Für Hub-Interessenten führt Vesta zusätzlich die 5-Kriterien-Qualifikation durch: Lieferdienst-Größe, Region (DACH), bestehende Abholpunkte, Tech-Reife, Budget-Passung. Ab 3 von 5 Punkten gilt ein Lead als qualifiziert.

vesta.qualifyHubLead({ lieferdienstGroesse, region, ... })

Erzeugte Daten: CSV-Datei in /drafts/lead-scout/leads-dach-*.csv. Qualifikations-Ergebnis im Audit-Log mit Score und Detailbewertung.

Grenzen: Nur öffentlich verfügbare Informationen. Keine Cold-Calls. Score-Werte werden auf 1–10 geclamped. Lead-Scout setzt sein Ticket auf 'completed' bei Erfolg, auf 'blocked' bei Fehler.
5
Vesta erstellt Angebot
Vesta → Angebots-Draft + Enforcer

Für qualifizierte Leads erstellt Vesta ein individualisiertes Angebot. Die gesamte Preisliste aus config/preisliste.yaml wird dem LLM-Call übergeben — der System-Prompt betont: „Verwende ausschließlich Preise aus der Preisliste."

vesta.draftAngebot(produktKey, kundenKategorie)

Der Kistengenerator Basis kostet 290 € Setup + 39 €/Monat. Das Nachbarschaft-Hub Komplett: 4.900 € einmalig + 99 €/Monat ab Monat 4. Alle Preise kommen aus der YAML-Datei, nicht aus dem LLM.

Erzeugte Daten: Angebots-Markdown in /drafts/vesta/angebot-*.md. Token-Verbrauch wird auf Vestas Budget (60 €/Monat) angerechnet.

Grenze: Im Dummy-Modus wird das Angebot nie versendet — es landet ausschließlich als Draft-Datei auf dem Server. Preise dürfen niemals erfunden werden. Das Modus-System blockiert externen Versand auf Netzwerk-Ebene.
6
Menschliche Freigabe
Board → manuelle Prüfung

Kein Agent bei biotools versendet selbständig Angebote, E-Mails oder Verträge an Kunden. Alles was nach außen geht, durchläuft eine menschliche Prüfung. Die Gründer sichten den Draft in /drafts/vesta/, passen ggf. an und geben den Versand manuell frei.

Dieser Schritt ist bewusst nicht automatisiert. Er ist das Kernprinzip von biotools: Agenten verstärken, Menschen entscheiden.

Erzeugte Daten: Keine — der Mensch liest, prüft, entscheidet.

Grenze: Der Modus-Schalter (BIOTOOLS_MODE=dummy) verhindert externen Versand auf System-Ebene. Selbst wenn ein Agent versuchen würde, eine E-Mail zu senden, wird der Call von der Modus-Middleware blockiert. Im Staging-Modus sind nur Whitelist-Adressen erlaubt.
7
Manager-Report an Helios
Vesta → Helios → Board (Wochenbericht)

Vesta aggregiert den Status aller Worker-Tickets: offene, abgeschlossene, blockierte Aufgaben. Der Report wird als JSON-Draft gespeichert. Helios liest diese Manager-Reports bei seinem 4-Stunden-Heartbeat und erstellt daraus einen Wochenbericht für das Board.

vesta.generateManagerReport()
vesta.collectWorkerStatus()
helios.generateWeeklyReport(kwNumber)
helios.collectManagerReports()

Erzeugte Daten: Manager-Report in /drafts/vesta/manager-report-*.json. Wochenbericht in /drafts/helios/wochenbericht-KW*.md. Bei blockierten Tickets: automatische Eskalation ans Board.

Grenze: Helios sieht nur die Aggregation (z.B. „Vesta: 3 offen, 1 abgeschlossen, 0 blockiert") — nie einzelne Worker-Tickets, nie Mandanten-Daten, nie Lead-Details. Das ist die Sichtbarkeitsregel aus der Architektur.

Vertrauen & Compliance

Wie wir Qualität und Transparenz sicherstellen

Disclaimer-Enforcer

Jede Antwort unserer Compliance-Agenten durchläuft einen technischen Filter. Verbotene Phrasen wie „rechtssicher", „garantiert" oder „ist konform" werden automatisch abgefangen. Kein Compliance-Output erreicht den Nutzer ohne Prüfung.

Audit-Log mit Hash-Kette

Jede Aktion jedes Agenten wird in einem manipulationssicheren Log protokolliert. Jede Zeile enthält den SHA-256-Hash der Vorgängerzeile. Nachträgliche Änderungen sind erkennbar — bei internen Audits und bei Behördenanfragen.

KI-Kennzeichnung (AI Act Art. 50)

Jede von unseren Agenten generierte Antwort trägt einen Footer mit KI-Kennzeichnung, Wissensbasis-Version und Verweis auf die zuständige Fachstelle. Transparenz ist gesetzliche Pflicht — und unser Standard.

DSGVO & Datenhoheit

Alle Daten bleiben auf Servern in Deutschland (Hetzner). LLM-Aufrufe laufen durch einen Scrubbing-Proxy, der personenbezogene Daten vor dem Versand an den KI-Anbieter entfernt. Pro Mandant separate Datenbank, separate Postgres-Rolle — keine mandantenübergreifenden Abfragen.

Notfall-Abschaltung

Ein einziger Befehl stoppt den gesamten Betrieb sofort. Alle Agenten, alle LLM-Verbindungen, alle Heartbeats. Wiederaufnahme nur mit Passphrase — auch nach Server-Neustart.

264

Tests grün

Disclaimer-Enforcer, Audit-Log, Panic-Button, Budget-Logik, Ticket-System, Agenten-Heartbeats — alles automatisiert getestet. Kein Agent geht in Betrieb ohne grüne Test-Suite.