En algún lugar del registro de un cliente, en medio de una nota corriente sobre una llamada corriente, hay una frase como esta: “El presupuesto está justo ahora, quedamos en volver a contactarles dentro de dos meses para retomarlo.”
Escrita una vez. Nunca vuelta a mirar. No porque a nadie se le olvidara que importaba, sino porque nada en ella parecía una tarea. No era una entrada de calendario. No era un recordatorio. Era solo una frase, haciendo lo que las frases en las notas hacen: quedarse ahí, técnicamente cierta, funcionalmente invisible.
Queríamos saber si el sistema podía detectar ese tipo de cosas por sí solo, sin que nadie tuviera que acordarse de volver y convertir a mano una frase en una tarea.
Lo que realmente construimos, y lo que deliberadamente no
El instinto con una función así es dejar que la IA se encargue de todo — leer la nota, averiguar la fecha, decidir que está vencida, quizá incluso redactar el seguimiento. En vez de eso, lo separamos a propósito.
El único trabajo del modelo es la comprensión del lenguaje: leer las notas recientes de un cliente y reconocer un compromiso orientado al futuro, algo como “lo retomamos en dos meses” o “les contactamos después de su reunión de junta.” Estima el retraso implícito en términos sencillos. Eso es todo. Todo el cálculo real de fechas — el plazo, si hoy ya lo ha superado — ocurre después, en código común y determinista. El modelo nunca hace los cálculos ni toma la decisión final sobre qué está vencido. Él lee. El código decide.
Esa separación importa más de lo que parece. La comprensión del lenguaje es exactamente el tipo de tarea difusa y dependiente del contexto en la que un modelo destaca. El cálculo de fechas es exactamente el tipo de tarea en la que no quieres que un modelo improvise, ni un poco.
La prueba real
No nos limitamos a comprobar que el endpoint devolviera algo con pinta razonable. Escribimos una nota real en un registro de cliente real: “…quedamos en volver a contactarles dentro de 2 meses para retomar el presupuesto.” Llamamos al endpoint. Extrajo correctamente el compromiso, calculó un retraso implícito de 60 días, y llegó a un plazo exactamente 60 días después de la marca de tiempo real de la nota, correctamente señalado como todavía no vencido.
Pequeño, y justo ese es el punto. El sistema no necesitó que le dijeran que había un compromiso que encontrar. Leyó una frase que una persona escribió para sí misma, no para un formulario, y de ahí sacó un plazo real.
La parte que es fácil pasar por alto
Las notas en Craft11 solo se pueden añadir, nunca modificar. Nadie las edita, nadie las borra, ni siquiera Stark. Es el mismo principio que mantiene honesto el lado en bruto de cada registro: lo que realmente escribiste se queda exactamente como lo escribiste. Cuando después tuvimos que quitar la nota de prueba, no había un botón de borrar al que recurrir, porque no se supone que exista. Hizo falta una operación directa en la base de datos, confirmada primero y deshecha justo después.
Es una pequeña molestia para nosotros durante las pruebas. Es la misma razón por la que la detección de compromisos es de fiar en primer lugar: lee texto humano real, sin alterar, sin limpiar, no una versión depurada de él.
Por qué merece la pena hacer esto, siquiera
Nada de esto sustituye a un gestor de tareas. Sustituye ese modo de fallo específico y silencioso en el que el único registro de una promesa es una frase que nadie va a volver a leer. El sistema no necesita que escribas distinto, que estructures tus notas, o que te acuerdes de marcar nada. Solo necesita que apuntes lo que realmente pasó, tal como lo escribirías para ti mismo, y él se encarga de darse cuenta.