La anatomía de un workflow defendible

Un workflow no es la ejecución. La ejecución es un evento — cincuenta milisegundos de tráfico entre sistemas, una decisión de millones. El workflow es el artefacto detrás: el grafo versionado, el contrato, lo que se firma, se audita, se reproduce y se enmienda. Cuando rota el equipo, cuando el regulador actualiza una cláusula, cuando un socio cambia su API, cuando llega el año siguiente — la ejecución ya pasó. El workflow queda. Esa distinción suena académica hasta el día en que alguien pregunta: ¿qué fue exactamente lo que nuestro sistema decidió el 14 de abril, y con qué fundamento? Un workflow que puede responder eso es lo que llamamos defendible.

TL;DR

• Un workflow de Sommatic es un grafo versionado de nodos tipados — no un script — compuesto desde un marketplace, anclado en políticas del Knowledge Center, y terminado en evidencia.
• El determinismo viene de los nodos; el juicio viene de los Agents; el control viene de los gates HITL; la confianza viene de la cadena de auditoría que cada paso escribe por defecto.
• El workflow es el documento que lee el regulador, que sigue el post-mortem, y que hereda el próximo ingeniero. Constrúyelo en consecuencia.

Qué es realmente un workflow

Un workflow en Sommatic es un grafo versionado, no un script. Esa frase suena chica y cambia casi todo lo que sigue. Un script es una secuencia de instrucciones que se ejecuta de arriba hacia abajo dentro de un proceso que es dueño de su propia memoria; cuando el proceso muere, el estado muere con él. Un grafo es una definición declarativa de nodos y aristas que un motor externo recorre. El estado vive afuera del código. Cada paso es direccionable. Cada transición es un contrato.

Esto importa de tres formas concretas.

Primero, reproducibilidad. Como el grafo y las entradas están persistidos, la misma ejecución puede reconstruirse semanas después — no como un log de lo que pasó, sino como la máquina de estados real moviéndose de nodo a nodo con los valores que vio. No estás leyendo una historia de la ejecución; estás viendo la ejecución otra vez.

Segundo, reanudabilidad. Un workflow que pausa para una aprobación humana en el nodo siete no muere en el nodo siete. La instancia persiste. El nodo activo, las variables, el último envelope devuelto — todo serializado. Cuando el humano actúa, el motor despierta la instancia y continúa desde la misma arista. Días después, semanas después, no importa.

Tercero, versionabilidad. Un workflow tiene un FlowDefinition (la cosa con nombre de la que el equipo habla — “intake de devoluciones”, “onboarding de proveedor”) y registros FlowVersion que son inmutables una vez publicados. Versión nueva, grafo nuevo. Las ejecuciones viejas siguen apuntando a la versión en la que arrancaron. No existe “la última” reescribiendo silenciosamente el comportamiento de ayer.

La ejecución es un evento. El workflow es el contrato. Trátalos distinto.

En la práctica esto cambia cómo hablan los equipos. La gente deja de preguntar “¿está corriendo el workflow?” y empieza a preguntar “¿qué versión usó esa instancia?”. Esa es la pregunta correcta — y solo es posible porque el workflow existe como artefacto independiente de cualquier ejecución.

Compuesto de nodos desde un marketplace

La unidad de composición es el nodo. Un nodo es un operador tipado con un slug (io.http, ai.classify, data.validate), un esquema de configuración, puertos de entrada y salida declarados, y una implementación que devuelve un envelope: { ok, data, port }. Ese envelope es lo que le dice al motor qué arista seguir. Los nodos no se llaman entre sí. No comparten memoria. Emiten, el motor enruta, el siguiente nodo recibe.

Esto se expone como el Node Marketplace — un catálogo de operadores que los equipos exploran, configuran y arrastran a un grafo de la misma forma que elegirían una pieza de Lego. El catálogo se organiza en doce familias de nodos:

• identity — emisión e inspección de tokens, criptografía, redacción de PII, chequeos de consentimiento, evaluación Veripass.
• flow — flow.if, flow.switch, flow.join, flow.wait, flow.try, flow.split, flow.mutex, flow.window, flow.rate.limit.
• io — HTTP, FTP, SMTP/IMAP, SSH, MQTT, gRPC, WebSocket, GraphQL, SOAP, OCR, archivo y shell locales.
• ai — classify, compose, embed, summarize, extract, RAG, translate, transcribe, safety.
• data — transform, template, parse, validate, lookup, datetime, math, chunk, UUID, stringify.
• code — code.js, code.python, code.shell para los casos que un nodo del marketplace no puede expresar.
• ops — trace start y end, checkpoint, metrics emit, state read y write, audit append, dedupe, saga begin y compensate.
• triggers — webhook, cron, queue, manual, event, workflow.
• hitl — human.task.create, human.approval.gate, sommatic.app.execute.
• workflow — workflow.chain para composición de sub-workflows.
• connectors — específicos de proveedor (Microsoft Graph y similares).
• integrations — AWS, PostgreSQL, MongoDB, Redis, Oracle, OpenAI.

Imagen concreta. Un workflow de devolución de cuatro nodos: triggers.webhook recibe el pedido del cliente, ai.extract saca monto e ID de orden del mensaje, data.validate chequea el monto contra un lookup de la orden, human.approval.gate espera a un supervisor. Ese es el workflow completo. Cuatro nodos, tres aristas, un resultado. El marketplace convierte este ensamblaje en el modo por defecto — no en la excepción.

Los workflows se componen, no se codean. Las piezas vienen pre-tipadas; la ingeniería está en el grafo.

El marketplace existe porque la alternativa es que cada equipo reimplemente reintentos de HTTP, adaptadores OCR y rate limiters por proyecto. Así es como las organizaciones terminan con diecisiete formas sutilmente distintas de llamar al mismo proveedor de pagos.

El conocimiento como sustrato

Un workflow que hardcodea políticas es un workflow que se va a reescribir la próxima vez que cambie la política. Eso es lo que pasa con la mayoría de los workflows en la mayoría de las organizaciones, y es por eso que los equipos operativos dejan de confiar en sus propias automatizaciones después de dieciocho meses.

Sommatic separa las dos cosas. Las decisiones referencian el Knowledge Center — un store gobernado de políticas, criterios, umbrales, taxonomías, términos contractuales y reglas operacionales. Un nodo no incrusta “aprobar si monto < 500”; le pregunta al Knowledge Center cuál es el umbral de devolución vigente para este tier de cliente, en esta jurisdicción, bajo este producto. El umbral cambia cuando cambia la política — no cuando se despliega el workflow.

El sustrato tiene estructura. Cada knowledge resource tiene un dueño, una versión, una fecha de vigencia, un alcance. Cuando un workflow lee una política en runtime, la traza registra qué versión de qué resource consultó. Dos meses después, cuando un cliente pregunta por qué le negaron una devolución, la respuesta apunta a la cláusula específica que estaba activa al momento de la decisión.

Las políticas viven en Knowledge. Los workflows van a buscarlas. El día que cambia la política, los workflows no tienen que cambiar.

Esta separación también permite que personas no técnicas editen aquello de lo que son responsables. Compliance es dueño de los criterios de compliance. Finanzas es dueña de la política de crédito. Ingeniería es dueña del grafo que las consume. Los límites coinciden con el organigrama en vez de pelearse con él.

Agents dentro de un workflow

La mayoría de los pasos en un workflow defendible deberían ser nodos determinísticos — son más baratos, más rápidos, testeables, y producen la misma salida para la misma entrada. El determinismo es el piso. El juicio es la excepción.

Cuando se requiere juicio — clasificar una queja en texto libre, resumir una transcripción de reunión en items accionables, elegir cuál de tres revisores debería ver un documento — el workflow usa un Agent. Un Agent en Sommatic no es una sesión de chat libre. Es un actor con objetivo acotado, una lista explícita de tools autorizados, un presupuesto de tokens y costo, una ventana de contexto poblada desde Knowledge, y un contrato sobre lo que devuelve.

El tradeoff es real y vale nombrarlo. Un nodo determinístico se va a comportar igual el día uno y el día setecientos; el comportamiento de un Agent depende del modelo, del prompt, del contexto y del drift de datos detrás de los tres. Así que la regla es: usen nodos determinísticos donde puedan, usen Agents donde deban, y contengan a los Agents dentro del contrato del workflow que los llamó.

Los Agents van en el grafo, no alrededor. Reciben entradas, devuelven salidas, pagan un presupuesto, dejan traza.

Cuando un Agent en Sommatic produce una salida que cruza un umbral de riesgo, el workflow no ejecuta esa salida directamente — la enruta primero por un gate HITL. El Agent propone; el workflow dispone; el humano firma.

Gates HITL

Human-in-the-loop es un nodo. Esa frase es el diseño.

Cuando un workflow necesita a una persona — para aprobar una devolución, para desambiguar una extracción, para elegir entre dos coincidencias probables, para liberar un pago — el grafo contiene un nodo human.task.create o human.approval.gate. El motor pausa la instancia, persiste el estado, y emite un Task a la cola de trabajo. El task carga todo lo que el humano necesita: la entrada que lo disparó, la interpretación del workflow hasta ahí, las políticas en juego, la acción propuesta, y los botones que reanudan el flujo.

La interfaz del humano no es una UI genérica de tickets. Es una Operational App — una superficie React hecha a propósito que recibe el payload del task como input y emite una salida tipada. El Document Intelligence Desk para revisar documentos OCR. El Approval Desk para firmas basadas en monto. El Decision Explorer para casos donde el operador necesita inspeccionar el razonamiento del Agent antes de aceptar. Cada app es su propio artefacto versionado, con sus propios contratos de entrada y salida, hosteada por el App Engine y alcanzada por el workflow vía el nodo sommatic.app.execute.

Cuando el humano actúa, la app llama a submitOutput(). El Task se cierra. El workflow reanuda desde la arista posterior al gate, con la decisión del humano adjunta al envelope y la identidad del operador en la traza. Al workflow no le importa si el humano tomó treinta segundos o treinta días.

El gate es parte del grafo. El operador es parte del contrato. La traza registra a los dos.

Esto es lo que hace honesto el diseño HITL: los humanos no son un fallback para cuando la IA no está segura — son checkpoints tipados declarados en tiempo de diseño, donde el workflow sabe de antemano que va a delegar, y la traza de auditoría trata la acción humana con el mismo peso que la salida de cualquier otro nodo.

La cadena de auditoría

Cada ejecución de nodo escribe un registro. Actor (qué sistema o qué humano), slug del nodo, envelope de entrada, envelope de salida, la versión del workflow en que corrió, las versiones de las políticas que consultó, el tiempo que tomó, el correlation ID que lo amarra con eventos aguas arriba y aguas abajo. Nada de lo que hace el workflow pasa fuera de esta cadena.

Eso suena a logging, y no lo es. Logging es lo que lee un ingeniero cuando algo se rompió. La cadena de auditoría es lo que lee un auditor cuando algo está siendo cuestionado — y la diferencia es la estructura. Una línea de log es prosa; un registro de auditoría es evidencia tipada. El workflow ES el documento de auditoría.

Este es el sustrato para la Explainability. Cuando alguien pregunta “¿por qué se tomó esta decisión?”, la respuesta se genera desde la cadena misma: esta versión de este workflow recibió esta entrada, consultó esta versión de esta política, llegó a este nodo que llamó a este Agent con este prompt, que devolvió esta salida, que fue aprobada por este operador, que resultó en esta escritura a este sistema de registro. No es una historia que escribimos. Es la secuencia real que ejecutó el motor.

La explainability no es un feature que se atornilla. Es lo que cae por gravedad cuando cada paso está tipado y cada transición queda registrada.

También cambia cómo los equipos escriben workflows. Saber que la salida de cada nodo va a ser legible un año después cambia el cuidado con que se la diseña. El envelope de salida se vuelve un contrato pequeño: ¿qué necesita el siguiente nodo, qué tiene que ver el auditor, qué tiene que poder reconstruir el post-mortem?

Versionado y replay

Los incidentes en sistemas operacionales suelen llegar como una pregunta: ¿qué hizo el sistema para el cliente X en la fecha Y, y por qué? La respuesta tradicional es un proyecto de arqueología de varios días — stack traces, agregación de logs, reconstrucciones parciales y suposiciones educadas sobre cómo se veía el código en ese momento. Los workflows versionados colapsan eso.

La instancia registró la versión de workflow en la que corrió. La versión es inmutable. La cadena de auditoría registró cada entrada, cada salida, cada transición. El Knowledge Center registró la versión de política que cada lookup consultó. El replay no es metáfora — el motor puede re-ejecutar el mismo grafo contra las mismas entradas y ver desplegarse el mismo camino.

Esto cambia la cultura de post-mortem. La pregunta deja de ser “¿qué probablemente hizo el sistema?” y pasa a ser “¿qué hizo realmente el sistema, y en qué parte del grafo cambiaríamos el comportamiento para prevenir esto?”. La respuesta suele ser un nodo específico, una config específica, una referencia a política específica — y el fix es una nueva versión del workflow con un diff claro contra la vieja.

Los grafos versionados le ganan a los stack traces. Un diff entre v3 y v4 es una frase que cualquiera en la organización puede leer.

El replay también hace seguro evolucionar agresivamente. Los equipos despliegan más versiones de workflow cuando saben que las ejecuciones de ayer están protegidas de los cambios de hoy, y cuando saben que el comportamiento de la versión nueva puede ejercitarse contra entradas históricas antes de salir a producción.

Ejemplo trabajado: un workflow de intake de documentos, de punta a punta

Así se ven las piezas juntas. Imaginen un workflow llamado document-intake-v7 que recibe facturas de proveedor, las valida, y escribe las que pasan en el sistema de cuentas por pagar. Siete nodos. Un grafo. De punta a punta.

Nodo 1 — triggers.webhook. Un gateway de correo del proveedor hace POST del documento al workflow. El nodo de webhook valida la firma, escribe el payload crudo al storage de evidencia, y emite { document_url, supplier_id, received_at } por su puerto out.

Nodo 2 — io.ocr. Recibe la URL del documento, llama al adaptador OCR, devuelve el texto extraído y un mapa de layout por página. Una falla acá sale por el puerto error hacia un gate de revisión humana; el éxito continúa.

Nodo 3 — ai.extract. Este es el primer Agent del grafo. Recibe el texto OCR y un prompt armado desde un knowledge resource (invoice-extraction-schema-v4). Devuelve un envelope estructurado: { invoice_number, supplier_tax_id, line_items[], total_amount, currency } más un score de confianza por campo. El Agent tiene un presupuesto de 8k tokens y un techo de costo por invocación. El envelope se escribe a la traza antes de que el siguiente nodo lo vea.

Nodo 4 — data.validate. Un nodo determinístico. Chequea que el total extraído coincida con la suma de los items, que el tax ID del proveedor exista en el maestro de proveedores, que la moneda sea una que la organización acepta. Los fallos salen por el puerto invalid. Los éxitos siguen.

Nodo 5 — lookup de política vía state.read contra Knowledge Center. Pregunta la política de aprobación vigente para este tier de proveedor y este monto. Devuelve { requires_human_approval: bool, approver_role: string }. La versión del resource de política consultado queda en la traza.

Nodo 6 — human.approval.gate (condicional). Si la política exigía revisión humana, el gate crea un Task asignado a un usuario en approver_role, lo expone a través de la Operational App del Approval Desk con los campos extraídos, el documento fuente, los resultados de validación y la cláusula de política que disparó el gate. La instancia suspende. Cuando el aprobador actúa, el workflow reanuda cargando { approved: bool, approver_id, decision_notes }.

Nodo 7 — integrations.postgresql. Escribe la factura aprobada en la base de AP. Devuelve el ID del nuevo registro.

Nodo 8 — audit.append. Cierra el ciclo con un registro de auditoría estructurado: hash de entrada, versión de workflow, todas las salidas de nodo en orden, versiones de políticas consultadas, invocaciones de Agent y sus costos, aprobador humano si lo hubo, target final de escritura y ID del registro.

El conjunto son unas 200 líneas de definición de grafo. Cada paso es reproducible. Cada decisión apunta a su regla. El día que legal pregunte por qué una factura específica fue aprobada el 14 de abril, la respuesta está a una query — y la respuesta es el workflow mismo, no una historia sobre él.

Ocho nodos. Un contrato. Dos años de defensibilidad.

Construye para quien hereda

Un workflow que aguanta dos años después es uno que el ingeniero que lo hereda puede leer sin preguntarle a nadie qué hace, el auditor puede interrogar sin tu ayuda, y el dueño de política puede enmendar sin abrir un ticket. El trabajo de Sommatic es hacer que eso sea el camino fácil: grafos versionados, nodos de marketplace, conocimiento externalizado, Agents tipados, HITL como nodos de primera clase, auditoría como subproducto de la ejecución, y Omnisearch como la forma en que cualquiera en la organización encuentra el workflow cuando lo necesita. El objetivo no es escribir menos workflows. Es escribir workflows que sobrevivan a las personas que los escribieron, a las políticas que codificaron, y a los sistemas con los que se integraron — y hacerlo sin ceremonia, porque el framework ya codifica la disciplina como capa cognitiva organizacional.

→ Cómo Sommatic hace Workflows