Cómo Escala reconstruyó su plataforma multi-tenant de agentes de IA sobre Amazon Bedrock AgentCore

El CRM de Escala permite a equipos comerciales de toda América Latina gestionar sus conversaciones de venta desde una única bandeja de entrada multicanal. Sus agentes de IA, sin embargo, corrían sobre un constructor heredado en el que todo el comportamiento de cada agente vivía en un único bloque de texto. Junto a Craftech, AWS Advanced Tier Services Partner, Escala reemplazó ese motor por una capa de agentes multi-tenant reconstruida de punta a punta sobre Amazon Bedrock AgentCore Runtime. La inferencia corre en Amazon Bedrock, un guardrail gestionado revisa cada turno y el consumo de tokens se mide por tenant. La plataforma atiende conversaciones reales de WhatsApp desde agosto de 2026.

Sobre Escala

Escala es un CRM SaaS con bandeja de entrada multicanal (WhatsApp, Messenger e Instagram), automatización de marketing y agentes de IA. Sus tenants son equipos comerciales de toda LATAM, incluidas empresas de verticales reguladas que inician sesión mediante proveedores de identidad SAML federados.

El desafío

El constructor de agentes heredado definía cada agente como un único bloque plano de instrucciones. Ese modelo chocó con cinco límites estructurales:

• Agentes contradictorios. La lógica conversacional con ramificaciones, forzada dentro de un solo prompt, producía respuestas inconsistentes o incorrectas, y no escalaba entre tenants con casos de uso distintos.
• Sin un límite de seguridad auditable. Una instrucción en el prompt puede eludirse desde lo que escribe el usuario y no deja evidencia de que actuó. Eso dejaba fuera de alcance a las verticales reguladas, como los agentes que hablan de inversiones.
• Sin memoria entre conversaciones. Los agentes perdían todo el contexto al terminar una conversación.
• Recuperación e integraciones limitadas. La recuperación era solo vectorial y fallaba con datos tabulares, y no había una forma escalable de conectar los sistemas propios de cada tenant.
• Sin plano de gobierno. No había guardrail gestionado, ni trazabilidad por turno, ni control de calidad antes de publicar un agente, y la observabilidad era manual.

En lo comercial, la calificación y el seguimiento de leads seguían dependiendo del trabajo manual del equipo de ventas de cada tenant. Escala necesitaba agentes de IA configurables y seguros como diferencial de su CRM.

La solución: cinco decisiones de arquitectura

Craftech construyó Nexo, un runtime que ejecuta agentes multi-turno configurables por cada tenant, junto con un constructor visual que funciona como su plano de configuración y gobierno. Reemplazó por completo al constructor heredado, sin capa de compatibilidad hacia atrás y sin migración de datos.

1. Cómputo agéntico gestionado

El agente corre en Amazon Bedrock AgentCore Runtime y llama a Claude Sonnet 5 en Amazon Bedrock a través de la Converse API, de modo que el modelo es un valor de configuración y no un compromiso de arquitectura. El equipo documentó la alternativa: el loop podría haber corrido en AWS Lambda o Amazon ECS, pero las sesiones, los turnos largos, el streaming y la trazabilidad por paso son exactamente lo que AgentCore gestiona. El runtime nunca es accesible desde internet; su único punto de entrada es una invocación firmada con SigV4 desde el dispatcher.

2. Un motor de agentes configurable

Los agentes se arman con pasos que tienen criterios de completitud y escenarios de interrupción. En cada turno, el motor verifica qué criterios se cumplen, mueve el foco al primer paso abierto y deja que cualquier escenario interrumpa el flujo según el texto del lead, una condición sobre un campo del CRM o ambas, para después retomar donde había quedado. Los agentes pueden escribir campos de Contacto y Oportunidad, crear entidades y aplicar etiquetas en el CRM, enviar PDF y audio, y derivar a una persona o a otro agente. LlamaIndex Workflows aporta una capa delgada de uso de herramientas, lo que mantiene el motor completamente testeable.

3. Un camino de mensajes desacoplado

La bandeja de entrada de Escala publica un evento por turno en una cola Amazon SQS FIFO agrupada por conversación, con deduplicación y una cola de mensajes fallidos (dead-letter queue). Una función AWS Lambda que actúa como dispatcher la consume, invoca el runtime y entrega la respuesta a la capa de mensajería de Escala. Las imágenes y los documentos se procesan con Amazon Bedrock Data Automation antes de que corra el turno, y los resultados se guardan en caché para que un mensaje reenviado nunca se procese dos veces. El estado de la conversación vive en Amazon DynamoDB on demand, con recuperación a un punto en el tiempo; la memoria duradera por contacto queda en el CRM, que el agente lee en cada turno.

4. La seguridad como control gestionado

En cada turno se aplica un Amazon Bedrock Guardrail, que devuelve una marca explícita de intervención como evidencia de auditoría. La contención también es estructural: el agente nunca envía mensajes por sí mismo, y el tenant decide en la bandeja de entrada si las respuestas salen directo o esperan la aprobación de un vendedor. Antes de que un agente pueda publicarse, el constructor ejecuta una validación de calidad de trece controles, y el historial de publicaciones es inmutable por diseño de IAM, con rollback a cualquier versión anterior.

5. Multi-tenancy y medición

Cada línea de log lleva los identificadores de tenant, agente y conversación, así que una sola búsqueda permite seguir una conversación de punta a punta. El consumo de tokens se registra de forma idempotente en cada turno, por tenant, agente y conversación, y se expone a través de una API de uso. Los créditos se calculan al momento de la lectura a partir de la tabla de equivalencias propia de Escala, por lo que la plataforma no almacena ningún valor monetario. La infraestructura está declarada como código con SST v4 sobre Pulumi y se despliega automáticamente por rama y por stage.

Resultados

La nueva capa de agentes llegó a producción en el hito acordado y hoy atiende conversaciones reales de WhatsApp para los tenants de Escala.

• Entrega a producción en tiempo. El backend salió a producción el 27 de agosto de 2026 y el frontend el 28 de agosto, ambos a través del pipeline, cumpliendo el hito revisado mediante gestión de cambios por dos ampliaciones de alcance pedidas por el cliente.
• Inferencia sobre infraestructura gestionada. Cada llamada al modelo corre en Amazon Bedrock dentro de la propia cuenta de AWS de Escala, con guardrails nativos y la trazabilidad por turno que el motor heredado no tenía.
• Intervención de seguridad verificada. Se verificó que el guardrail bloquea un pedido de asesoramiento financiero y devuelve una marca de intervención como evidencia de auditoría: el control que abre la puerta a las verticales reguladas.
• Validación de calidad: de no existir a ser obligatoria. Todo agente debe pasar trece controles antes de salir a producción; la plantilla de referencia y el agente piloto obtienen 13/13.
• Atribución de costos por tenant. Donde la plataforma heredada contaba créditos por mensaje, ahora el consumo se registra por tenant, agente y conversación, separado en tokens de entrada, de salida y de caché. Las escrituras fallidas se encolan y se reprocesan de forma idempotente, así que ningún turno queda sin medir.
• Controles de calidad de ingeniería. En cada pull request corren 843 tests de backend y 760 de frontend, con 82% de cobertura de sentencias en el backend; ningún cambio llega a un entorno por fuera del pipeline.
• Sin costo fijo por hora. La carga es serverless de punta a punta (AgentCore Runtime, Lambda, DynamoDB on demand, SQS, Amazon S3 y Amazon CloudFront), así que el costo acompaña a las conversaciones atendidas y tiende a cero para un tenant inactivo. Cada recurso lleva nueve etiquetas de asignación de costos.

Lecciones aprendidas

• Testear el formato que realmente envía producción. Un cambio obligado de HTTP API a REST API en Amazon API Gateway modificó cómo llegaban las rutas y los claims del authorizer, y cientos de tests que pasaban no lo detectaron. El equipo sumó tests construidos sobre el formato real del gateway y escribió un postmortem.
• La seguridad tiene que poder operarla el cliente. Craftech diseñó roles OIDC por repositorio para el CI, y luego acordó adoptar el flujo de pipeline que Escala ya tenía bajo su administración, manteniendo versionado el diseño OIDC para una etapa posterior y registrando la decisión en un architecture decision record.
• Integrar contra el servicio real, no contra la documentación. Varias discrepancias aparecieron recién al probar contra las APIs reales, y las dependencias del cliente, no los bloqueos internos, fueron el principal riesgo de calendario. Un checklist con fechas que separaba el trabajo de Craftech de lo que esperaba respuesta del cliente mantuvo el hito en tiempo.

Próximos pasos

Con el runtime en producción, Escala puede ofrecer a sus tenants agentes configurables con seguridad auditable y visibilidad de costos por conversación, incluso en verticales reguladas que el constructor heredado no podía atender.