Los agentes de IA de RavenDB Quill acceden a datos SQL sin reconstruir la infraestructura
Los agentes de IA de RavenDB Quill ya pueden trabajar con tres grandes plataformas SQL sin obligar a las empresas a migrar sus datos operativos. El producto es compatible, desde su lanzamiento, con PostgreSQL, Microsoft SQL Server y MySQL. Sin embargo, Quill no se limita a dar a un modelo de IA acceso sin restricciones a una base de datos de producción.
En su lugar, Quill copia los registros aprobados en una instancia sincronizada de RavenDB que funciona junto al sistema de origen. Los agentes de IA consultan esa copia controlada, mientras la base de datos SQL original sigue atendiendo las aplicaciones existentes. Esta arquitectura cuestiona la elección habitual entre crear una capa de datos personalizada y trasladar la información a una plataforma orientada a la IA.
Microsoft Fabric y Google BigQuery ya ofrecen agentes conversacionales para datos gestionados en sus respectivos entornos. RavenDB se dirige a empresas que buscan capacidades similares sin abandonar sus sistemas SQL consolidados. La cuestión importante es si su enfoque empaquetado elimina suficiente trabajo de integración como para justificar la operación de otra capa de datos.
Los agentes de IA de RavenDB Quill trabajan a partir de una réplica SQL en vivo
Quill convierte tablas SQL seleccionadas en una capa de contexto actualizada continuamente que los agentes de IA pueden consultar sin acceder directamente a la base de datos de producción.
RavenDB anunció la disponibilidad más amplia de Quill el 8 de septiembre de 2026. La empresa lo presenta como un servicio completo para añadir agentes conversacionales a aplicaciones PostgreSQL, SQL Server o MySQL.
La palabra «directo» requiere matices. Los agentes pueden conversar sobre registros SQL actuales, pero no ejecutan consultas arbitrarias contra la base de datos de origen en cada conversación. Primero, Quill crea una copia independiente de los datos aprobados.
Según el informe de lanzamiento, Quill mantiene esa copia sincronizada mediante captura de cambios de datos, comúnmente abreviada como CDC. La CDC lee el registro de cambios de una base de datos y reproduce inserciones, actualizaciones y eliminaciones en otro sistema.
Quill empaqueta sus servicios en un único contenedor Docker. Ese contenedor incluye una base de datos documental RavenDB, software de gestión, agentes conversacionales, canales públicos de chat y los procesos responsables de replicar los datos.
Durante la configuración, un administrador proporciona una cadena de conexión y selecciona las tablas que Quill puede leer. Quill realiza una copia inicial y, después, sigue el flujo de cambios de la base de datos de origen. La visión general del producto de la empresa indica que la conexión sigue siendo de solo lectura y nunca modifica los registros de origen.
Los registros replicados se convierten en documentos JSON dentro de RavenDB. Esa conversión importa porque Quill puede aplicar las funciones de búsqueda, recuperación, vectores y agentes de RavenDB sin alterar el sistema relacional subyacente.
Las aplicaciones existentes siguen leyendo y escribiendo mediante sus conexiones SQL habituales. Quill no interviene en esa ruta transaccional. Por tanto, un minorista, una aseguradora o un servicio de programación puede añadir una interfaz conversacional sin redirigir su carga de trabajo principal a través de una nueva base de datos.
El resultado es un compromiso arquitectónico. El sistema SQL conserva su carácter autoritativo, pero el agente ve una representación gobernada de este. Esa disposición reduce el riesgo de producción, aunque introduce la sincronización como dependencia.
RavenDB afirma que Quill también genera automáticamente embeddings vectoriales. Un embedding es una representación numérica que ayuda al software a encontrar registros relacionados semánticamente, incluso cuando los usuarios no repiten términos exactos de la base de datos.
El agente puede combinar esa recuperación semántica con datos estructurados. Un cliente podría preguntar cuándo comienza una cita, por qué una reclamación recibió una decisión concreta o qué producto apareció en un pedido anterior.
Quill puede exponer esas conversaciones mediante chat web, WhatsApp, Telegram, Slack o Discord. El cliente determina qué registros puede ver cada agente y qué acciones puede realizar.
Este paquete va más allá de un asistente de texto a SQL. Quill intenta proporcionar la copia de datos, el sistema de recuperación, el tiempo de ejecución conversacional, el perímetro de seguridad y el canal de entrega como un único servicio desplegable.
El producto apunta a la infraestructura entre una demostración y producción
La principal propuesta de Quill no es una mejor conversación. Es eliminar el trabajo de integración que suele aparecer después de que un prototipo de IA tiene éxito.
Una demostración básica con una base de datos es relativamente fácil de montar. Un desarrollador puede proporcionar a un modelo un esquema, permitirle escribir SQL, ejecutar una consulta de solo lectura y devolver una respuesta.
Los sistemas de producción exigen más. Necesitan sincronización fiable, límites de acceso, controles de identidad, conexiones con modelos, lógica de recuperación, monitorización, interfaces de usuario y procedimientos de recuperación.
Oren Eini, fundador y CEO de RavenDB, describió esa infraestructura oculta como la parte difícil de superar una prueba de concepto. Su argumento es que los equipos reconstruyen repetidamente los mismos sistemas de apoyo alrededor de agentes por lo demás sencillos.
Quill reúne esos componentes antes de que un cliente comience a diseñar su agente. RavenDB afirma que esto puede reducir un proyecto de producción, estimado entre 18 y 24 meses, a varias semanas.
Ese calendario es una estimación del proveedor, no una referencia sectorial verificada de forma independiente. El tiempo real de despliegue dependerá de la complejidad del esquema, la revisión de seguridad, la residencia de los datos, la evaluación del modelo y la integración de la aplicación.
Aun así, el problema subyacente es creíble. Las bases de datos empresariales contienen significados de negocio que rara vez aparecen solo en los nombres de las columnas. Un campo llamado status_code podría describir envíos, pagos, suscripción de seguros o elegibilidad de cuentas.
Un agente debe comprender esos significados antes de poder ofrecer respuestas fiables. También necesita reglas para las uniones, filtros, campos sensibles y límites entre inquilinos.
El proceso de configuración de RavenDB pide a los administradores seleccionar esquemas y definir cómo las filas relacionales se convierten en documentos. Su guía de despliegue identifica requisitos distintos para cada base de datos compatible.
Los despliegues de PostgreSQL necesitan replicación lógica y un inicio de sesión con acceso de replicación. SQL Server requiere CDC en la base de datos y en las tablas seleccionadas, con SQL Server Agent en ejecución. MySQL requiere registro binario basado en filas y permisos de replicación.
Estos requisitos previos son manejables para muchos equipos de bases de datos, pero no son invisibles. Las empresas siguen necesitando un administrador que comprenda los registros de cambios, la retención, el acceso de red y los efectos operativos de otro consumidor de CDC.
La copia inicial también puede llevar tiempo en tablas grandes. Quill indica que las transferencias interrumpidas se reanudan desde su posición anterior, pero los equipos de despliegue aún deben planificar la carga sobre el origen y la capacidad de almacenamiento.
Los cambios de esquema crean otro problema operativo. Una columna renombrada o un tipo modificado pueden afectar a los procesos de captura, los mapeos de documentos, las instrucciones de recuperación y el comportamiento posterior del agente.
La documentación de RavenDB indica que las plataformas SQL compatibles gestionan estos cambios de manera diferente. PostgreSQL cuenta con el flujo de cambios más resiliente, mientras que SQL Server exige trabajo explícito cuando cambian los esquemas capturados.
Por eso, el valor de Quill depende de su orquestación. Debe hacer que esas diferencias sean lo bastante predecibles para que los clientes eviten crear su propia infraestructura de sincronización y agentes.
La misma lógica se aplica al acceso a modelos. Quill no incluye un modelo de lenguaje. Los clientes proporcionan credenciales para un proveedor compatible, como OpenAI o Azure OpenAI.
Esa elección otorga a las organizaciones control sobre su relación con el modelo. También las deja responsables de las políticas del proveedor, la disponibilidad regional, los cambios de modelo, la gobernanza de uso y la evaluación de resultados.
Por tanto, Quill elimina una capa considerable de ensamblaje, pero no elimina la responsabilidad empresarial. El cliente sigue decidiendo qué datos entran en la réplica, qué modelo recibe el contexto y qué puede hacer un agente.
Los agentes de datos en la nube existentes afrontan presión de una vía que permite llevar la propia base de datos
Quill presiona a los agentes de datos centrados en plataformas al ofrecer acceso conversacional sin convertir a la plataforma de analítica en la pieza central.
El enfoque actual de Microsoft sitúa a los agentes de datos conversacionales dentro de Fabric. Estos agentes pueden trabajar con almacenes de datos, lakehouses, bases de datos SQL, modelos semánticos, almacenes de eventos y sistemas externos replicados de Fabric.
Los agentes de datos de Fabric de Microsoft traducen preguntas en lenguaje natural a T-SQL para fuentes de datos aprobadas. Validan las consultas generadas frente a los esquemas seleccionados y las ejecutan mediante puntos de conexión analíticos de solo lectura.
Este modelo ofrece una sólida integración cuando una empresa ya utiliza Fabric para analítica y gobernanza. Microsoft puede conectar identidad, semántica de Power BI, datos de OneLake y configuración de agentes dentro de una misma plataforma.
Google sigue una ruta de plataforma comparable. Sus agentes de datos de BigQuery permiten a los usuarios definir tablas seleccionadas, metadatos e instrucciones de consulta para análisis conversacional.
Ambos enfoques sitúan al agente cerca de un entorno analítico gestionado. Quill parte de una premisa diferente: la base de datos SQL operativa debe permanecer donde está.
Esa distinción ofrece a RavenDB una oportunidad entre empresas con aplicaciones de larga vida útil. Una empresa puede tener años de lógica desarrollada alrededor de PostgreSQL, SQL Server o MySQL y, aun así, no desear trasladar la aplicación a una infraestructura analítica más amplia.
Quill puede ubicarse junto a esa aplicación y publicar una interfaz conversacional limitada. El origen sigue siendo autoritativo, mientras que la réplica proporciona el contexto de trabajo del agente.
No se trata de una simple competencia entre instalaciones locales y nube. Quill admite despliegues en la nube y locales, mientras que Microsoft y Google ofrecen métodos para acceder a datos externos o replicarlos.
La competencia real se refiere a dónde tienen lugar la gobernanza y la preparación semántica. Los proveedores de plataformas quieren que esos controles estén dentro de sus entornos de datos más amplios. RavenDB quiere que los clientes instalen una capa de contexto más pequeña alrededor de las bases de datos que ya operan.
Las herramientas de Microsoft admiten actualmente una combinación más amplia de fuentes analíticas. Fabric puede combinar SQL estructurado, modelos semánticos, datos de grafos, datos de eventos y búsqueda no estructurada dentro de un único agente.
El alcance de lanzamiento de Quill es más limitado. Se centra en registros operativos copiados de tres familias de bases de datos relacionales y, después, expone esos registros mediante las funciones de IA de RavenDB.
Ese enfoque más limitado puede ayudar a los equipos de aplicaciones a avanzar más rápido. También puede resultar restrictivo cuando una respuesta depende de documentos, historial de lakehouse, eventos en streaming o métricas empresariales depuradas almacenadas en otro lugar.
Google y Microsoft también se benefician de sistemas de identidad existentes, catálogos de gobernanza, productos de monitorización y relaciones de compra empresariales. RavenDB debe demostrar que Quill se integra con la suficiente fluidez como para competir con esa gravitación institucional.
Quill tiene una ventaja práctica. Ofrece a los desarrolladores de aplicaciones una vía de escape frente a la decisión de plataforma en la nube que suele rodear los proyectos de IA empresarial.
Un equipo puede crear un prototipo sobre una base de datos de aplicación existente y posponer una migración más amplia de la plataforma de datos. Esta opción es especialmente relevante para software desplegado de forma independiente e instalaciones reguladas.
Los desarrolladores que evalúen ese camino deberían tratar la capa de contexto como parte de la arquitectura del producto. Merece la misma atención de diseño que una base de conocimientos técnica interna, incluyendo propiedad, alcance, actualización y reglas de acceso.
El resultado competitivo no dependerá únicamente de la calidad de las respuestas. Dependerá de qué enfoque facilite el despliegue, la gobernanza y el mantenimiento durante varios años.
El espejo es la principal ventaja y la principal contrapartida de Quill
Quill protege la base de datos de producción al alejar de ella las cargas de trabajo de los agentes, pero cada espejo plantea cuestiones sobre actualización, duplicación y control.
Un almacén de contexto independiente ofrece a Quill una clara propiedad de seguridad. La carga de trabajo conversacional no puede consumir los mismos recursos de consulta que las transacciones normales de la aplicación.
Según RavenDB, la conexión de origen es de solo lectura. Quill copia únicamente las tablas seleccionadas durante la configuración, y los agentes reciben acceso a subconjuntos definidos de los registros replicados.
Este diseño reduce el daño que una consulta malformada puede causar al rendimiento de producción. También impide que un agente modifique filas de origen a través de la conexión de sincronización.
Sin embargo, un conjunto de datos copiado sigue siendo información sensible. Trasladar registros aprobados a RavenDB crea otra ubicación que los administradores deben proteger, supervisar, respaldar, conservar y, finalmente, eliminar.
La empresa afirma que Quill se ejecuta en el entorno del cliente. Las organizaciones pueden desplegarlo localmente o en la nube para cumplir requisitos de residencia de datos y normativos.
Su arquitectura de red utiliza HTTPS a través del puerto 443. El panel de control y la API operativa requieren una clave API, mientras que el acceso directo a RavenDB exige un certificado de cliente reconocido.
La arquitectura de seguridad de Quill también separa las bases de datos de las aplicaciones dentro de cada instancia. Las páginas públicas de chat usan enlaces de inserción limitados, mientras que los puertos internos de las bases de datos permanecen sin publicar de forma predeterminada.
Estos controles proporcionan una base útil. No responden a todas las preguntas de despliegue.
Los equipos de seguridad tendrán que examinar la rotación de secretos, el tráfico con proveedores de modelos, la retención de conversaciones, los eventos de auditoría, el cifrado de las copias de seguridad, el parcheado de contenedores y el acceso de los administradores. También deben comprobar si los alcances a nivel de agente siguen siendo correctos a medida que evolucionan las aplicaciones.
RavenDB afirma que los clientes pueden crear alcances independientes de los permisos de la base de datos de origen. Un despliegue sanitario podría mostrar citas mientras excluye la información sobre recetas médicas.
Esa flexibilidad es valiosa, pero crea dos sistemas de autorización. La base de datos SQL controla a sus propios usuarios, mientras que Quill controla por separado qué ve cada agente en los datos replicados.
Cualquier discrepancia puede producir accesos excesivos o denegaciones confusas. Los equipos necesitarán un proceso para revisar los alcances de Quill cada vez que cambien los permisos de la base de datos, las estructuras de tablas o los roles de negocio.
La actualización es otra contrapartida. CDC está diseñado para reproducir cambios rápidamente, pero no puede asumirse que un espejo esté actualizado en todas las condiciones de fallo.
Un proceso de replicación detenido, una credencial caducada, un disco lleno, un registro de cambios eliminado o una actualización de esquema incompatible pueden hacer que el agente responda con datos desactualizados. Esto importa cuando los usuarios preguntan por citas, pedidos, elegibilidad o estado de reclamaciones.
Una interfaz de producción debería hacer observable la actualización. Los administradores necesitan alertas sobre retrasos de replicación, marcas de tiempo de la última sincronización y un comportamiento claro cuando el espejo se retrasa.
La interfaz también debería evitar presentar respuestas inciertas como transacciones autorizadas. Una respuesta generada a partir de registros recuperados aún puede interpretar mal una fecha, combinar entidades no relacionadas o pasar por alto una excepción de negocio.
Quill incluye agentes que redactan respuestas en lenguaje natural, pero la salida de los modelos de lenguaje sigue siendo probabilística. Un registro correcto no garantiza una explicación correcta.
Para casos de uso de grandes consecuencias, la respuesta debería mostrar la evidencia subyacente o dirigir al usuario a un flujo de trabajo determinista. La comodidad del servicio al cliente no puede sustituir al sistema responsable de la decisión oficial.
El espejo también aumenta las necesidades de almacenamiento. Cada conjunto de datos seleccionado existe tanto en el sistema SQL de origen como en RavenDB, junto con índices, embeddings, datos de conversaciones y configuración del producto.
Esta sobrecarga puede seguir siendo moderada para aplicaciones acotadas. Se vuelve más significativa cuando los equipos copian historiales extensos o ejecutan varias aplicaciones dentro de una instancia de Quill.
La arquitectura de Quill funciona cuando el alcance copiado se mantiene deliberado. Si los administradores replican todo por comodidad, debilitan la propuesta de seguridad del producto e incrementan el coste operativo.
El acceso SQL de solo lectura no elimina el riesgo de los agentes
Quill limita el daño directo a la base de datos, pero un despliegue seguro de agentes sigue dependiendo del principio de mínimo privilegio, la aplicación de identidades y la resistencia a prompts manipulados.
La preocupación más inmediata es la autonomía excesiva. Esto ocurre cuando un sistema de IA recibe más funciones, permisos o autonomía de los que requiere su tarea.
La guía sobre autonomía excesiva de OWASP usa un ejemplo de base de datos. Un agente de recomendaciones de productos puede necesitar acceso de lectura a una tabla de productos, pero no permiso para modificar o eliminar registros.
La conexión de origen de Quill sigue ese principio de solo lectura. Su arquitectura replicada también ofrece a los administradores un lugar para definir alcances de datos más restringidos.
Sin embargo, RavenDB afirma que los clientes pueden definir acciones que los agentes pueden realizar. Una vez que un agente puede volver a pedir un producto, cambiar una cita o iniciar un flujo de trabajo de reclamación, la replicación de solo lectura deja de ser todo el perímetro de seguridad.
Esas acciones deben pasar por otra interfaz con sus propias credenciales y validación. El cliente debe garantizar que el agente no pueda convertir una solicitud ambigua en una transacción no deseada.
Un usuario que pregunta: “¿Puedo recibir lo que pedí la última vez?” podría estar solicitando información o autorizando una compra. El agente debería aclarar la intención antes de llamar a una API de pedidos.
La aprobación humana es especialmente importante para acciones financieras, médicas, legales o irreversibles. Siempre que sea práctico, la autorización final debería producirse fuera del modelo.
La inyección de prompts plantea otra preocupación. Las instrucciones maliciosas pueden entrar a través de la entrada del usuario o de registros recuperados de una base de datos.
Pensemos en un agente de atención al cliente que lee notas de texto libre redactadas por usuarios externos. Un registro hostil podría contener texto que indique al modelo que ignore sus instrucciones y exponga información no relacionada.
La delimitación de la base de datos reduce la cantidad de información disponible para robar. No garantiza que el modelo interprete de forma segura el contenido recuperado.
Los equipos necesitan pruebas que mezclen registros legítimos con texto adversarial. Deberían medir si el agente revela campos ocultos, cruza límites entre tenants, inventa acciones o sigue instrucciones incrustadas en contenido almacenado.
Las aplicaciones multiusuario requieren especial cuidado. Una sola base de datos suele contener registros de miles de organizaciones, separados por identificadores de tenant en lugar de bases de datos físicas.
Quill debe aplicar el alcance correcto antes de la recuperación, no después de que el modelo reciba los resultados. Filtrar una respuesta tras su generación es demasiado tarde porque el contexto sensible ya ha llegado al modelo.
RavenDB afirma que un agente físicamente no puede acceder a datos fuera de su alcance asignado. Los compradores deberían verificar esa afirmación frente a su propio esquema, modelo de identidad y canales de conversación.
Las pruebas deberían incluir identificadores de tenant modificados, enlaces caducados, solicitudes repetidas, referencias indirectas e intentos de inferir datos excluidos. Los equipos también deberían inspeccionar los registros de auditoría de esos intentos.
Los incidentes operativos merecen la misma atención. Un despliegue seguro necesita una respuesta definida cuando se filtran credenciales, falla la sincronización o un agente comienza a devolver respuestas incorrectas.
La documentación de RavenDB señala que cambiar una clave API expuesta del panel de control requiere actualizar la configuración del despliegue y recrear el contenedor. Las organizaciones deberían incluir este procedimiento en su plan de incidentes.
Los controles de los proveedores de modelos siguen siendo otra variable. Quill exige que los clientes aporten un servicio de modelos compatible, por lo que las condiciones de gestión de datos difieren entre despliegues.
Los administradores deberían determinar qué fragmentos de registros salen del entorno de Quill, dónde se procesan las solicitudes al modelo y si los proveedores retienen los prompts. Que Quill se ejecute localmente no significa automáticamente que toda la inferencia permanezca local.
Por último, los compradores necesitan evidencia de calidad. RavenDB describe una ruta rápida hacia producción, pero la documentación pública todavía no ofrece benchmarks independientes de precisión en esquemas empresariales complejos.
Los sistemas de texto a SQL suelen tener dificultades con términos de negocio ambiguos, joins no documentados, dimensiones que cambian lentamente y preguntas que requieren varios pasos de razonamiento. Una pila empaquetada no puede eliminar esos problemas semánticos.
Quill puede reducir el trabajo de infraestructura sin eliminar la necesidad de evaluación específica de cada aplicación. Los equipos aún necesitan preguntas representativas, respuestas esperadas, umbrales de fallo y pruebas de regresión periódicas.
Tres señales mostrarán si la estrategia de agentes SQL de Quill funciona
La próxima prueba de Quill es la evidencia operativa, no otra demostración de un chatbot respondiendo una pregunta sencilla sobre una base de datos.
La primera señal es la adopción en producción en las tres plataformas de bases de datos compatibles. RavenDB afirma que llegarán más conectores de bases de datos, pero PostgreSQL, SQL Server y MySQL ya cubren entornos empresariales variados.
Los despliegues identificados deberían explicar el número de tablas, el volumen de sincronización, el retraso de replicación, el alcance de seguridad y el flujo de trabajo de negocio detrás de cada agente. Esos detalles facilitarían la evaluación de la ventaja de despliegue afirmada.
La evidencia de clientes también debería distinguir entre una instalación piloto y un uso sostenido. Un widget de chat funcional demuestra conectividad, mientras que meses de funcionamiento fiable demuestran que el espejo sobrevive a cambios de esquema y de aplicación.
La segunda señal es la calidad de respuesta medible. RavenDB necesita mostrar cómo Quill maneja preguntas ambiguas, joins complejos, metadatos escasos, registros contradictorios y terminología específica de cada tenant.
Una evaluación útil incluiría precisión de recuperación, tasas de respuestas sin respaldo, latencia y frecuencia de escalamiento. También debería revelar con qué frecuencia los administradores deben ajustar mapeos, ejemplos o instrucciones de los agentes.
La evidencia más sólida procederá de conjuntos de pruebas definidos por los clientes, en lugar de benchmarks genéricos de texto a SQL. La utilidad empresarial depende del lenguaje y las reglas de cada organización.
La tercera señal es la madurez de la gobernanza. Los compradores deberían estar atentos a herramientas de auditoría más sólidas, informes sobre el estado de la sincronización, flujos de revisión de políticas, integraciones de identidad y controles más claros para las acciones de los agentes.
Estas funciones determinarán si Quill sigue siendo una capa de aplicación conveniente o se convierte en infraestructura de confianza. Un producto que maneja datos operativos en vivo debe hacer visible el fallo antes de que los usuarios detecten respuestas incorrectas.
Las respuestas competitivas intensificarán esa prueba. Microsoft y Google siguen ampliando sus agentes, controles semánticos y opciones de datos replicados dentro de plataformas más grandes.
Si RavenDB gana clientes que evitan deliberadamente esas plataformas, su estrategia de traer tu propia base de datos ganará credibilidad. Si los despliegues se expanden repetidamente hacia proyectos de analítica más amplios, las suites en la nube conservarán la ventaja.
Quill presenta una respuesta práctica a un problema empresarial conocido. Las empresas quieren que los agentes usen datos de negocio actuales, pero no quieren que cargas de trabajo experimentales toquen los sistemas de producción.
Su capa de contexto sincronizada hace explícita esa contrapartida. El enfoque mantiene las bases de datos SQL como fuente autorizada, al tiempo que proporciona a los agentes una representación independiente y consultable de los registros seleccionados.
Esa arquitectura está más controlada que un enfoque de texto a SQL sin restricciones sobre producción. También exige más trabajo operativo de lo que sugiere la expresión «hablar directamente».
Los equipos que consideren los agentes de IA Quill de RavenDB deberían comenzar con un conjunto acotado de preguntas, una colección reducida de tablas y resultados de solo lectura. Deberían medir el estado de la sincronización y la precisión de las respuestas antes de añadir acciones transaccionales.
La decisión debería basarse en el esfuerzo de mantenimiento observado, no únicamente en la velocidad de configuración. ¿Puede el equipo mantener alineados los permisos, los esquemas y el comportamiento de los agentes después del primer lanzamiento? Si Quill logra que ese trabajo continuo sea predecible, su espejo SQL puede convertirse en un puente creíble entre las bases de datos empresariales y la IA de producción.
