React Flow como plano de control de agentes: puertos tipados en vez de YAML
Yaseen Khatib cuenta cómo convirtió el lienzo de React Flow en el plano de control real de su sistema de agentes, con handles tipados que rechazan conexiones inválidas mientras se dibujan.
El canvas de React Flow deja de ser un dibujo y pasa a ejecutar cosas. Ese es el argumento de Yaseen Khatib, ingeniero full-stack, que explica cómo en su producto IntegrateX empezó a correr los agentes directamente desde el grafo que antes solo servía para bocetar flujos. El mismo diagrama que un product manager arrastra para decir «cuando llega un ticket, busca en la documentación y luego responde o escala» es la especificación que consume el runtime: sin YAML en paralelo, sin DSL propio mantenido a mano.
Nodos como capacidades y aristas como contratos
La pieza central es tratar cada nodo como una capacidad —disparador, agente, herramienta, salida— y cada arista como un contrato tipado: la salida de una capacidad tiene que ser entrada válida de la siguiente. React Flow ya trae lo necesario para eso, componentes de nodo personalizados y handles con tipo. Poniendo un tipo en cada handle (flujo de documentos, resultado de herramienta, un «done» terminal), el editor rechaza las conexiones incompatibles mientras el usuario las dibuja, a través del callback isValidConnection. Las tuberías absurdas mueren al dibujarlas en lugar de reventar en los logs a las tres de la mañana.
Khatib mantiene además separado el grafo de render del grafo de ejecución. El estado de React Flow es el modelo visual: posiciones, selección, pan y zoom. El ejecutor consume un grafo derivado, solo capacidades y cableado tipado. Entre ambos sitúa un adaptador de serialización que limpia los metadatos de React Flow antes de persistir; según su cifra, eso recortó el payload un 94% y eliminó una tanda de bloqueos de sincronización. El número es suyo, no de un tercero, y no va acompañado de mediciones reproducibles.
Al conjunto de capas lo llama Trinity Architecture: presentación en el canvas, estado y orquestación en un store del cliente que actúa como fuente de verdad, y el adaptador en la frontera de serialización. La regla que impone es que la interfaz no formatea esquemas de base de datos y el adaptador no toca el estado de la interfaz por su cuenta.
Sobre el papel el patrón es sensato y no depende de nada exótico: es TypeScript, React Flow y disciplina de fronteras. El interés para quien monta orquestación de agentes está menos en el nombre y más en dos decisiones concretas: validar el grafo en tiempo de dibujo en lugar de en tiempo de ejecución, y no dejar que la UI sea la fuente de verdad del pipeline.
El coste es el de siempre: acoplas tu modelo de orquestación a una librería de diagramación. Si mañana React Flow cambia sus primitivas o el equipo decide que el grafo se edite desde otro sitio, la migración no es trivial. Y conviene recordar de dónde sale esto: un artículo de blog personal, con un producto propio detrás y con el autor buscando empleo al final del texto. La idea se sostiene sola; los porcentajes habrá que medirlos en casa.
