El límite no es Make: es el determinismo
Un escenario de Make es una secuencia de módulos y un mapeo de campos entre ellos. Con entradas predecibles eso es exactamente lo que hace falta, y es más rápido de montar que cualquier alternativa.
Un modelo de lenguaje no es una entrada predecible. Puede devolver un precio que no existe, un campo con otro nombre o un texto donde se esperaba un número, y lo hace sin fallar: devuelve algo, con la forma correcta. El módulo siguiente lo recibe y sigue.
Ahí es donde las dos arquitecturas se separan. No en la velocidad, ni en el número de integraciones: en qué pasa con una salida que llegó mal y no lo dice.
Qué hace cada uno, eje por eje
| La pregunta | Make.com | Bentho |
|---|---|---|
| ¿Qué se cobra? | Una operación por cada bundle que procesa cada módulo. Los bundles de un disparador multiplican las operaciones de todo lo que viene detrás. | Servicios por dominio con su propio puerto —catálogo, comercial, facturación, marca—, detrás de un gateway. El turno lo decide el código, no el número de pasos dibujados. |
| ¿Y si el modelo devuelve una cifra que no existe? | El lienzo no tiene con qué contrastarla: la pasa al módulo siguiente como cualquier otro valor. | Toda cifra del mensaje final tiene que venir del desglose de la cotización de ese turno o de la respuesta ya verificada del Cerebro. Si no, se descarta y se responde con plantilla determinista. |
| ¿Quién decide el siguiente paso? | El grafo, tal y como está dibujado en el lienzo. | El código. El modelo solo extrae, con temperatura 0; las transiciones están escritas y versionadas. |
| ¿Qué pasa cuando falla? | Ajustes por escenario: cuántos errores se admiten antes de desactivarlo, si se guardan las ejecuciones incompletas para reintentarlas, y qué descartar si esa carpeta se llena. | Una cifra sin respaldo no se reintenta a ciegas: se sustituye por plantilla. |
| ¿Cómo se habla con cada sistema? | Un módulo por integración, con los campos mapeados a mano en el lienzo. | Herramientas MCP con firma tipada por dominio, montadas junto al REST sin apagarlo: una llamada que declara cliente, líneas y sesión, y no un campo suelto. |
| ¿Qué separa a un cliente de otro? | La conexión configurada en cada escenario. | Perímetro criptográfico de tres factores y comprobación de que el cliente del token coincide con el de la URL, con ventana anti-repetición y rechazo por defecto. |
El caso que decide la arquitectura: una cifra inventada
Es el fallo más caro de una operación comercial automatizada, y el más difícil de ver: el modelo redacta un mensaje correcto, bien escrito, con un precio que no sale de ningún sitio. No hay excepción, no hay reintento, no hay alerta. Hay un cliente con una cifra que la empresa no puede sostener.
En Bentho ese mensaje no sale. El orquestador exige que cada cifra del texto final esté respaldada por el desglose de la cotización de ese turno o por la respuesta del Cerebro, que trae su propia verificación. Si el modelo cuela una que no lo está, la redacción se descarta entera y se responde con una plantilla determinista.
Lo que no se hace es volver a pedírselo al modelo a ver si esta vez acierta.
Regla del producto: toda cifra del mensaje final debe estar respaldada por el desglose de la cotización de ese turno o por la respuesta ya verificada. Si una redacción del modelo introduce una cifra sin respaldo, se descarta y se usa una plantilla determinista. Nunca se reintenta a ciegas.
El contrato entre piezas, y por qué se rompe solo
En un lienzo, el contrato entre dos módulos es el mapeo de campos que alguien hizo a mano el día que lo montó. Cuando la API del otro lado renombra un campo, o el modelo empieza a devolver el mismo dato con otra forma, el mapeo sigue ahí apuntando a algo que ya no llega.
Las herramientas MCP de Bentho declaran su firma: qué recibe cada una, de qué tipo, y de qué cliente. La entrada se valida antes de tocar nada, y el módulo rechaza la llamada si el cliente del token no es el de la petición.
Van montadas junto a las rutas REST de siempre, sin apagarlas. Añadir MCP no obligó a migrar lo que ya funcionaba, que es la diferencia entre una interfaz nueva y una reescritura.
Cuándo quedarte con Make
Casi siempre, si tu flujo es determinista. Make resuelve en una tarde lo que en código son dos días, y esta comparación no cambia eso.
- Mueves datos entre servicios con esquemas estables: un formulario a una hoja, un pago a un CRM.
- Los pasos son pocos y el resultado de cada uno es comprobable a simple vista.
- No hay un modelo de lenguaje decidiendo nada, o si lo hay, su salida no acaba delante de un cliente.
- El volumen es bajo y predecible, así que el coste por operación no se dispara.
Preguntas
¿Cuándo hace falta una alternativa a Make?
Make ejecuta pasos fijos, y lo hace bien. El problema aparece cuando uno de esos pasos es un modelo de lenguaje: su salida cambia entre ejecuciones y el lienzo no tiene contra qué contrastarla.
¿Qué hace Bentho con una cifra que no sale de la cotización?
Toda cifra del mensaje final tiene que venir del desglose de la cotización de ese turno o de la respuesta ya verificada del Cerebro. Si no, se descarta y se responde con una plantilla determinista.
Revisión técnica de tu arquitectura
Media hora mirando tus escenarios actuales, dónde entra el modelo y qué pasa hoy con una salida mal formada. Sin presentación comercial.
Programar la revisiónDe dónde sale cada dato
Las afirmaciones sobre Make salen de su documentación oficial, con la fecha en que se consultó. Puede haber cambiado: si vas a decidir con un dato, míralo en la tuya.
- Documentación de Make
https://help.make.com/operations (consultado el 2026-09-24)
«An operation is a single module run to process data or check for new data». Cada bundle que procesa un módulo cuenta una operación, así que los bundles de un trigger multiplican las operaciones de todos los módulos que vienen detrás.
- Documentación de Make
https://help.make.com/scenario-settings (consultado el 2026-09-24)
«Errors before deactivation» fija cuántos intentos se admiten antes de que el escenario se desactive solo; «Store incomplete executions» guarda las ejecuciones fallidas para reintentarlas, y «Discard data if storage is full» las descarta si la carpeta se llena.
- Documentación de Make
https://help.make.com/scenario-settings (consultado el 2026-09-24)
«Cycles per run» fija el máximo de ciclos permitidos durante una ejecución.