DataQubeDataQube
Blog

Flujos de trabajo de IA deterministas: un lenguaje, no una grabación

Los flujos de trabajo de IA deterministas no se construyen guardando una sesión como tarea - la repetición necesita propiedades que se puedan leer antes de que nada corra. Por qué los flujos de DataQube se escriben en un lenguaje: pasos ordenados, parámetros tipados y un manifiesto de permisos que no puede mentir.

PE
Product Engineering
DataQube · 8 de julio de 2026 · 7 min de lectura
Producto

El trabajo analítico tiene dos modos que fingen ser uno. La investigación es abierta: divaga, revisa, sigue la cifra sorprendente. La repetición es lo contrario: el paquete de cierre de mes, la respuesta al supervisor, el deck del comité del lunes - los mismos pasos sobre datos nuevos, donde una sorpresa no es un hallazgo sino un incidente. Una plataforma que trate ambos como un solo modo será mediocre en los dos; la verdadera pregunta de diseño es qué merece el modo segundo.

La respuesta de DataQube: un flujo de trabajo - un artefacto propio, de primera clase, con una pretensión fuerte. No "el agente intentará hacer lo mismo otra vez". No "guardamos su sesión y la reproduciremos". Un flujo de trabajo es un programa: pasos ordenados, parámetros tipados, acceso declarado - algo que se puede leer, revisar y razonar antes de que corra, y que después se comporta igual todas las veces.

El riesgo de las automatizaciones grabadas

La mayoría de los productos de agentes ofrece la repetición como grabación: tomar la sesión que funcionó, guardarla como tarea, ejecutarla según agenda. En la demo luce estupendo. El riesgo llega después, y se acumula en silencio. Una grabación arrastra todo lo que la sesión contenía por casualidad - los desvíos exploratorios, los supuestos de aquel día, valores enterrados en la celda diecisiete que solo valían para octubre. Nadie puede decir con precisión qué hará con datos nuevos, porque nadie escribió nunca qué debería hacer; y cuando la grabación la "reproduce" un modelo improvisando alrededor, cada ejecución mensual es una interpretación fresca de la historia. La deriva no tiene registro de cambios. La primera vez que el paquete del lunes se contradiga a sí mismo, no habrá nada que comparar - solo dos ejecuciones, dos estados de ánimo y una reunión.

Si está evaluando funciones de automatización en cualquier plataforma de agentes, esta es la pregunta que separa la grabación de la ingeniería: muéstreme el artefacto que corre el lunes - ¿puedo leerlo, y puede demostrar qué puede tocar?

Un flujo de trabajo es un programa que se puede leer

En DataQube, ese artefacto responde ambas mitades. Los flujos se escriben en un pequeño lenguaje dedicado - .wf -, y aquí está el flujo de exposición estándar de nuestros escenarios de demostración, ligeramente abreviado (los métodos de herramienta vienen de su propio catálogo):

cre-monthly-exposure.wf — el artefacto en síwf
import std @ 1 ## Rebuilds the monthly CRE exposure pack and stages it for review.## @param sql the SQL capability the queries run under## @param docs the document-store capability for policy citations## @param conn the registered risk-warehouse connection## @param as_of the reporting month-end, e.g. "2026-09-30"## @param dest the file store that receives the packdef cre_monthly_exposure(sql: Cap<dq.sql>, docs: Cap<dq.files>,                       conn: Connection, as_of: String, dest: Store) -> Step<ArtifactRef> = {let exposures: Table<{ segment: String, drawn: Decimal }> <- sql.execute_sql(  connection_id: conn,  sql: "select segment, sum(drawn_amount) as drawn        from loan_book where cre_flag and as_of = '{as_of}' group by segment",)let policy: Markdown <- docs.cite(file: "policies/CRE-limits-2026.pdf", section: "3.2")let pack: Markdown <- std.llm(prompt: "Build the CRE exposure pack for {as_of}.  Exposures: {exposures.rows}. Limits, cited: {policy}")let pdf: Pdf <- std.render_pdf(pack)std.upload(pdf, name: "cre-exposure-{as_of}.pdf", store: dest)}

Todo lo que una grabación deja implícito, aquí es explícito. Los parámetros están tipados, declarados en la firma y documentados con etiquetas que el verificador exige - la fecha de referencia es una entrada, no arqueología. Cada efecto es un paso vinculado y ordenado. Y el lenguaje mismo está construido para que el artefacto no pueda derivar: total y determinista por construcción - sin recursión, sin bucles ilimitados, sin coma flotante (solo decimales exactos), sin nulos. Cuando el análisis tiene que cambiar, el cambio es una versión nueva de este texto, revisada como cualquier cambio de un proceso gobernado. El determinismo no es una promesa sobre el humor del modelo. Es una propiedad del artefacto.

No puede mentir sobre lo que toca

Mire la firma otra vez, porque es la que hace el trabajo de seguridad. Cada familia de herramientas que un flujo puede usar debe llegar como parámetro de capacidad tipado - sql: Cap<dq.sql> -, y las capacidades no pueden crearse en el cuerpo. La firma es la superficie de acceso: este flujo puede consultar una conexión de almacén, citar documentos y subir un artefacto, porque eso es todo lo que se le entregó. De ahí, el análisis computa el manifiesto de permisos del flujo antes de que nada corra - qué lee, qué escribe, qué puede preguntar - como hecho comprobado, no como intención declarada.

La disciplina no se detiene en las herramientas nativas. Conecte un servidor MCP de terceros - Jira, ServiceNow, un servicio interno - y sus herramientas se derivan automáticamente al mismo mundo tipado: la capacidad aparece como jira: Cap<mcp.`jira-cloud`.*>, sus métodos tipados desde el catálogo vivo, sin envoltorios escritos a mano. Las herramientas externas obedecen las mismas reglas que las nativas - declaradas en la firma, contadas en el manifiesto, incapaces de aparecer en una ejecución que no las declaró.

Esa única propiedad cambia quién puede confiar en qué. Quien aprueba un flujo ve su superficie exacta en el momento de aprobar. El sistema de permisos impone el mismo techo que en todas partes: un flujo nunca supera los permisos de su propietario, y programarlo no concede nada. Y un auditor que pregunte "a qué pudo acceder esta tarea en marzo" obtiene la respuesta del artefacto mismo, no de una reconstrucción.

Extraerlo es tarea del agente, no suya

Nada de esto exige que alguien escriba código de flujos. El hilo es donde el trabajo se descubre - y cuando tiene que volver a correr, usted lo pide, y el agente deriva el flujo desde el registro: los pasos que realmente corrieron, los parámetros que realmente variaron, las fuentes que realmente se tocaron. El registro solo-anexado de la investigación es lo bastante preciso para compilar desde él; la extracción es una proyección de lo ocurrido en un programa que puede volver a ocurrir. Usted revisa el resultado - legible, tipado, con manifiesto adjunto - en lugar de ensamblarlo.

Tres maneras de ejecutarlo

El mismo artefacto corre de tres maneras, y cada una responde a una necesidad distinta:

  • Bajo demanda - una persona lo lanza con los parámetros de hoy; el paquete de cierre, corrido antes porque el comité se adelantó.
  • Según agenda - eso es un agente programado: el paquete del comité del lunes a las 06:00 que se reconstruye solo, compara con la semana anterior y prepara un borrador mientras la versión distribuida queda intacta.
  • Por llamada de herramienta - un agente en una conversación en vivo invoca el flujo estándar en lugar de rederivar cifras; así un número citado en un hilo puntual sale idéntico, ejecución por ejecución, al número del paquete distribuido.

Aquí corre una ejecución programada - lunes, 06:00, nadie al teclado:

ic-weekly-packejecución n.º 112 · agenda · lun 06:00
as_of = 2026-10-05portfolio = eu_equity_alphabenchmark = msci_europeparámetros fijados
  1. riskdwh.sqlExtraer posiciones y rendimiento semanal
  2. risk.engineCalcular atribución frente al índice
  3. docstore.readCitar los límites del mandato
  4. checks.runConciliar y verificar
  5. thread.appendPreparar el borrador del deck del comité
1 / 5 · ejecutando…

A partir de conversaciones reales con clientes — todos los datos son ficticios.

Cada ejecución queda en el registro

Una ejecución de flujo no es lanzar y olvidar. Cada una se añade al historial: qué versión corrió, con qué parámetros, produciendo qué salidas, con la cadena de evidencia completa - y sus resultados aterrizan en un hilo como borrador preparado que una persona publica. Las ejecuciones fallidas aparecen en el mismo historial con su procedencia, no en un log que nadie lee. Las garantías del registro no se debilitan porque nadie mirase; seis meses de ejecuciones de los lunes son seis meses de evidencia, no seis meses de esperanza.

Ese es todo el diseño: el hilo es donde está permitido sorprenderse, y el flujo de trabajo es donde nunca ocurre - porque es un programa con manifiesto, no el recuerdo de un buen día. El módulo de agentes programados de la página de producto muestra dónde vive esto en la plataforma, y una demo extraerá con gusto un flujo de una conversación en vivo delante de usted.

Se despliega en su clúster; nada sale fuera

Vea sus datos responder preguntas sin salir de su infraestructura

Treinta minutos con un ingeniero: producto en vivo, opciones de despliegue y respuestas claras para su equipo de seguridad.