La capa de base de datos que mantiene a raya a los agentes de IA.
Los asistentes y agentes de IA ya forman parte del flujo de trabajo de la mayoría de nosotros. Aceleran el desarrollo, automatizan lo repetitivo y nos permiten centrarnos en las partes de construir un sistema que de verdad necesitan a una persona. Pero hay una capa en la que creo que debemos ir más despacio: la base de datos.
Una parte central del diseño de cualquier sistema es su modelo de datos, y sigue siendo delicada. Puedes pedirle a un agente que modele un esquema para tu aplicación y normalmente hará un trabajo aceptable con el contexto que le des — pero en mi experiencia, rara vez es el mejor diseño. He recibido tablas con demasiadas columnas, sin ninguna reflexión real sobre cómo evolucionará el esquema con el tiempo, datos que no están agrupados con ninguna lógica — incluso de los modelos más potentes. El foco está en terminar rápido la tarea que tienes entre manos, no en dónde tiene que estar el esquema dentro de un año.
Puedes lanzarle muchas reglas y archivos markdown al problema para mejorar el diseño de esquemas de un agente. Pero creo firmemente que la revisión humana sigue siendo necesaria para asegurarte de que realmente tiene sentido. Al final del día, la persona que trabaja en el proyecto tiene más contexto del que jamás podremos entregarle a un modelo.
Y estos modelos de dominio se vuelven grandes y complejos a medida que un sistema evoluciona. Creo que una representación visual del modelo es lo que realmente lo hace comprensible — puedes ver las entidades, ver cómo se relacionan, ver la forma del conjunto en lugar de desplazarte por un archivo schema.sql. Esa capa visual importa para los ingenieros, pero importa aún más para las personas no técnicas de un equipo que necesitan entender el sistema sin leer código.
Modelar el dominio de un sistema es parte de la arquitectura central y, con gran parte del resto del proceso automatizándose, yo diría que esta es la parte que merece más atención — no menos. Incluso con agentes en el ciclo, sigue siendo costoso cambiar drásticamente un modelo una vez que un proyecto está bien avanzado. La automatización debería hacer que esta parte sea más segura de tocar, no algo que toques con menos cuidado.
Qué hace nuzur al respecto
Este es el problema que el servidor MCP de nuzur está construido para resolver. Importas tu base de datos existente (o creas una nueva) y la inspeccionas visualmente — ese es el primer paso. A partir de ahí, el servidor MCP permite que un agente haga cambios en el esquema, pero cada cambio es algo que tú revisas: ves exactamente qué está cambiando, y queda registrado a medida que el sistema evoluciona.
Me gusta pensarlo como que el agente propone y tú dispones — el agente nunca sostiene realmente la pluma. No obtiene una conexión en vivo para tocar nada por su cuenta. Abre lo que es esencialmente un pull request contra tu esquema: una solicitud de cambio que describe una nueva entidad, un nuevo campo, un índice, una relación. nuzur la prepara, tú ves el diff, y solo cuando apruebas algo se vuelve real.
Ese paso de revisión es todo el objetivo. Una mala línea de código de aplicación falla una prueba y se detecta. Un mal cambio de esquema es un tipo de error distinto: reconfigura los datos mismos, y los datos tienen memoria. Eliminar una columna no es algo que resuelvas con un git revert; es una restauración desde una copia de seguridad y un incidente que tendrás que explicar. La barrera tiene que estar ahí precisamente porque el agente es lo bastante rápido como para superar la capacidad de cualquiera de absorber sus cambios de forma segura sin ella.
No es solo el esquema — también son tus datos
La otra parte que nuzur gestiona es la administración de datos, siguiendo la misma lógica: un asistente puede proponer agregar, actualizar o eliminar datos, y tú revisas esos cambios visualmente antes de que nada se confirme. Puedes editarlos si algo no cuadra, y conservas un registro de lo que ocurrió por si alguna vez necesitas volver y ver por qué.
nuzur también valida lo que sea que el agente intente agregar o actualizar — asegurándose de que los campos requeridos estén presentes, de que los formatos sean correctos y de que cualquier validación que hayas definido en el modelo se aplique de verdad. Las entidades anidadas (campos JSON) también se validan, si has definido reglas para ellas. El agente no puede escribir datos incorrectos, igual que no puede escribir una migración incorrecta; solo puede proponer.
Diseñado para cómo trabajan realmente los agentes
El servidor MCP en sí está optimizado específicamente para agentes — herramientas granulares y específicas en lugar de una sola herramienta que espera un payload gigante. Nuestra primera versión tenía un único gran martillo: reemplazar toda la versión del proyecto por una nueva. Técnicamente funcionaba, pero iba en contra de cómo razonan realmente los agentes. Los agentes trabajan en pasos pequeños — agrega esta entidad, luego este campo, luego conecta la relación — y obligarlos a reconstruir y reenviar un modelo entero por cada cambio pequeño era lento, propenso a errores y hacía que las solicitudes de cambio resultantes fueran más difíciles de revisar.
Así que reconstruimos la superficie de herramientas en torno a operaciones granulares — addEntity, addField, addIndex, addRelationship, addEnum y otras — cada una correspondiente a una pieza pequeña y legible de una solicitud de cambio. El agente las compone de forma natural, y lo que llega ante ti para revisar se lee como una secuencia de intenciones en lugar de un muro de JSON regenerado.
Esto no es teórico para nosotros — usamos nuzur en nuestros propios proyectos a diario, y se han construido esquemas enteros a través de sesiones con agentes en las que cada cambio pasó por este mismo flujo de revisión. La fricción que sentimos al usarlo nosotros mismos es la fricción que fuimos a eliminar.
Hacia dónde va esto
Creo que este patrón — los agentes proponen, las personas aprueban, el sistema ejecuta — es cómo debería funcionar la infraestructura agéntica en cualquier lugar donde el costo de un error sea asimétrico. Las bases de datos son simplemente la versión más aguda de ese problema: el lugar donde «muévete rápido» y «no rompas cosas» están en el conflicto más directo.
Si usas Claude Code, Codex, Cursor o cualquier agente compatible con MCP, y has sentido ese destello de duda antes de dejarlo acercarse a tu esquema — esa duda es correcta. No deberías tener que elegir entre la velocidad del agente y la seguridad de tu base de datos.
Conecta el servidor MCP de nuzur, apunta tu agente a un proyecto y déjalo proponer algo. Tú seguirás sosteniendo la pluma.
Usa nuzur gratis. Conecta tu agente, modela tus datos y revisa cada cambio antes de que toque tu base de datos — sin tarjeta de crédito.
