De los sueños del agente RAG a un prototipo de VBA: separando datos brutos y derivados

El plan era modesto: crear una versión reducida de Merge, un agente de IA personal. Ya se estaban realizando experimentos con RAG, LangChain, LangGraph, embeddings y almacenes vectoriales, y la idea original era dotar al agente de memoria a largo plazo y acceso a documentos internos. Luego surgió otro problema. La gestión de proyectos como freelancer se había vuelto caótica, lo que llevó a pensar en escribir primero una herramienta pequeña en VBA. Parecía sencillo, pero no lo era. Con el tiempo, el prototipo en VBA se transformó en algo distinto: una forma de estudiar la lógica empresarial que algún día podría heredar un agente de IA.

Proyectos que rechazan un ciclo de vida ordenado

El trabajo freelance no sigue un camino predecible. Se envía una página de aterrizaje, y luego el cliente quiere un rediseño. La dirección del negocio cambia, aparece la integración de pagos, después la automatización con LINE, y luego un proyecto relacionado. Desde el punto de vista financiero, una tarea ya puede estar terminada y facturada mientras la colaboración en general sigue en curso. Los contratos de mantenimiento son aún más extraños, ya que muchos simplemente continúan hasta que el cliente indica que ya no los necesita.

Un único campo de estado no puede describir todo eso. Varias dimensiones de estado independientes sí pueden hacerlo:

billing_status = closed
task_status = active
invoice_status = pending

Al leerlo juntos, se indica que la cantidad está finalizada, la tarea sigue activa y la factura aún no se ha emitido. De lo contrario, habría sido necesario utilizar veinte estados combinados definidos manualmente. Los campos independientes mantienen el modelo compacto.

Separación de responsabilidades

Después de algunos días de reflexión, surgió una regla de estratificación:

Raw Data
   ↓
Small Logic
   ↓
Secondary Data
   ↓
END

Los datos primarios contienen hechos. Los datos secundarios albergan información calculada o transformada destinada a la vista humana. Existe una regla fundamental: no hay datos terciarios. Una hoja de datos secundaria nunca debe servir como entrada para otro cálculo. Cuando se necesita un nuevo resultado, se vuelve a los datos brutos para generar otro conjunto de datos secundarios. Eso podría significar la existencia de muchas hojas de datos secundarias con el tiempo, y eso es aceptable. Veinte vistas independientes son mejores que una cadena como esta:

Raw
 ↓
Secondary A
 ↓
Secondary B
 ↓
Secondary C
 ↓
Dashboard

porque un solo error en el medio se propaga por todas partes. El principio de funcionamiento es que tener más hojas está bien, pero las dependencias demasiado profundas no lo están.

Un diseño estricto para libros de trabajo

Las hojas se dividen según la responsabilidad, utilizando una convención de prefijos:

D_ = Raw Data
M_ = Master Data
S_ = System Rules
V_ = Secondary Views

Las hojas de datos en bruto se ven así:

D_Task
D_Point
D_Pharmacy

y las hojas maestras así:

M_Company
M_Project
M_Contact
M_Product
M_GroupS_SystemV_TaskList
V_MonthlyBilling
V_CurrentSummary

Las hojas D_ son la fuente de verdad. Las hojas M_ son diccionarios empresariales que incluyen información sobre empresas, productos, proyectos y contactos. S_System almacena la configuración específica de VBA: la tasa impositiva, el significado de cada estado, la tarifa por hora y los objetivos de ingresos. Las hojas con el prefijo V_ son resultados temporales. Cualquiera de ellas puede reconstruirse según sea necesario, y existen para que las personas las lean, no para que otras fórmulas dependan de ellas.

Ninguna edición directa

Se sigue una segunda regla: el funcionamiento normal nunca debe requerir que alguien edite manualmente los datos brutos o las hojas maestras. UserForms se encargan de crear, actualizar y eliminar lógicamente los registros. La eliminación no es física; en su lugar, se marca el registro:

record_status = deleted

La fila permanece en el sistema, lo que debería facilitar el seguimiento de la historia y reducir la pérdida accidental de datos.

VBA como herramienta de observación

Este fue el momento en que todo el proyecto cambió de rumbo. Inicialmente, VBA estaba destinado a automatizar el flujo de trabajo. Su papel más adecuado podría ser el de observarlo. El sistema puede calcular los ingresos esperados del proyecto y los ingresos esperados del farmacéutico, cuántos ingresos adicionales se necesitan aún, qué queda en cada proyecto, qué facturas aún no se han enviado, en qué estado se encuentra cada proyecto y cuántos puntos se han gastado.

Al analizar esas cifras se toman decisiones, como concluir que no se necesitan turnos adicionales para farmacéuticos el próximo mes. Si le preguntas a Merge cómo se tomó esa decisión, la respuesta honesta hoy en día es algo como “experiencia”. Esa es precisamente la razón por la cual la decisión aún no está automatizada. El sistema debería mostrar siempre la misma información, y tras un uso suficiente, los patrones en las decisiones podrían volverse visibles. Esos patrones luego podrían transferirse a Python y, finalmente, al agente. La posible progresión:

Raw Data
   ↓
Python Logic
   ↓
Secondary Information
   ↓
AI Agent
   ↕
Human adjustment through Slack

Por lo tanto, la versión en VBA no es necesariamente la aplicación final. Funciona como un laboratorio para averiguar qué necesita saber la aplicación definitiva.

Herramientas diferentes, tareas diferentes

Forzar todo en un solo sistema sería un error. Excel se encarga de los números, la facturación, los estados, los registros y las vistas financieras. Notion almacena tareas detalladas, notas e información de proyectos. Una pizarra física sirve para anotar cosas que hay que recordar o observar.

La visión a largo plazo combina dos enfoques: uno presentado como un informe y otro como una línea de tiempo, con Merge funcionando en Slack como el lugar principal para las conversaciones. Un dispositivo físico de Merge podría leer posteriormente los mensajes importantes de Slack en voz alta mediante tecnología de texto a voz. Al principio solo generaría salida, con las respuestas escritas en Slack, ya que el reconocimiento de voz resulta incómodo al aire libre y los experimentos anteriores provocaban que la voz sonara excesivamente alta al hablar frente a una computadora. La conversación por voz directa con el dispositivo físico es donde volvería a ser útil un Raspberry Pi.

La interfaz se convierte en una pizarra

Tras días de conversaciones sobre arquitectura, comenzó el trabajo en el primer UserForm, que gestiona grupos, empresas, proyectos, contactos y productos. La actitud inicial era que solo serviría para uso personal y que la apariencia no importaba. Luego se eligió una fuente graciosa, se cambió el fondo, aparecieron líneas divisorias blancas, y el serio formulario de datos maestros se convirtió en una interfaz al estilo pizarra. El veredicto de Merge fue que olía a MergeLab, y la reacción honesta fue que resultaba bastante agradable.

Internamente todo es estricto: dependencias, propiedad de los datos brutos, eliminación lógica y prohibición de datos terciarios. Visualmente parece como si alguien estuviera enseñando normalización de bases de datos en una pizarra a medianoche. El VBA aún no funciona, pero al menos la interfaz al estilo pizarra es coherente.

Lecciones aprendidas

La lección más importante es que la automatización no debería comenzar con la automatización misma. Primero hay que determinar qué información es factual, cuál está derivada y qué decisiones aún requieren juicio humano.

Tener menos hojas de cálculo no significa automáticamente menos complejidad. Muchas vistas secundarias independientes pueden ser más fáciles de entender que una configuración compacta con cadenas complejas de datos derivados.

Los estados de diferentes tipos pertenecen a campos distintos. En lugar de muchos estados combinados, los campos independientes pueden describir situaciones reales mucho más complejas:

task_status
billing_status
invoice_status
record_status

La lógica de negocio debe mantenerse separada de la interfaz de usuario. Un UserForm recopila los datos de entrada y llama a la lógica reutilizable, la hoja de cálculo activa las actualizaciones y muestra los resultados, mientras que los cálculos se encuentran en módulos pequeños y reutilizables. Esto facilita la migración posterior del prototipo.

Sobre todo, el prototipo puede exponer reglas de decisión ocultas. No es necesario que tome todas las decisiones hoy; solo debe hacer que esas decisiones sean visibles.

Siguientes pasos

La tarea inmediata es hacer que VBA realice alguna acción, comenzando con MasterManagementForm, que registra y gestiona grupos, empresas, proyectos, contactos y productos. Su flujo básico es:

Input
 ↓
Validation
 ↓
Generate ID
 ↓
Create / Update / Logical Delete
 ↓
Master Data

Una vez que los datos maestros estén listos, seguirán formularios de entrada separados para las hojas brutas:

D_Task
D_Point
D_Pharmacy

Después de eso, se pueden generar las primeras vistas secundarias. Las más importantes por ahora:

V_TaskList
V_MonthlyBilling
V_CurrentSummary

Cuando esos elementos sean utilizables en el trabajo real, quedará claro qué vistas se abren realmente y cuáles fueron solo una idea. Solo una vez que ese flujo de trabajo sea estable, una reconstrucción adecuada con Python, integración con Slack y un agente de IA se convertirá en una opción seria.

Así que la secuencia hasta ahora es: un intento de crear un agente impulsado por RAG, luego Excel, seguidos de varios días dedicados a delimitar los datos, y finalmente un tablero negro. El desarrollo de software va bien.