Avahi entregó un pipeline serverless y orientado a eventos en AWS, construido alrededor de un diseño de puertos y adaptadores para que cada dependencia externa quede detrás de una interfaz con una implementación tanto en vivo como offline. El beneficio práctico es que el mismo código corre contra una emulación local durante el desarrollo y contra AWS real en la nube, lo que mantuvo al equipo construyendo mientras aún se gestionaban credenciales y aprobaciones de la plataforma.

La ingesta corre por dos rutas, alineadas con lo que admite cada plataforma. Los comentarios y mensajes directos de Facebook e Instagram llegan como eventos de webhook a un punto de entrada público HTTPS, donde cada solicitud se verifica mediante HMAC antes de aceptar cualquier cosa. X no ofrece un acceso equivalente por webhook en los niveles dentro del alcance, así que una función programada consulta las menciones cada cinco minutos. Ambas rutas normalizan el mensaje a una forma común y lo colocan en una cola de Amazon SQS, que separa la recepción de un mensaje de su procesamiento y le da al pipeline una ruta de reintento y una cola de mensajes muertos cuando falla una llamada downstream.

Una función worker consume esa cola y clasifica cada mensaje con Claude Haiku 4.5 de Anthropic en Amazon Bedrock, ordenándolo en una de cinco categorías: Gestión de casos, Política, Consulta de prensa, Feedback y Amenaza/Abuso. La clasificación es zero-shot, sin entrenamiento ni fine-tuning del modelo, así que la taxonomía y sus reglas de frontera viven en el prompt y pueden revisarse sin reentrenar. La distinción más difícil resultó ser entre la crítica hostil al desempeño de una oficina y el abuso genuino dirigido a una persona. Avahi lo resolvió con un principio en lugar de una lista de palabras clave, separando ambos por el objetivo de la hostilidad, lo que elevó el recall en la categoría Amenaza/Abuso de 70 % a 90 % y, como generaliza en lugar de hacer pattern-matching, se sostuvo ante redacciones que el clasificador nunca había visto.

Luego, los mensajes clasificados fluyen por matching, enrutamiento y almacenamiento. El remitente se asocia con un contacto existente del CRM por handle normalizado o se crea un nuevo contacto, para que un constituyente que escribe repetidamente no se duplique. Los elementos de gestión de casos se asignan al equipo correcto mediante una capa de reglas impulsada por configuración y se almacenan con trazabilidad completa, es decir, la plataforma, la publicación de origen, el comentario y un permalink, para que un miembro del personal siempre pueda rastrear un caso hasta el mensaje que lo inició. Todo se persiste en una única tabla de Amazon DynamoDB cuyo diseño de clave hace que la deduplicación sea una búsqueda directa por clave en lugar de un escaneo.

Dos APIs cierran el ciclo. Un endpoint de publicación de respuestas acepta una respuesta redactada por el personal y la publica de vuelta en el hilo de origen, eligiendo entre respuesta a comentario o mensaje directo según cómo haya llegado el mensaje. Una API de hand-off de solo lectura, protegida por una API key y cerrada por defecto cuando no hay una key configurada, permite que Revere extraiga los registros de gestión de casos clasificados y los contactos asociados según su propio calendario. Las respuestas siempre las escribe una persona; el sistema las publica, pero no las redacta.

El sistema tal como se construyó es deliberadamente más liviano que el diseño propuesto originalmente. Un servicio de streaming se reemplazó por una cola, un clúster de búsqueda para deduplicación se reemplazó por una búsqueda directa por clave y una capa completa de API gateway se reemplazó por un único punto de entrada verificado, cada uno porque el componente más simple cubría por completo el requisito a este volumen. Las credenciales sociales se guardan en AWS Secrets Manager y se cargan en el runtime en el cold start, cada función corre bajo un rol de mínimo privilegio, los logs estructurados van a Amazon CloudWatch y los tokens nunca se escriben en los logs. Todo el stack está definido como código con AWS CDK, para que Civic pueda levantarlo en su propia cuenta.

El pipeline se desplegó y se probó en AWS, con una ejecución end-to-end que llevó un evento de webhook firmado a través de la cola y el modelo hasta un registro de gestión de casos almacenado, y se confirmaron los recorridos de respuesta a comentarios y mensajes directos contra cuentas reales. La conexión de las cuentas oficiales en vivo del miembro y el cutover a producción quedan a cargo de Civic, que es dueño de ese paso por razones de cumplimiento. Avahi también entregó una aplicación web de evaluación y demostración que muestra resultados de precisión, una bandeja de entrada en vivo a través de las tres plataformas con un cuadro de respuesta y un cuadro de “clasificar cualquier mensaje” usado para ejercitar el modelo desplegado durante las sesiones de revisión.