Irgendwo im Datensatz eines Kunden, mitten in einer gewöhnlichen Notiz über ein gewöhnliches Telefonat, steht ein Satz wie dieser: “Budget ist gerade knapp, vereinbart, dass wir uns in zwei Monaten wieder melden, um das Ganze neu zu besprechen.”
Einmal geschrieben. Nie wieder angeschaut. Nicht, weil jemand vergessen hätte, dass es wichtig ist, sondern weil nichts daran wie eine Aufgabe aussah. Es war kein Kalendereintrag. Es war keine Erinnerung. Es war einfach ein Satz, der tat, was Sätze in Notizen so tun: dort sitzen, technisch wahr, funktional unsichtbar.
Wir wollten wissen, ob das System so etwas von selbst erkennen kann, ohne dass sich jemand daran erinnern muss, zurückzugehen und den Satz von Hand in eine Aufgabe zu verwandeln.
Was wir tatsächlich gebaut haben, und was bewusst nicht
Der Instinkt bei einer solchen Funktion ist, die KI einfach das Ganze übernehmen zu lassen — die Notiz lesen, das Datum ermitteln, entscheiden, dass es überfällig ist, vielleicht sogar die Nachfrage entwerfen. Wir haben es stattdessen bewusst aufgeteilt.
Die einzige Aufgabe des Modells ist Sprachverständnis: die jüngsten Notizen eines Kunden lesen und eine zukunftsgerichtete Zusage erkennen, etwa “in zwei Monaten schauen wir nochmal drauf” oder “nach ihrer Vorstandssitzung nochmal melden.” Es schätzt die implizite Verzögerung in einfachen Worten. Das ist alles. Jede tatsächliche Datumsberechnung — das Fälligkeitsdatum, ob es heute schon überschritten ist — passiert danach in gewöhnlichem, deterministischem Code. Das Modell rechnet nie und trifft nie die endgültige Entscheidung darüber, was überfällig ist. Es liest. Der Code entscheidet.
Diese Aufteilung ist wichtiger, als es klingt. Sprachverständnis ist genau die Art von unscharfer, kontextabhängiger Aufgabe, in der ein Modell gut ist. Datumsrechnung ist genau die Art von Aufgabe, bei der man nicht will, dass ein Modell improvisiert, nicht einmal ein bisschen.
Der eigentliche Test
Wir haben nicht nur geprüft, ob der Endpoint etwas plausibel Aussehendes zurückgibt. Wir haben eine echte Notiz auf einem echten Kundendatensatz geschrieben: “…vereinbart, dass wir uns in 2 Monaten wieder melden, um das Budget neu zu besprechen.” Den Endpoint aufgerufen. Er hat die Zusage korrekt herausgelesen, eine implizite Verzögerung von 60 Tagen errechnet und ist bei einem Fälligkeitsdatum gelandet, das genau 60 Tage nach dem echten Zeitstempel der Notiz lag, korrekt als noch nicht überfällig markiert.
Klein, und genau das ist der Punkt. Das System musste nicht darauf hingewiesen werden, dass es eine Zusage zu finden gab. Es hat einen Satz gelesen, den jemand für sich selbst geschrieben hat, nicht für ein Formular, und daraus eine echte Frist gezogen.
Der Teil, den man leicht übersieht
Notizen in Craft11 sind append-only. Niemand bearbeitet sie, niemand löscht sie, nicht einmal Stark. Es ist dasselbe Prinzip, das die rohe Seite jedes Datensatzes ehrlich hält: Was Sie tatsächlich geschrieben haben, bleibt genau so, wie Sie es geschrieben haben. Als wir die Testnotiz später entfernen mussten, gab es keinen Löschen-Button, nach dem wir hätten greifen können, weil es keinen geben soll. Es brauchte einen direkten Datenbankeingriff, erst bestätigt, dann sofort wieder rückgängig gemacht.
Das ist für uns beim Testen eine kleine Unannehmlichkeit. Es ist aus demselben Grund, dass die Zusagen-Erkennung überhaupt vertrauenswürdig ist: Sie liest echtes, unverändertes, unbereinigtes menschliches Geschriebenes, keine bereinigte Version davon.
Warum sich das überhaupt lohnt
Nichts davon ersetzt einen Aufgabenmanager. Es ersetzt den spezifischen, stillen Fehlermodus, bei dem der einzige Nachweis eines Versprechens ein Satz ist, den niemand je wieder lesen wird. Das System braucht nicht, dass Sie anders schreiben, Ihre Notizen strukturieren oder sich daran erinnern, irgendetwas zu markieren. Es braucht nur, dass Sie aufschreiben, was tatsächlich passiert ist, so wie Sie es sich selbst aufschreiben würden, und es übernimmt das Bemerken.