Si estás armando un chatbot en AWS y no sabes si partir de Amazon Lex o de Bedrock Agents, la pregunta correcta no es cuál es mejor en general, sino qué tan predecible necesitas que sea la conversación. Son dos modelos distintos de construir agentes conversacionales y mezclarlos sin entender la diferencia es la causa más común de proyectos que se traban a mitad de camino.
Amazon Lex: intents, slots y flujos que controlas tú
Lex funciona con una lógica de intents (la intención del usuario) y slots (los datos que necesitas recolectar para cumplirla). Si el usuario quiere agendar una cita, defines el intent 'agendar_cita' y los slots 'fecha' y 'hora'; Lex se encarga de preguntar lo que falta hasta completar el flujo. Es determinista: tú decides exactamente qué puede pasar en cada paso, y eso lo hace ideal para procesos con reglas de negocio estrictas, como confirmar un pago o validar una identidad.
El Taller de Creación de Agentes Inteligentes con AWS arranca justo por acá: Lex con intents y slots, después Lambda para lógica dinámica y DynamoDB para persistir datos en tiempo real, y cierra con Amazon Polly para que el mismo agente responda por voz además de texto. Son 11 horas en 4 sesiones, con certificado y proyecto incluido.
Bedrock Agents: razonamiento con LLM y RAG
Bedrock Agents cambia el modelo: en vez de intents fijos, el agente usa un modelo fundacional (Claude, por ejemplo) para razonar sobre qué hacer con la pregunta del usuario, y puede conectarse a Knowledge Bases para hacer RAG sobre documentación propia sin que tú programes cada rama de la conversación. Es mucho más flexible frente a preguntas que no anticipaste, pero esa misma flexibilidad significa menos control exacto sobre lo que el agente puede decir.
Cuándo usar cada uno
- ▸ cuando el flujo es un proceso con pasos fijos: reservas, soporte de primer nivel, validaciones. Necesitas que el agente nunca se salga del guion.
- ▸ cuando la pregunta puede venir en cualquier forma y necesitas que el agente busque la respuesta en una base de conocimiento, no que siga un árbol de decisiones.
- ▸ cuando el caso de uso lo pide: Lex maneja el flujo transaccional (agendar, cancelar, confirmar) y delega a un Bedrock Agent las preguntas abiertas que no calzan en ningún intent definido.
Lo que casi nadie menciona: migrar un bot ya construido en Lex hacia Bedrock Agents no es un simple cambio de proveedor. Tienes que repensar la conversación completa, porque pasas de un modelo de árbol de decisiones a uno de razonamiento abierto. Si tu bot en Lex ya funciona bien para su caso de uso actual, no hay razón de negocio para migrarlo solo por usar el componente más nuevo.
El costo también cambia de modelo
Lex cobra por solicitud de voz o de texto procesada, un modelo predecible que escala de forma lineal con el volumen de conversaciones. Bedrock Agents cobra según los tokens que consume el modelo fundacional en cada turno, lo que significa que una conversación larga con mucho contexto de Knowledge Base cuesta más que una pregunta corta. Antes de decidir cuál usar en un proyecto con presupuesto ajustado, vale la pena estimar cuántos tokens promedio va a consumir cada conversación, no solo cuántas conversaciones esperas.
Seguridad y despliegue: lo que comparten ambos
Más allá del modelo conversacional, el taller cubre IAM para gestionar permisos del agente (quién puede invocarlo, a qué servicios puede llamar) y el despliegue en interfaces web con el SDK de AWS. Esa parte es igual de importante seas cual seas el enfoque que elijas: un agente sin permisos bien configurados en IAM es un riesgo de seguridad, no una feature menor.
Un ejemplo de cómo se combinan en la práctica
Piensa en un chatbot de soporte para una tienda online. El intent 'rastrear_pedido' en Lex pide el número de orden (un slot fijo) y consulta DynamoDB para devolver el estado exacto: ahí no hace falta ni conviene usar un LLM. Pero si el mismo usuario pregunta algo que no calza en ningún intent —'¿puedo cambiar la dirección de envío si ya salió del almacén?'— ese mensaje se delega a un Bedrock Agent conectado a una Knowledge Base con las políticas de la tienda, que sí puede razonar sobre una pregunta que nadie programó de antemano.
Si estás empezando: por dónde partir
Si nunca has construido un chatbot en AWS, empieza por Lex aunque tu objetivo final sea trabajar con Bedrock Agents. Entender cómo se modela una conversación con intents y slots te da el vocabulario para después reconocer qué partes de un flujo sí necesitan razonamiento abierto y cuáles no. Saltar directo a un agente generativo sin ese contexto suele terminar en un bot que intenta resolver con un LLM problemas que un flujo de reglas simples resolvía mejor y más barato.
Esa es también la razón por la que el taller está ordenado así: primero construyes el agente determinista con Lex, Lambda y DynamoDB en las dos primeras sesiones, y recién con ese modelo mental claro avanzas a los canales de voz con Polly y al despliegue multicanal. Llegar a Bedrock Agents sin haber pasado por esta base es posible, pero el criterio para decidir cuándo usar cada enfoque se aprende construyendo el flujo determinista primero.
Para equipos que ya decidieron apostar por el enfoque de modelos fundacionales con Bedrock y Claude, la Especialización en IA Generativa en AWS profundiza en Bedrock, Knowledge Bases y RAG empresarial. Y si el objetivo final es dominar agentes en cualquier nube, no solo AWS, la ruta AI Agentic Engineer conecta este taller con LangChain, LangGraph y arquitecturas de producción multicloud.
