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. Y la inferencia se desborda sola a otro proveedor cuando no hay slot libre. |
| ¿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: `price_quote(tenant, lineas, session_ref)` 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.
Garantía P1 (0% precios que no vengan de quote()): toda cifra del mensaje final debe estar respaldada por el desglose de la Cotizacion de este turno, o por la respuesta del Cerebro. Si una redacción del LLM introduce una cifra sin respaldo → se descarta y se usa PLANTILLA DETERMINISTA (nunca reintento LLM a ciegas).mod/atencionalcliente/atencion/agent/orchestrator.py
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.
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ó. Las de Bentho salen del código, con el fichero donde se puede leer.
- 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.
- Código de Bentho
mod/atencionalcliente/atencion/agent/orchestrator.py
«Garantía P1 (0% precios que no vengan de quote()): toda cifra del mensaje final debe estar respaldada por (a) el desglose de la Cotizacion de este turno, o (b) la respuesta del Cerebro. Si una redacción del LLM introduce una cifra sin respaldo → se descarta y se usa PLANTILLA DETERMINISTA (nunca reintento LLM a ciegas).»
- Código de Bentho
mod/atencionalcliente/atencion/agent/orchestrator.py
«Orquestador conversacional (loop por turno). Transiciones 100% en código.» Por turno: guards → el LLM extrae con temperatura 0 → merge de slots → EL CÓDIGO decide (RAG / cotizar / pedir slot / desambiguar / handoff) → redacción verificada cifra a cifra.
- Código de Bentho
mod/productos/productos/api/mcp_server.py
Servidor MCP con firma tipada por herramienta: `search_catalog(tenant, q, limit)`, `lookup_variant(tenant, variant_id)`, `price_quote(tenant, lineas, session_ref)` y `availability(tenant, variant_id, cantidad)`. Montado aparte del REST: «HTTP no depende de esto».
- Código de Bentho
README.md
Los módulos sirven MCP bajo FastMCP montado en `/mcp` como sub-aplicaciones ASGI dentro de FastAPI, «sin apagar ni interferir con las rutas HTTP REST tradicionales».
- Código de Bentho
mod/productos/productos/api/mcp_server.py
Cada herramienta MCP valida el tenant antes de responder y rechaza la llamada si «el tenant del claim no coincide con el de la tool».
- Código de Bentho
README.md
Gateway → microservicios con tres factores: Bearer `CORE_API_KEY`, claims del tenant en base64url y firma HMAC-SHA256 del payload. Cada servicio comprueba que `claims.tenant` coincida con el `{tenant_id}` de la URL (anti-confused-deputy), con ventana anti-replay de 60 s y diseño fail-closed.
- Código de Bentho
mod/comprension/comprension/api/routes/comandos.py
El módulo de comprensión expone `POST /comandos` con entrada validada por pydantic (`ComandosIn`: `mensaje` de 1 a 4000 caracteres) y extrae comandos de diálogo TIPADOS a partir del turno del cliente.
- Código de Bentho
README.md
La inferencia local corre con un único slot de contexto completo (73k tokens) para mantener latencias predecibles; cualquier petición concurrente se desborda a Groq mientras haya margen de cuota, y de ahí a un proveedor de pago.
- Código de Bentho
README.md
Los dominios son servicios propios con su puerto —Atención :8100, Productos :8200, Facturación :8300, Comercial :8500, Marca :8600, Comprensión :8800, Cerebro :8000— detrás del gateway :3001, repartidos en dos máquinas.