El fin de la automatización determinista
Durante quince años automatizamos el trabajo dibujándolo. Aguantó mientras cada paso era predecible. Deja de aguantar en cuanto un modelo entra en el flujo, y la respuesta no es un diagrama más grande.
Esto es lo que creemos, y lo que estamos construyendo por eso. No es una página de producto: aquí no hay precios, ni nada que no podamos enseñarte en el código.
1. La era determinista y su techo
La automatización determinista hizo una promesa sencilla: misma entrada, mismo camino, misma salida. Para pasar una fila de un formulario a una hoja de cálculo, esa promesa es exactamente la correcta, y nada de este manifiesto va contra ella. El código que siempre hace lo mismo es lo más barato de confiar que hay en el software.
El techo nunca fue el código. Fue el supuesto que tenía debajo: que alguien podía escribir de antemano todas las situaciones que el flujo iba a encontrarse. Con formularios y webhooks, se podía. Con un cliente que escribe con sus propias palabras, un contrato con una cláusula rara o un proveedor que contesta media pregunta, no — y todo equipo de automatización recuerda la semana en que la cola de excepciones empezó a crecer más rápido que el flujo.
2. Por qué los grafos visuales fueron un parche de la Web 2.0
El constructor visual fue un avance de verdad. Permitió que gente que no programa conectara las API que abrió la Web 2.0, y convirtió un flujo en algo que se puede mirar. Por eso ganó.
Pero un lienzo sostiene de maravilla el camino feliz y todo lo demás, mal. Un invariante —«este precio sale siempre de la cotización»— no es un paso. Tampoco un contrato («este campo tiene como mucho 4.000 caracteres») ni una política («nunca prometas una fecha que no puedas respaldar»). Nada de eso tiene sitio en un diagrama, así que se codifica como más ramas, y el grafo crece justo en la dirección en la que peor se lee.
La señal no es el número de nodos. Es el día en que el equipo empieza a añadir sub-flujos y nodos de código: ese es el lienzo admitiendo que dejó de ser la representación. La versión larga está en Flujos vs agentes.
3. LLM dinámicos: cada rama se vuelve frágil
Mete un modelo de lenguaje en ese grafo y se rompe algo más silencioso. Una rama comprobaba un valor que producía el sistema: un código de estado, un campo, un número. Ahora comprueba un texto que escribió un modelo. La condición se ve igual en el lienzo; por debajo, se ha convertido en una probabilidad.
El grafo no puede enseñarlo. Dibuja «si categoría = reembolso» como la misma bifurcación limpia tanto si la categoría vino de una base de datos como si vino de un modelo leyendo un correo enfadado. Cada rama de después hereda la incertidumbre de la primera, y el diagrama la presenta toda como cierta.
El arreglo habitual son más ramas: una para cuando el modelo dice «reembolso», otra para «devolución», una tercera para cuando dice las dos. Es intentar salir dibujando de un problema que creó el dibujo.
4. Bentho como sustrato agéntico
La respuesta tampoco es dárselo todo al modelo. La mejor guía que hay —la de Anthropic incluida— dice que se empiece simple y se añada autonomía solo donde lo simple se queda corto. Lo que cambia no es cuánto determinismo hay. Es dónde vive.
Un sustrato es aquello sobre lo que se apoya el trabajo. El de Bentho es una columna determinista escrita en código, no dibujada: se encarga del turno, del dinero y de los contratos. Los modelos hacen lo que se les da bien —leer, extraer, redactar— dentro de límites que la columna hace cumplir. El trabajo cuya duración nadie puede prever va a sub-agentes acotados, que devuelven un resultado tipado que la columna comprueba como cualquier otra entrada.
Por eso decimos «agéntico» y no «agentes»: el sistema delega trabajo en un modelo, y nunca delega la decisión de la que responde. Con la definición estricta, nuestro propio orquestador conversacional es un flujo —lo hemos dicho en público— y creemos que esa es la gracia, no una debilidad.
5. Principios del runtime
Contratos, no confianza
Cada capacidad que el sistema puede llamar declara qué recibe, qué devuelve y para qué cliente, y lo comprueba antes de ejecutarse. La entrada se valida en la frontera antes de que nada decida. Una capacidad que verifica quién pregunta no se deja convencer de contestar por otro.
La memoria es del negocio, no de la ejecución
Una ejecución que guarda una conversación en memoria muere con ella y crece con ella. En Bentho, lo que el sistema sabe de tu negocio —tus documentos, tu lenguaje, tus reglas— vive en un espacio privado propio, y cada dominio guarda su estado en su propio servicio. Una ejecución puede fallar sin que el sistema olvide.
Personas donde está lo que importa
Las transferencias y las disputas se detienen en una interrupción determinista para la aprobación humana. No porque el modelo suela equivocarse, sino porque «suele» es mal criterio cuando hay dinero o la queja de alguien de por medio. Y antes de que nada salga, toda cifra de la respuesta tiene que venir de una fuente que el sistema sepa nombrar; la que no, se descarta y responde una plantilla fija.
6. Un llamado a evaluadores alfa y a los fundadores
Estamos empezando, y preferimos que nos pongan a prueba a que nos admiren. Si tienes un flujo del que ya no te fías del todo —el de la cola de excepciones, el que nadie quiere tocar— queremos ponerle Bentho delante contigo, y publicar lo que cambie en el changelog.
Si inviertes en infraestructura y este es un argumento que esperabas ver hecho con código en vez de con diapositivas, escribe directamente a los fundadores.