Tres plataformas que todo el mundo mezcla viven en capas distintas del stack. Este documento las define capa por capa, dibuja una arquitectura agentica corporativa escalable sobre Yujin Forge y NAC-3, y compara ventajas, desventajas, madurez y lock-in -- con los numeros reales de exito de implementacion.
El primer paso para comparar bien es dejar de tratarlos como alternativas intercambiables. Cada uno resuelve un problema distinto.
Plataforma visual de automatizacion (desde 2019). Dispara flujos por trigger (cron, webhook, chat) y los conecta con 400+ integraciones. Su nodo AI Agent esta construido sobre LangChain.js: al cablear cajas, compones un grafo de LangChain con el mouse.
Framework para construir apps LLM. Abstracciones neutrales de proveedor: chains, agents (el bucle executor de tool-calling), memory, retrievers, tools, output parsers. Es codigo que corres tu, en cualquier nube. LangGraph es su capa de orquestacion mas moderna y estable.
Gateway de modelos fundacionales: una sola API + IAM para Claude, Llama, Mistral, Nova, Cohere. AWS lo hostea. Sube de capa con features managed -- Agents / AgentCore, Flows, Knowledge Bases, Guardrails -- que si solapan con n8n y LangChain, pero con lock-in AWS.
Bedrock y LangChain compiten en la capa de agentes/flujos/RAG (managed vs framework), pero cooperan en la capa de modelo: LangChain tiene ChatBedrock y llama a Bedrock por debajo. No son sustitutos limpios.
La trampa mental es creer que una herramienta "escala el agente". Cada capa escala por medios distintos, hostea en sitios distintos, y tiene su propio techo.
Fig. 1 -- Las cinco capas. En resaltado, la posicion de Forge/NAC-3. n8n vive arriba; Bedrock en el brain; LangChain en ejecucion.
El cambio central para volumen: desacoplar el executor (iterative_step) del escritorio y correrlo como fleet headless detras de una cola, con estado compartido y un broker de brain con techo de rate-limit por tenant. n8n queda como orquestador; hito4 como control-plane que nunca ejecuta el brain.
Fig. 2 -- Flujo corporativo. El bucle de Forge no cambia (mismo ACL de verbos, mismo HITL); lo que cambia es donde corre y como se coordina el cupo de brain.
El brain corre donde estan el proyecto y las llaves (fleet / sesion local, segun tier); el worker de hito4 solo relaya. Las llaves BYOK viven solo en el vault cifrado -- la AgentDefinition referencia brain_tier, nunca la llave. El mismo patron que Bedrock resuelve con IAM, aqui se resuelve con verbos + vault, sin ceder el control al proveedor.
Nota de implementacion: los semaforos de concurrencia de runtime.ts son hoy in-memory (mono-proceso). Pasar a fleet exige moverlos a coordinacion distribuida (cola / redis) -- es refactor, no config. Es la decision de runtime + storage que hoy bloquea el tier P3.
Cada plataforma brilla en su capa. La comparacion honesta no es "cual es mejor" sino "que ganas y que cedes" al apoyarte en cada una en lugar del bucle propio de Forge.
iterative_step): cero lock-in de framework.Lo verificable. La pregunta de negocio real: si construyo hoy, ¿me rompe el proximo upgrade y cuanto me cuesta salir?
| Dimension | n8n | LangChain | Bedrock | Forge + NAC-3 |
|---|---|---|---|---|
| Madurez del core | Alta (2019) | Media-Alta (1.0 nov-2025) | Alta (modelos) / Baja (agentes) | Producto propio, en evolucion a P3 |
| Backward-compat | Fuerte -- nodos versionados | Buena desde 1.0; churn historico | API estable; modelos caducan (EOL) | Tu controlas el contrato de verbos |
| ¿Te ata a la version? | Poco -- tu pineas el self-host | Menos que antes; semver real | Si -- el EOL de modelo fuerza migracion | No -- eres dueno del codigo |
| Grado de lock-in | Medio (JSON propietario) | Medio (libreria, arrancable) | Alto (AWS-proprietary) | Bajo (neutral, self-host) |
| Politica de breaking | BREAKING_CHANGES.md por release | Solo en major (2.0); deprecados viven en 1.x | Aviso min. 6 meses antes de EOL de modelo | Definido por ti (contrato NAC-3) |
Trampa de Bedrock: la API casi nunca rompe, pero los model IDs estan versionados y pasan Active -> Legacy (aviso 6 meses) -> acceso extendido a mayor precio -> EOL. El modelo al que fijas tu implementacion va a expirar; hay que re-testear en un calendario que no controlas.
No existe una "tasa de exito" publicada por herramienta. Lo que existe es data de proyectos agenticos en general -- y es demoledora. El fracaso casi nunca es la libreria.
Cambiar n8n por LangChain por Bedrock no mueve tu tasa de exito. Lo que la mueve son los condicionantes: alcance medible, evaluacion, control de coste y gobernanza. Ahi es donde Forge + NAC-3 juega su ventaja real.
Agente estrecho con metrica de exito clara. El scope difuso es el asesino #1.
Forge: verbos acotan el scopeSi no puedes medir si el agente acierta, no llegas a produccion.
Forge: audit log por verboEl "escalating cost" de Gartner. Sin techo por tenant, se cancela por factura.
Forge: brain_tier + brokerControles de riesgo insuficientes = proyecto muerto.
Forge: ACL de verbos + HITLTools flojas -> agente inutil, por bueno que sea el modelo.
Forge: NAC-3 verbs tipadosMadurez de MLOps/DevOps del equipo que lo opera.
Forge: fleet + CI de agentesCompite en las capas que deciden si un proyecto agentico sobrevive: gobernanza por verbos, neutralidad de brain y control de coste por tenant. El pitch corporativo no es "mejor libreria" -- es disciplina de evaluacion, techo de coste y gobernanza incorporada. Eso es lo que separa al 11% del resto.