Finyuus

El lenguaje de Finyuus es un lenguaje de dominio específico y pequeño, escrito para la orquestación de IA, no para scripting de propósito general. Sus sentencias cubren llamadas a agentes, herramientas nativas y HTTP, guardas, aprobaciones, condicionales, bucles, ramas paralelas y canalizaciones hijas. Como los flujos de trabajo son texto plano, puedes compararlos con diffs, revisarlos en pull requests y reutilizar piezas entre proyectos. Esa es la razón de que exista: comportamiento de IA que puedes leer y comparar, no un lienzo lleno de cajas. Sin cajas. Solo texto.

Cada ejecución está respaldada por Temporal, que es lo que hace que las esperas largas y los fallos sean superables. Si un worker muere a mitad de una ejecución, el flujo de trabajo se reanuda desde su estado registrado en lugar de empezar de nuevo. Los reintentos, la cancelación y la orquestación de flujos de trabajo hijos vienen de la misma capa. Simplemente funciona. Para quien haya visto desaparecer una tarea de agente de varias horas por un fallo, esta es la función que cambia el cálculo.

Las guardas son verificaciones de política basadas en LLM que devuelven campos como allowed, confidence y reason. Una canalización dirige la ejecución por una rama de permitido o de bloqueo, y puedes condicionar según umbrales de confianza en lugar de un sí o no plano. Así evitas que un modelo responda directamente a una pregunta de asesoramiento financiero, o bloqueas resultados que incumplen una política de publicación antes de que lleguen a un usuario. Idea simple. Diferencia enorme en la práctica.

Las sentencias de aprobación pausan un flujo de trabajo hasta que un revisor lo resuelve desde el panel o la API. Defines un responsable, un tiempo de espera y una acción al agotarse, y la canalización se ramifica en rutas aprobada y rechazada. Es una detención real, no una sugerencia. Esa es la diferencia entre "lo revisaremos más tarde" y un sistema que de verdad detiene un resultado arriesgado y espera a una persona antes de continuar.

Los agentes, guardas, herramientas, esquemas y canalizaciones son objetos guardados con fijaciones de versión inmutables. Escribes pipeline:company_research@v2 y obtienes exactamente esa versión, no lo que alguien editó por última vez. Fíjala. Sigue adelante. Las canalizaciones hijas pueden llamarse directamente o envolverse como herramientas de agente, así que un cambio en un punto no se propaga en silencio por todos los flujos de trabajo que dependen de él.

Cualquier canalización puede publicarse como endpoint HTTP con autenticación por token Bearer, limitación de tasa respaldada por Redis, claves de idempotencia y validación de entrada. Los eventos enviados por el servidor transmiten las actualizaciones de la ejecución de vuelta a quien llama, y las aprobaciones generan sus propios eventos. Los límites de proceso son de 300 solicitudes por minuto en total y 120 por endpoint de forma predeterminada, todo configurable mediante variables de entorno. Valores predeterminados sensatos. Fáciles de sobrescribir.

Las trazas, el uso de tokens y los costes de modelo llegan a Langfuse, mientras que los datos de la aplicación y las tablas de canalización viven en ClickHouse. El historial de ejecución, los resultados de las guardas y las decisiones de aprobación se ven en el panel. El objetivo no es tener más paneles por tenerlos. Es que un sistema de IA fragmentado normalmente no tiene un único lugar donde responder "¿qué pasó realmente en esta ejecución?"

Los archivos y los artefactos grandes van a un almacenamiento de objetos configurable, que de forma predeterminada es MinIO local y puede cambiar a AWS S3 con unas pocas variables de entorno. El DSL lee y escribe archivos y tablas respaldadas por ClickHouse como sentencias de primera clase, así que las operaciones con datos estructurados están dentro del flujo de trabajo en lugar de en un servicio aparte. Sin un servicio extra que cuidar.