AppBarrio es un sistema serverless en AWS para reservar canchas comunitarias por chat. Amazon Q in Connect razona y orquesta, mientras que Amazon Lex V2 ejecuta la lógica transaccional sobre AWS Lambda y DynamoDB.
En este artículo cuento por qué diseñé la solución de esta manera, cómo conecté sus componentes y qué aspectos todavía no llegué a medir.
El problema
En muchos barrios de Perú, reservar una cancha comunal puede ser complicado. No siempre existe un sistema accesible para gestionar las reservas, lo que abre la puerta a cobros informales y a que los horarios terminen siendo ocupados siempre por las mismas personas.
Quise explorar si un asistente conversacional podía hacer este acceso más ordenado y equitativo, protegiendo horarios para grupos que suelen quedar fuera.
El resultado fue AppBarrio: un agente de IA que responde preguntas sobre precios, reglamento y horarios, y que también permite gestionar reservas por chat, sin necesidad de instalar aplicaciones adicionales ni completar formularios largos.
¿Por qué elegí un agente?
Un flujo basado únicamente en reglas habría sido suficiente para distinguir entre una consulta y una reserva. Sin embargo, elegí un agente porque quería que la conversación fuera más natural y pudiera interpretar mensajes que no necesariamente encajan en reglas predefinidas.
Para las operaciones críticas, mantuve un bot determinista.
Necesitaba un componente que pudiera interpretar lo que quería hacer cada persona y decidir qué camino seguir:
- Responder preguntas utilizando información de documentos.
- Iniciar el proceso de reserva.
Descubrí que Amazon Connect ofrece capacidades de agentes con LLM de forma nativa, integradas con el chat, la transferencia a agentes humanos y Lex. Por eso decidí aprovechar estos componentes en lugar de construir toda esa infraestructura desde cero.
La arquitectura: un orquestador y un ejecutor
La decisión principal de diseño fue separar el razonamiento de la IA de la ejecución de las operaciones transaccionales.
| Componente | Rol | Responsabilidad |
|---|---|---|
| Amazon Q in Connect | Orquestador | Interpreta los mensajes. Responde consultas mediante RAG sobre documentos en S3, deriva las reservas al bot transaccional y permite escalar a un humano. |
bot-reservas (Lex V2) |
Ejecutor | Bot tradicional basado en intents y slots. Recoge DNI, tipo de cancha, fecha y hora. |
bot-clasificador-q (Lex V2) |
Conector | Bot utilizado para integrar el agente con Lex. No contiene lógica de negocio. |
| AWS Lambda + DynamoDB | Lógica y datos | Ejecutan las operaciones de consulta de saldo, gestión de reservas y generación de resúmenes. |
Un detalle importante: si abres la consola de Amazon Lex, encontrarás dos bots. Uno existe para conectar el agente con Lex; el único que contiene la lógica de negocio es bot-reservas.
Decisiones de diseño
1. Lex para los datos críticos
El DNI, la fecha y la hora son datos importantes para una reserva. Por eso decidí recogerlos mediante slots de Lex, que permiten validar y estructurar la información de forma controlada.
Así reduzco el riesgo de que un LLM interprete incorrectamente o invente datos necesarios para una operación transaccional.
2. Lambdas separadas por responsabilidad
Separé las funciones Lambda según su responsabilidad.
De esta manera, si la consulta de saldo falla, las operaciones de reservas y la generación de resúmenes pueden seguir funcionando de manera independiente.
3. Principio de mínimo privilegio
Cada función Lambda tiene únicamente los permisos que necesita para acceder a sus respectivas tablas y ejecutar sus operaciones.
Esto evita conceder permisos innecesarios a toda la aplicación.
¿Qué ocurre cuando llega un mensaje?
Veamos tres escenarios para entender cómo interactúan los componentes.
Escenario 1: una consulta informativa
Una persona pregunta:
¿Cuánto cuesta la cancha de fútbol?
Amazon Q in Connect interpreta que se trata de una consulta informativa, recupera información de los documentos almacenados en S3 mediante la base de conocimiento y redacta una respuesta en lenguaje natural.
Escenario 2: una reserva
Una persona escribe:
Quiero reservar mañana a las 7.
El agente identifica que se trata de una operación transaccional y deriva la conversación a bot-reservas.
Lex solicita los datos que faltan mediante sus slots. Cuando se completan, invoca la función Lambda correspondiente con un evento similar al siguiente:
{
"sessionState": {
"intent": {
"name": "ReserveCourtIntent",
"slots": {
"sl_customer_dni": {
"value": {
"interpretedValue": "76543210"
}
},
"slt_court_types": {
"value": {
"interpretedValue": "futbol"
}
},
"sl_date": {
"value": {
"interpretedValue": "2026-11-01"
}
},
"sl_time": {
"value": {
"interpretedValue": "19:00"
}
}
}
}
},
"invocationSource": "FulfillmentCodeHook"
}
La Lambda procesa la solicitud, guarda la reserva en DynamoDB y devuelve la confirmación junto con un código de reserva.
Datos y despliegue
La aplicación utiliza dos tablas de DynamoDB:
| Tabla | Clave principal | Uso |
|---|---|---|
sports-customers |
customer_dni |
Información de los usuarios. |
sports-reservations |
reservation_id |
Información de las reservas, con un índice para consultar por cliente y fecha. |
Para desplegar la capa de aplicación utilicé AWS SAM, que administra los recursos definidos en la plantilla, entre ellos:
- Funciones Lambda.
- Tablas de DynamoDB.
- Roles de IAM.
- Políticas y permisos necesarios.
Sin embargo, no toda la infraestructura se crea mediante SAM. Algunos componentes requieren configuración adicional:
- La instancia de Amazon Connect.
- El agente y la configuración de Amazon Q in Connect.
- Los documentos almacenados en S3 y la base de conocimiento.
- Los bots de Amazon Lex V2.
- La interfaz web, que parte de la plantilla proporcionada en el workshop.
Esta separación es importante porque tener una plantilla de infraestructura como código no significa necesariamente que todos los componentes de una solución puedan desplegarse automáticamente desde un único stack.
Lo que aprendí
Uno de los mayores retos fue configurar el agente y ajustar sus prompts. Al ser un servicio relativamente reciente, me apoyé en la documentación oficial y un workshop de AWS, adaptando sus ejemplos a mi proyecto.
Me quedo con una idea: un agente de IA y un bot determinista se complementan. Uno interpreta y gestiona la conversación; el otro ejecuta las operaciones que requieren precisión y validaciones.
Lo que no llegué a medir
El proyecto tiene algunas limitaciones que vale la pena mencionar:
- Costos: no realicé una medición de los costos reales de operación.
- Latencia y rendimiento: no evalué los tiempos de respuesta ni el comportamiento bajo carga.
- Base de conocimiento: actualmente contiene información limitada, como preguntas frecuentes, precios y reglamento. No sé cómo se comportaría con un volumen mucho mayor de documentos.
- Autenticación: no implementé un mecanismo de autenticación de usuarios. La identificación se realiza mediante el DNI proporcionado dentro del chat.
- Calidad de las respuestas: no realicé una evaluación sistemática de las respuestas generadas por el agente.
Por estas razones, AppBarrio debe entenderse como un prototipo para explorar la integración de servicios de IA y arquitecturas serverless en AWS, no como un sistema listo para producción.
Código y cómo reproducirlo
El código fuente, las capturas y la documentación técnica de AppBarrio están disponibles en mi GitHub:
👉 Amazon-Connect-Orchestrator-Executor en GitHub
Un recordatorio si decides clonarlo: utiliza tu propia cuenta de AWS y revisa los precios vigentes de los servicios antes de desplegar los recursos.
Top comments (0)