Unsere Arbeit

Wir haben die KI- und ML-Pipeline entwickelt, die ein Modell auf H&E-gefärbten Krebs-Biopsie-Scans trainiert, um die Ansprechwahrscheinlichkeit auf eine Therapie vorherzusagen.

Kontext

Eine europäische CRO im Bereich Krebsbiopsien wollte wissen, ob das Gewebe selbst genug Signal trägt, um vor Therapiebeginn zu sagen, welche Patientinnen und Patienten wahrscheinlich ansprechen. Der Eingang ist das Routineprodukt jedes Pathologielabors: H&E-gefärbte Biopsie-Schnitte, hochauflösend digitalisiert. Es wird nichts neu erhoben, und genau das macht die Frage lohnend. Liegt die Antwort in Material, das ohnehin existiert, ist der Weg von der Forschung in die Anwendung deutlich kürzer als bei einem neuen Assay.

Herausforderung

Drei Eigenschaften machen die Aufgabe schwerer als eine übliche Bildklassifikation. Ein Whole-Slide-Scan ist viel zu groß, um ihn einem Modell direkt vorzulegen; jeder Schnitt muss in Kacheln zerlegt und aus den Kacheln wieder eine Vorhersage pro Patient zusammengesetzt werden. Das Label steckt nicht im Bild: Das Ansprechen ist ein klinisches Ergebnis, das später erhoben wird, jeder Schnitt ist also nur schwach gelabelt und das Modell muss das Signal finden, ohne dass ihm gesagt wird, wo es liegt. Und die Zahl der Patienten ist klein, auch wenn die Zahl der Kacheln sehr groß ist. Ein Modell kann die Kohorte also auswendig lernen, lange bevor es etwas Übertragbares lernt.

Vorgehen

Wir haben die Pipeline durchgängig gebaut. Einlesen und Qualitätskontrolle der Scans, Gewebesegmentierung zum Aussortieren von Hintergrund und Färbeartefakten, Kachelung mit Stain-Normalisierung, damit Schnitte verschiedener Scanner vergleichbar sind, Merkmalsextraktion über die Kacheln und ein Aggregationsschritt, der aus tausenden Kachel-Repräsentationen eine Vorhersage pro Patient macht. Gesplittet wird nach Patient und nie nach Kachel, damit dieselbe Person nicht auf beiden Seiten eines Splits auftaucht. Validierungsschema und Reporting-Metrik standen vor dem Trainingsstart fest. Daten und Code sind fixiert, jeder Trainingslauf ist protokolliert, und jede Zahl in einem Bericht lässt sich auf den Lauf zurückführen, der sie erzeugt hat. Der Aufbau der Pipeline ist der, den diese Klasse von Aufgaben verlangt: Whole-Slide-Image zu Kacheln, ein Pathologie-Feature-Encoder über die Kacheln, Attention-based Multiple Instance Learning zur Aggregation und am Ende eine Biomarker-Vorhersage pro Patient.

Ergebnis

Die Pipeline trainiert und bewertet ein Modell, das das Therapieansprechen allein aus dem Biopsie-Scan vorhersagt, und sie tut das reproduzierbar: gleiche Daten und gleicher Code ergeben wieder dieselben Zahlen. Validiert wird über eine Kreuzvalidierung auf Patientenebene gegen eine vor dem Training festgelegte Metrik, und der Held-out-Split blieb bis zum Schluss unangetastet. Die Arbeit war als technische Machbarkeitsstudie angelegt; Leistungszahlen daraus veröffentlichen wir nicht.

Stack

Durchgehend Python, mit versionierten Daten, fixierten Abhängigkeiten und protokollierten Experimentläufen. Der Partner hält Code, Modellgewichte und das vollständige Trainingsprotokoll und kann ohne uns nachtrainieren.

Wir haben Setup und Konzept für ein Joint Venture in der Real-World-Data-Forschung entworfen: Struktur, Umfang und Betriebsmodell.

Kontext

Real-World-Data im Gesundheitswesen sind für die Forschung wertvoll und organisatorisch unbequem. Die Daten liegen bei den Organisationen, die sie im Rahmen der Versorgung erzeugen, die Forschungsfragen liegen anderswo, und keine Partei kann allein handeln, ohne ein Risiko zu tragen, das sie lieber teilen würde. Ein Joint Venture ist eine Antwort darauf: eine eigene Einheit mit eigenem Auftrag, in die jeder Partner etwas einbringt, das er ohnehin hat. Unser Kunde wollte diese Einheit entworfen sehen, bevor er sich auf sie festlegt.

Herausforderung

Das Schwierige an einem Joint Venture ist nicht die Idee, sondern die Reihenfolge der Fragen. Was genau tut die Einheit, und was tut sie ausdrücklich nicht? Was bringt jeder Partner ein, und was bekommt er zurück? Wer entscheidet was, und was passiert bei Uneinigkeit? Wie gelangen Daten in die Einheit, ohne dass ein Partner die Kontrolle darüber oder seine eigene Compliance-Position verliert? Wer diese Fragen zu spät beantwortet, verhandelt das Venture nach dem Start neu. Das ist teuer und meist tödlich.

Vorgehen

Wir haben den Entwurf von den Forschungsfragen her rückwärts aufgebaut. Zuerst der Umfang: welche Fragen die Einheit beantworten soll und welche benachbarten ausdrücklich nicht. Dann das Beitragsmodell: was jeder Partner an Daten, Zugang, Fähigkeiten und Finanzierung einbringt und wie ein fairer Rückfluss darauf aussieht. Dann das Betriebsmodell: wie eine Studie vorgeschlagen, freigegeben und durchgeführt wird, wer sie besetzt und wie mit Ergebnissen umgegangen wird. Die Governance kam zuletzt, denn Governance beschreibt bereits verstandene Entscheidungen und ersetzt sie nicht. Jede Option steht mit ihrer Konsequenz im Dokument, damit die Partner zwischen beschriebenen Alternativen wählen und nicht auf eine Empfehlung reagieren.

Ergebnis

Der Kunde hat ein schriftliches Setup und Konzept für das Venture erhalten: Umfang, Beitragsmodell, Betriebsmodell und Governance, mit den offenen Punkten als benannte Entscheidungen statt als Fußnoten. Ein Dokument, gegen das die Partner verhandeln können.

Stack

Keine Software. Das Ergebnis ist schriftliche Arbeit: die Venture-Strategie, Umfang und Auftrag der Einheit, Rollen und Beiträge jeder Partei, eine Bewertung der Geschäftsopportunität und die Strukturierung eines Term Sheets, jeweils mit der Begründung, aus der sie entstanden sind.

Wir haben die Control Plane gebaut, die Coding-Agenten an echten Repositories arbeiten lässt: dauerhaft, isoliert und überprüfbar. Unsere eigene Auslieferung läuft darüber.

Kontext

Coding-Agenten können Code schreiben. Das ist nicht mehr der schwierige Teil. Schwierig ist alles darum herum, sobald mehr als einer an einem echten Repository arbeitet: Ein Agent, der unterbrochen wird, verliert Stunden Arbeit, zwei Agenten im selben Checkout überschreiben sich gegenseitig, und ein Agent mit Push-Rechten auf einen Hauptbranch ist ein Risiko, das keine Entwicklungsorganisation akzeptiert. Die übliche Antwort darauf ist, Agenten in einer Spielecke zu halten, in der sie keinen Schaden anrichten können — und damit auch keine Arbeit leisten. Uns interessierte die andere Antwort: Agenten an produktiven Repositories, mit den nötigen Einschränkungen im System statt im Prompt.

Herausforderung

Vier Eigenschaften müssen gleichzeitig gelten, und jede einzelne schließt die naheliegende Umsetzung aus. Lang laufende Arbeit muss Unterbrechungen überstehen, ein Lauf darf also kein Prozess sein, der mit seinem Terminal stirbt. Parallele Versuche müssen wirklich isoliert sein, dürfen sich also keinen Arbeitsbaum teilen. Ein Agent darf nicht über seine Aufgabe hinausgreifen, Datei- und Netzwerkzugriff müssen also durch etwas Stärkeres als eine Anweisung begrenzt sein. Und das Ergebnis muss als Vorschlag ankommen, den ein Mensch ablehnen kann, nicht als bereits angewandte Änderung. Das System braucht also einen Veröffentlichungsschritt, der strukturell nicht in der Lage ist, direkt auf einen Branch zu schreiben.

Vorgehen

Wir haben es als Control Plane gebaut, nicht als Wrapper. Arbeit ist als Sessions und Tasks modelliert, die ihren eigenen gespeicherten Kontext halten, auf Zuruf stoppen und fortsetzen und nach Abschluss unveränderlich werden — was ein Agent getan hat, lässt sich nachträglich nicht umschreiben. Jeder Versuch läuft in einem eigenen Git-Worktree gegen ein beim ersten Zugriff fixiertes Repository, Nebenläufigkeit ist damit eine Eigenschaft des Entwurfs und keine Frage der Disziplin. Die Ausführung ist mit Bubblewrap isoliert, was das Dateisystem begrenzt, ohne Container-Privilegien auf dem Host zu verlangen. Der Modellzugang liegt hinter einer Verbindungsabstraktion, Anbieter und Denktiefe sind damit Konfiguration statt Umbau. Veröffentlicht wird ausschließlich als Draft-Pull-Request hinter einem Freigabeschritt; einen Pfad, der auf einen Branch pusht, gibt es nicht. Prüf-Workflows je Repository bilden die Evaluationsschicht, und das Ganze wird über eigene CI-Qualitätsgates auf einen privaten Server ausgeliefert, der nur über ein privates Netz erreichbar ist.

Ergebnis

Die Control Plane läuft, und unsere eigene Auslieferung läuft darüber — sie ist das System hinter der Entwicklungsarbeit, die wir für Kunden machen, keine Demonstration zum Vorzeigen. Sie wird über dieselben Gates ausgeliefert, die sie selbst durchsetzt. Weil es interne Infrastruktur ist und kein Produkt mit Kundschaft, veröffentlichen wir dazu keine Durchsatz-, Nutzungs- oder Produktivitätszahlen. Was wir sagen, ist architektonisch, und genau dieser Teil ist übertragbar: dauerhafte Läufe, isolierte Arbeitsbereiche, begrenzte Ausführung und ein Veröffentlichungsschritt, dem ein Mensch zustimmen muss.

Stack

TypeScript auf Node, wobei Fastify die versionierte API und die Produktionsoberfläche aus einem Prozess ausliefert, dazu ein Frontend aus React und Vite. Bubblewrap zur Isolation, Git-Worktrees zur Trennung, systemd für den Dienst, privates HTTPS über ein Mesh-Netz und GitHub Actions für das qualitätsgeprüfte Deployment. Architekturentscheidungen sind als ADRs im Repository dokumentiert.

Wir haben eine Tanzkurs-Plattform durchgängig definiert und gebaut — Produktdesign, Informationsarchitektur, App, Admin, API und Infrastruktur — und einen früheren Prototypen vollständig ersetzt.

Kontext

Tanzen ist eines der wenigen Dinge, die Menschen wirklich aus Kurzvideos lernen, und zugleich eines der ungeeignetsten: Das Format ist fürs Zuschauen gebaut, nicht fürs Üben. Die Produktidee war, den Sog dieser Welt — Lehrende, denen man ohnehin folgt, Choreografien, die man ohnehin will — auf eine Struktur zu stellen, die tatsächlich unterrichtet: mit Kursen, Lektionen, Fortschritt und einem Abonnement dahinter. Ein früherer Prototyp existierte als vier getrennte Anwendungen. Er hatte Nachfrage und ungefähre Form belegt und konnte nicht das Produkt werden; er war eine Skizze, die Last tragen sollte.

Herausforderung

Die Arbeit war keine Portierung. Das Produkt musste definiert werden, bevor es gebaut werden konnte: Was ist ein Kurs, was eine Lektion, wie wird eine lehrende Person genannt, wenn mehrere in einem Kurs auftreten, worauf hat ein Abonnent Anspruch und wann wird dieser Anspruch geprüft, was passiert offline, und was tut die Redaktion den ganzen Tag, damit Inhalte fließen. Darunter lag eine harte technische Bedingung. Nichts aus dem Prototypen war an den Stellen belastbar, an denen Fehler teuer werden — Authentifizierung, Sessions, Bezahlung, Berechtigung, Upload, Transcoding, Speicher, Tokens, API-Clients, State und Datenbankschema mussten neu gebaut statt übernommen werden. Und das musste eine Regel sein, die sich unter Termindruck nicht still umgehen lässt.

Vorgehen

Wir haben mit der Informationsarchitektur begonnen, weil das Modell des Prototypen am ehesten aus Versehen weitervererbt worden wäre. Seine Begriffe pressten das Unterrichten auf eine einzige Ebene; wir haben es als Kurse mit Lektionen neu aufgebaut, mit einer Viele-zu-viele-Zuordnung der Lehrenden, damit ein Kurs legitim mehr als eine haben kann, und mit erhaltenen Alt-Identifikatoren, damit bestehende Inhalte migrieren statt neu erfasst werden. Danach haben wir in nummerierten vertikalen Schnitten gebaut, jeder mit eigener Spezifikation, Planung, Aufgabenliste und Review, und jeder mit einem nutzbaren Ergebnis statt einer Schicht: zuerst Katalog und Veröffentlichung, dann die lesenden Oberflächen, dann Authentifizierung und Onboarding, dann Abrechnung und Berechtigung, dann signierte Wiedergabe und die Lernschleife, dann Fortschritt, Merkliste und Offline-Verhalten, dann Kontoverwaltung, schließlich Admin-Betrieb, Analytics und Release-Reife. Die Videowiedergabe wird ausschließlich über die API signiert, Signaturschlüssel erreichen also nie einen Client. Beide Umgebungen sind in Terraform beschrieben, und jede Plattform hat eigene Continuous Integration.

Ergebnis

Der Kunde hat das Produkt durchgängig definiert und gebaut: eine mobile App, eine Admin- und Account-Weboberfläche, eine API und einen Worker-Dienst, Infrastruktur als Code für Staging und Produktion sowie Testsuiten über das Ganze. Die Regel hat gehalten — kein sicherheitskritischer Code des Prototypen ist in die Produktion gelangt. Bei der Übergabe waren die verbleibenden Punkte bis zum Start kaufmännischer und organisatorischer Natur, nicht technischer: produktives Cloud-Projekt, Store-Konten und die ersten Inhalte. Wir beschreiben es als gebaut und startbereit, weil es das ist.

Stack

Ein pnpm-Monorepo: Flutter für Mobile, Next.js für Admin und Account-Web sowie zwei Cloud-Run-Dienste für API und Hintergrundarbeit. Terraform für Staging und Produktion, Mux für signierte Videowiedergabe, RevenueCat über die In-App-Käufe von Apple und Google für Berechtigungen, Produktanalytik und Continuous Integration je Plattform inklusive mobiler Release-Builds.

Femy ist unsere eigene App zu Hormonen, Menopause und Longevity. Ihr redaktioneller Standard wird vom Build durchgesetzt: Ein Artikel ohne ausreichend datierte, prüfbare Quellen kompiliert nicht.

Kontext

Gesundheitsinhalte für Endnutzer sind meist ohne Quellen, und in der Frauengesundheit kostet das am meisten. Hormone, Zyklus, Menopause und Longevity sind die Themen mit dem größten Abstand zwischen dem, was gesichert ist, dem, was vielversprechend ist, und dem, was schlicht verkauft wird — und die Leserin hat keine Möglichkeit zu unterscheiden, was sie gerade vor sich hat. Femy bauen wir selbst. Wir konnten den Standard also festlegen, bevor die erste Zeile Inhalt entstand, statt ihn später gegen einen Redaktionstermin zu verhandeln.

Herausforderung

Ein redaktioneller Standard, der in einem Styleguide steht, zerfällt. Er übersteht den ersten Monat und erodiert dann unter dem gewöhnlichen Druck des Ausspielens, weil niemand daran gehindert wird, ihn zu übergehen. Wir wollten eine Untergrenze, die sich gar nicht übergehen lässt. Das zweite Problem zieht in die Gegenrichtung: Inhalte, die sich wie eine Literaturübersicht lesen, werden nicht gelesen. Der Text musste einfach und brauchbar bleiben, Glaubwürdigkeit konnte also nicht daraus entstehen, Zeitschriftennamen in die Sätze zu stapeln — sie musste von einer Stelle kommen, die nachprüfbar ist, ohne dass man sich durch sie hindurchkämpfen muss.

Vorgehen

Wir haben die Untergrenze ins Typsystem gelegt. Jeder Bibliotheksartikel wird gegen ein Inhaltsschema geprüft, das eine Mindestzahl an Quellen verlangt, und jede Quelle muss Titel, Herausgeber, eine auflösbare URL und das Abrufdatum tragen. Ein Artikel, der das nicht erfüllt, baut nicht. Das Abrufdatum ist aus einem genannten Grund Pflicht: Eine undatierte Quellenangabe lässt sich nicht nachprüfen, und genau das ist der Sinn einer veröffentlichten Quellenliste. Die Regel steht im Build und nicht in einem Linter, weil ein Lint-Schritt vergessen werden kann und ein fehlschlagender Build nicht. Hinter den veröffentlichten Artikeln liegen Rechercheberichte, die jede Aussage nach Evidenzstärke einordnen, Einzelaussagen mit Kennung und DOI auf PubMed zurückführen, Leitlinienaussagen mit ihrer Primärpublikation verknüpfen und klar benennen, welche beliebten Präparate Marketing sind und keine Medizin. In diesen Berichten werden auch Rücknahmen gefasst: Eine Fallserie von 1993 wurde als zurückgezogen erkannt und bewusst ausgeschlossen, statt still aus einer Sekundärquelle übernommen zu werden. Die Lektionen in der App halten eine eigene Untergrenze — mindestens eine namentlich genannte Institution, nie keine.

Ergebnis

Femy ist im App Store verfügbar, und die Inhaltspipeline dahinter lässt lieber den Build scheitern als die Leserin. Wir sind präzise, was das ist: Evidenzdisziplin, keine klinische Prüfung. Hinter der App steht keine ärztliche Freigabe, sie bindet keine Gesundheitsdaten der Plattform ein, und sie sagt im Produkt selbst, dass sie Wissensvermittlung ist und keine medizinische Beratung. Sie zeigt, dass sich ein Evidenzstandard mechanisch machen lässt — und dass er, einmal mechanisch, auch unter Termindruck hält.

Stack

Flutter auf iOS, mit Firebase für Authentifizierung, Daten und Nachrichten, einer Paywall- und Abonnementschicht sowie Fehler- und Produktanalytik. Die öffentliche Inhaltsseite ist mit Astro über schemageprüftes MDX gebaut; dort wird die Quellen-Untergrenze durchgesetzt. Unit- und Widget-Tests decken Abonnement, Authentifizierung, Inhaltssynchronisation und die Bewertung im Onboarding ab.

Wir haben das Venture-Konzept für einen computergestützten Wirkstoffdienst entworfen und das Modell darunter trainiert: eine Repurposing-Pipeline, die bekannte Medizin wiederfinden muss, bevor ihre neuen Vorschläge zählen.

Kontext

Es gibt tausende seltener Erkrankungen und für die einzelne sehr wenige Programme, weil die Ökonomie eines neuen Moleküls bei dieser Patientenzahl nicht aufgeht. Repurposing verändert die Rechnung: Eine Substanz, die bereits existiert und deren Sicherheitsprofil bereits beschrieben ist, startet weit vorne. Die Frage ist, welche Substanz, und der Raum ist viel zu groß, um ihn durch Lesen zu durchsuchen. Das war ein Venture-Konzept aus zwei Hälften, und beide mussten tragen: ob die kommerzielle Gelegenheit real ist und ob die Modelle das leisten, worauf die Gelegenheit beruht.

Herausforderung

Ein Modell, das plausibel wirkende Moleküle sortiert, ist nichts wert. Es liefert immer etwas, dieses Etwas wirkt immer vernünftig, und dem Ergebnis ist nicht anzusehen, ob das System Signal gefunden oder flüssiges Rauschen erzeugt hat. Zwei Dinge müssen gelten, bevor ein neuer Vorschlag Aufmerksamkeit verdient. Die Pipeline muss Medizin wiederfinden, von der bekannt ist, dass sie wirkt, und zwar bei Erkrankungen, deren Antwort feststeht — als Erdungstest, an dem sie scheitern kann. Und etwas in der Pipeline muss strukturell gegnerisch sein: ein Schritt, dessen Aufgabe das Verwerfen ist und nicht das Erzeugen, denn ein Generator, der seine eigene Ausgabe bewertet, ist keine Prüfung. Darunter liegt eine unscheinbarere Bedingung, die über die Verwertbarkeit entscheidet: Öffentliche biomedizinische Daten stehen unter sehr unterschiedlichen Lizenzen, und ein Ergebnis aus einer Quelle, die kommerzielle Nutzung untersagt, ist kein Ergebnis.

Vorgehen

Wir haben die Pipeline als gestufte Phasen gebaut und trainiert, jede mit eigenen Kennzahlen. Die Kandidatenerzeugung läuft als Graph-Machine-Learning über einen Wissensgraphen aus öffentlichen biomedizinischen Quellen — Zielstrukturen, Studien, Varianten, Chemie, Genetik und ihre bekannten Beziehungen. Jede Quelle und jede Kante ist nach Lizenzrisiko markiert, und ein Gate schließt eingeschränkte Quellen aus der produktiven Bewertung aus; Herkunft wird damit erzwungen statt erinnert. Die erzeugten Kandidaten gehen anschließend in eine gegnerische Prüfphase, danach in eine transkriptomische Validierung mit einem Foundation-Modell über Expressionssignaturen und für die Überlebenden in eine strukturelle Validierung. Jeder Lauf schreibt ein Manifest — Datensatzversion, Konfigurationshash, Modellversion, Lizenzstand — sodass sich jede Zahl auf den Lauf zurückführen lässt, der sie erzeugt hat, und Kennzahlen je Phase halten fest, wie viele Kandidaten eingingen, wie viele gefiltert wurden und was der Schritt gekostet hat. Für den Erdungstest haben wir Erkrankungen mit etablierter Therapie gerechnet: Bei Morbus Crohn und bei Morbus Gaucher hat die Pipeline bekannte Erstlinienwirkstoffe deutlich innerhalb der vorab gesetzten Schwellen gefunden, bei Gaucher stand die bekannteste Therapie auf Platz eins.

Ergebnis

Vorhanden ist eine trainierte, reproduzierbare Pipeline samt erhaltener Laufhistorie, dazu das Venture-Konzept, zu dessen Prüfung sie gebaut wurde: Umfang, Leistungsmodell, kommerzielle Einordnung und eine Lizenzprüfung der Open-Source-Bausteine, auf denen die Pipeline aufsetzt. Die negativen Ergebnisse sind erhalten geblieben statt aufgeräumt zu werden — in einem protokollierten Lauf hat die gegnerische Phase alle zwanzig eingegangenen Kandidaten verworfen, was die Prüfinstanz bei der Arbeit zeigt und der nützlichste Eintrag im Protokoll ist. Der Rahmen ist computergestütztes Screening. Es gibt keine Laborarbeit und keine klinische Validierung dahinter; ein sortierter Kandidat ist eine Hypothese für jemanden mit einem Labor, kein Befund.

Stack

Durchgehend Python. Graph-Machine-Learning zur Kantenvorhersage über den Wissensgraphen, ein transkriptomisches Foundation-Modell zur Signaturvalidierung, Strukturvorhersage und Docking für die Tiefenvalidierung, serverloses GPU-Rechnen für die schweren Schritte und lokale analytische Speicherung für Graph und Ergebnisse. Lizenzregister, Laufmanifeste und Kennzahlen je Phase gehören zur Pipeline und sind kein nachträgliches Reporting.

Ein System, das aus einem technischen Problem ein Erfindungsdossier macht, in dem jede Aussage belegt ist — mit Recherche zum Stand der Technik und einer Kritikschleife zwischen Idee und Ergebnis.

Kontext

Forschungs- und Entwicklungsabteilungen haben keinen Ideenmangel. Sie haben ein Sichtungsproblem: Ideen kommen schneller, als jemand prüfen kann, ob sie neu sind, und Entwicklungszeit fließt in Dinge, die sich als patentiert, veröffentlicht oder vor einem Jahrzehnt still aufgegeben herausstellen. Die interessante Frage ist, ob sich diese Sichtung als Prozess führen lässt statt als Nachmittag, an dem eine erfahrene Person Patente liest — und ob ein Agent dieses Lesen übernehmen kann, ohne selbstbewussten Unsinn zu produzieren.

Herausforderung

Ein Sprachmodell, das erfinden soll, erfindet — flüssig und ohne Zögern, auch Dinge, die es längst gibt. Die Flüssigkeit ist der Fehlermodus und nicht ein Nebeneffekt: Die Ausgabe überzeugt genau dort am meisten, wo das Modell etwas Gesehenes rekonstruiert. Das System kann also kein Prompt sein. Es muss echte Patent- und Literaturquellen erreichen statt sie zu erinnern, es braucht einen Ort für Belege, damit eine Aussage auf eine Quelle zurückführbar ist statt behauptet, und es braucht einen Schritt, dessen Zweck der Angriff auf die Idee ist. Ein Generator, der sich selbst benotet, besteht immer.

Vorgehen

Das System läuft als Pipeline mit einer Aufsicht darüber. Aus einem Problemdossier entstehen Ideenkandidaten; jeder Kandidat geht über echte Konnektoren in die Recherche zum Stand der Technik gegen Patent- und Forschungsquellen; eine Kritik- und Validierungsschleife greift anschließend an, was zurückkommt, und nur was übersteht, wird zu einem Erfindungsdossier mit belegten Aussagen. Strukturierte erfinderische Variation — die TRIZ-Methode, bekannte Transformationsmuster auf einen Widerspruch anzuwenden statt frei zu assoziieren — gibt dem erzeugenden Schritt etwas Besseres als ein leeres Blatt. Gebaut haben wir in Phasen, jede mit eigener Datenbankmigration und eigener API-Testsuite, in einer Reihenfolge, die das Gedächtnis vor das Denken setzt: zuerst Artefakte, dann ein Ereignisstrom der Läufe, dann Belegquellen als eigenständige Datensätze, dann die Orchestrierungsläufe, darüber die Aufsichtsschleife. Dass Belege Datensätze sind und kein eingebetteter Text, macht das Dossier am Ende prüfbar: Jede Aussage lässt sich zur stützenden Quelle zurückverfolgen.

Ergebnis

Das System arbeitet durchgängig: Ein Problem geht hinein, ein belegtes Erfindungsdossier kommt heraus, und die Recherchen wie die Ablehnungen der Kritikinstanz bleiben im Lauf erhalten, sodass die Begründung prüfbar ist statt geglaubt werden zu müssen. Es ist als interne Forschung und Entwicklung entstanden, und es gehört zur Redlichkeit zu sagen, dass es nicht als Dienst betrieben wurde — es gibt kein Deployment dahinter und keine Nutzerzahlen, auf die wir uns berufen könnten. Was es zeigt, ist eine Methode: agentische Recherche, die sich auf abrufbare Quellen stützen und etwas Gegnerisches überstehen muss, bevor ihr Ergebnis zählen darf.

Stack

Python und FastAPI mit versionierten Alembic-Migrationen, ein Orchestrierungsgraph für den Gesprächsverlauf, der die Phasen steuert, und ein Next.js-Frontend. Konnektoren für Patentrecherche und Forschung zum Stand der Technik, ein Query-Planer darüber und Testsuiten auf beiden Seiten — pytest gegen die API Phase für Phase und Komponententests in der Weboberfläche.

Ein strukturierter vierzehntägiger Sprint zur Venture-Validierung, neu entworfen: Ein dialogfähiger Agent führt die Methode mit der Gründerin durch, statt ihr ein Arbeitsbuch zu geben.

Kontext

Gründerinnen und Gründer validieren schlecht, und nicht aus Mangel an Frameworks. Die Frameworks existieren, sie sind gut, und sie liegen unvollendet herum, weil ein Validierungssprint vierzehn Tage unglamouröse Arbeit sind, die mit der weit reizvolleren Möglichkeit konkurriert, die Sache einfach zu bauen. Wer einen solchen Sprint geführt hat, kennt das Muster: stark an Tag eins, ehrlich an Tag drei, an Tag sechs aufgegeben, mit einem halb gefüllten Canvas, das niemand wieder öffnet. Nicht die Methode fehlt. Es fehlt jemand, der sie mit einem durchgeht.

Herausforderung

Eine Methode in Software zu gießen ergibt normalerweise ein Arbeitsbuch mit Login, und das scheitert aus genau dem Grund, aus dem die Papierfassung scheitert: Es wartet darauf, dass die Gründerin die Disziplin mitbringt. Eine agentengeführte Fassung muss das Gegenteil tun und die Struktur selbst halten — wissen, in welcher Phase des Sprints sie ist, im richtigen Moment zum richtigen Instrument greifen statt ein Menü anzubieten, und bereit sein zu sagen, dass eine Antwort für den nächsten Schritt noch nicht gut genug ist. Dieser letzte Punkt macht daraus einen Validierungssprint und kein Gespräch. Und all das muss mit Werkzeugen geschehen, deren Ausgabe prüfbar ist, denn eine Marktgröße, die ein Agent improvisiert, ist schlimmer als gar keine.

Vorgehen

Wir haben das Produkt als dialogfähigen Agenten über einem Katalog phasenspezifischer Werkzeuge entworfen, nicht als Formularoberfläche mit angebauter Assistenz. Die vierzehn Tage sind als Phasen modelliert — Entdeckung und Recherche, Ideenbildung, Validierung, Auswertung — und jede Phase stellt einen bestimmten Satz Werkzeuge bereit, statt alles auf einmal zu zeigen; die Struktur der Methode wird damit von der Orchestrierung getragen und nicht vom Durchhaltevermögen der Gründerin. Jedes Werkzeug ist mit einem typisierten Parameterschema definiert: Marktabschätzung, die nach Branche und Region fragt und Gesamt-, bedienbaren und erreichbaren Markt mit offengelegtem Rechenweg zurückgibt; Personendefinition; Wettbewerbs- und Positionierungsanalyse; Validierungsdesign. Die Typisierung hält den Agenten ehrlich, denn ein Aufruf mit fehlenden oder falschen Parametern scheitert, statt umschifft zu werden. Ebenso haben wir den Migrationsweg ausgeschrieben: wie aus einer formularzentrierten Anwendung eine agentengeführte wird, ohne das Datenmodell darunter wegzuwerfen.

Ergebnis

Das Ergebnis ist das durchgängig definierte Produkt: die Sprint-Methode als Phasenmodell, ein vollständiger Werkzeugkatalog mit typisierten Definitionen und ausgearbeiteten Umsetzungen je Instrument, eine Architektur für die Orchestrierung und der Migrationsweg von der bestehenden formularbasierten Fassung zur agentengeführten. Es ist die Entwurfshälfte eines Ventures, sauber gemacht — der Teil, der entscheidet, ob die Sache gebaut werden sollte, und zwar in der Detailtiefe, in der sich diese Frage tatsächlich beantworten lässt.

Stack

Durchgehend TypeScript: eine Next.js-Anwendung über einem Supabase-Backend für Daten und Identität, Hintergrundjobs für lang laufende Rechercheschritte und typisierte Werkzeugdefinitionen für den Werkzeugaufruf des Agenten, je Instrument mit Parameterschema spezifiziert.