Inteligencia social multiagente con Strands Agents y Amazon Bedrock

Sus prospectos dejan rastros en múltiples fuentes: un fundador pregunta "¿Qué debo usar para X?" en r/SaaS mientras su producto se lanza en Hacker News. Las preguntas de Stack Overflow aumentan. Un repositorio de GitHub supera las 2400 estrellas. Cada señal por sí sola es ruido, pero correlacionadas entre fuentes, revelan un cliente potencial listo para comprar. Los sistemas multiagente creados con Strands Agents y Amazon Bedrock AgentCore pueden automatizar esta inteligencia social a escala.

Thrad.ai está construyendo la infraestructura publicitaria para la IA, introduciendo anuncios pagos en los LLM. Su plataforma permite monetizar las interfaces de chat a través de anuncios y permite que las marcas se anuncien en ellos. Se enfrentaron a una versión de este problema especialmente rica en señales. El seguimiento manual de estos patrones no escala y la divulgación genérica carece del contexto que hace que valga la pena abrir el correo electrónico. El equipo de ventas de Thrad.ai dedicó entre 30 y 45 minutos a investigar cada cliente potencial en seis fuentes antes de escribir un correo electrónico de divulgación.

Un solo agente de IA no puede resolver esto: la diversidad de señales es demasiado amplia, las API de origen demasiado variadas y el análisis demasiado matizado para que un modelo pueda manejarlo bien. Con la orquestación de múltiples agentes, usted asigna cada fuente a un agente especializado y luego fusiona los resultados a través de un agente de análisis dedicado que detecta patrones entre fuentes.

Esta publicación muestra cómo Thrad.ai implementó un sistema multiagente con Strands Agents y Amazon Bedrock AgentCore que automatiza el proceso desde el descubrimiento de prospectos hasta la generación de correo electrónico personalizado. La publicación compara dos patrones de orquestación (Swarm y Graph) con puntos de referencia directos sobre latencia, costo y calidad del correo electrónico. También aprenderá cómo el sistema califica a los prospectos utilizando criterios ponderados, clasificación de intenciones y deterioro temporal, además de controles de gobernanza para la implementación de producción.

Puede aplicar estos patrones a la inteligencia competitiva, la búsqueda de candidatos y la investigación de mercado. Hay un repositorio complementario disponible para ayudarle a seguir el proceso.

Requisitos previos

Esta publicación asume familiaridad con Python, los conceptos básicos del kit de desarrollo en la nube de AWS (AWS CDK) y los conceptos de modelos de lenguaje grande (LLM).

Cuenta de AWS con acceso a Amazon Bedrock (modelo Claude Sonnet 4.6 habilitado) y Amazon Bedrock AgentCore. Permisos para Amazon DynamoDB, AWS Lambda, AWS Secrets Manager y AWS CDK. Python 3.12+, Node.js 18+ strands-agents>=1.25.0, bedrock-agentcore[strands-agents]>=1.2.1, pydantic>=2.12.5 Aproximadamente 60 minutos para la implementación práctica, aproximadamente entre $3 y $5 (invocaciones del modelo Amazon Bedrock). Importante: Los recursos implementados (tablas de DynamoDB, funciones Lambda, servicios AgentCore) generan cargos durante su ejecución. Complete los pasos de limpieza después de finalizar el tutorial para evitar costos continuos.

Nota: Puedes seguir esta publicación conceptualmente sin implementarla. Para ejecutar el código usted mismo, necesitará los requisitos previos anteriores.

# Clonar el repositorio complementario git clone https://github.com/aws-samples/sample-multi-agent-social-intelligence-strands-agentcore cd sample-multi-agent-social-intelligence-strands-agentcore # Instalar dependencias con uv uv sync # Implementar infraestructura cd infra && cdk implementar –all

Guía de configuración completa: README.md

Descripción general de la solución

Con esta arquitectura ilustrada en la Figura 1, puede convertir automáticamente las señales sociales sin procesar en un alcance personalizado. Cuatro agentes especializados se encargan del descubrimiento, el enriquecimiento, la puntuación y la generación de correo electrónico, cada uno con sus propias herramientas y una estricta validación de resultados.

Canalización de cuatro agentes con Amazon Bedrock AgentCore Runtime, Gateway, Memory y Observability

La siguiente tabla describe la función, las herramientas y los servicios de AgentCore de cada agente que utiliza.

Herramientas de rol de agente Servicios AgentCore Investigación de tendencias Descubre lanzamientos de tendencias y señales de intención de compra Hacker News, YouTube, dev.to, ProductHunt, Reddit, tiempo de ejecución de API de Stack Overflow, especialista en búsqueda de Gateway Enriquece los perfiles de clientes potenciales con contexto Wikipedia, GitHub, Lobste.rs, tiempo de ejecución de API de Stack Overflow, análisis de Gateway Puntuaciones de pares de tendencia-prospecto (0-100) Motor de puntuación, tiempo de ejecución de comparación de ICP, generación de correo electrónico de memoria Borradores de alcance personalizado Conocimiento de la marca recuperación, almacenamiento de clientes potenciales Tiempo de ejecución, puerta de enlace, memoria

Dos agentes inician la recopilación de datos en paralelo. El agente de investigación de tendencias consulta seis fuentes (Hacker News, YouTube, dev.to, ProductHunt, Reddit, Stack Overflow) en busca de lanzamientos de tendencias y señales de intención de compra. Mientras tanto, el agente especialista en búsqueda enriquece a cada cliente potencial a través de Wikipedia, GitHub, Lobste.rs y Stack Overflow.

Una vez que ambos agentes terminan, el agente de análisis califica cada par de prospecto-tendencia de 0 a 100 utilizando Claude Sonnet 4.6 en Amazon Bedrock. Los agentes utilizan un perfil de inferencia global (global.anthropic.claude-sonnet-4-6), que enruta las solicitudes a la región disponible más cercana. Esto evita los ARN de modelos específicos de una región en las políticas de IAM y agiliza la implementación en varias regiones. Los prospectos con puntajes altos fluyen hacia el Agente de Generación de Correo Electrónico, que redacta mensajes de correo electrónico personalizados vinculados a tendencias específicas y valida cada borrador según las pautas de la marca.

Cada agente posee una responsabilidad, un conjunto de herramientas y un contrato de salida validado por Pydantic. Pydantic es una biblioteca de validación de datos de Python que aplica esquemas de seguridad de tipos en tiempo de ejecución. Si un agente devuelve datos en el formato incorrecto, el sistema los detecta antes de que los vea el siguiente agente.

La herramienta Reddit escanea cinco subreddits (r/SaaS, r/startups, r/devtools, r/selfhosted, r/Entrepreneur) y utiliza la coincidencia de patrones de palabras clave para clasificar las publicaciones en cuatro categorías de intención: búsqueda de recomendaciones, frustración de la competencia, lanzamiento de producto e intención de compra. Cuando el lanzamiento de Hacker News también aparece en Reddit "¿qué herramienta debo usar?" hilo, ese prospecto obtiene una puntuación más alta.

La puntuación se basa en la triangulación de señales: un cliente potencial necesita evidencia correlacionada de al menos dos fuentes independientes. El agente de investigación de tendencias primero llama a check_existing_leads para omitir los prospectos que ya están en proceso. Una publicación de tendencia de Hacker News sin discusión en Reddit, sin actividad de Stack Overflow y sin estrellas de GitHub probablemente refleje un impulso promocional. El sistema lo filtra antes de gastar tokens en análisis.

El Agente de Análisis aplica cinco criterios ponderados: alineación temática (25%), relevancia temporal (20%), potencial de participación (20%), señales de intención (20%) y calidad de los datos (15%). La coincidencia del perfil de cliente ideal (ICP) suma hasta 10 puntos de bonificación para herramientas de desarrollo con presencia de código abierto y enfoque B2B. La caída temporal agudiza la puntuación: las señales de menos de 24 horas obtienen un peso 1,5 veces mayor, las señales de más de 7 días obtienen un peso de 0,5 veces.

Orquestación de hebras: enjambre versus gráfico

Ahora viene la decisión central del diseño: ¿cómo se coordinan cuatro agentes? Strands Agents proporciona dos patrones de orquestación. Thrad.ai creó ambos y los comparó con la misma carga de trabajo de 50 prospectos. Las siguientes secciones analizan cada patrón y luego presentan los resultados de referencia.

Enjambre: transferencias autónomas

La Figura 2 ilustra cómo los agentes pasan el control a través de la herramienta handoff_to_agent con contexto compartido. En la orquestación de Swarm, los agentes pasan el control dinámicamente utilizando una herramienta handoff_to_agent. El agente de investigación de tendencias descubre prospectos y los entrega al especialista en búsquedas para su enriquecimiento. El especialista en búsqueda pasa a Análisis para su puntuación. Si los datos son escasos, Analysis puede devolverlos a Trend Research para obtener contexto adicional. Los agentes comparten una memoria de trabajo común.

Diagrama de orquestación de enjambre que muestra a cuatro agentes pasando el control a través de transferencias con una memoria de trabajo compartida

Transferencias dinámicas de agente a agente con memoria de trabajo compartida

Los agentes de enjambre actúan como pares autoorganizados con un contexto compartido, donde cada agente decide cuándo traspasarlo a un especialista. Trend Research descubre un cliente potencial y lo pasa al especialista en búsqueda para que lo enriquezca, y el especialista en búsqueda pasa a Análisis para su puntuación.

Si los datos son escasos, Analysis vuelve a Trend Research para recibir más contexto. Esta transferencia bidireccional permite a los agentes solicitar contexto adicional cuando sea necesario.

El siguiente código muestra cómo configurar un Swarm con límites de seguridad:

enjambre = Enjambre( agentes=[agente_de_tendencia, agente_de_búsqueda, agente_de_análisis, agente_de_correo], punto_de_entrada=agente_de_tendencia, max_handoffs=15, tiempo de espera_de_ejecución=1200.0, repetitive_handoff_detection_window=8, repetitive_handoff_min_unique_agents=3,)

Los parámetros de transferencia repetitivos son importantes. Sin ellos, dos agentes pueden hacer ping-pong entre sí indefinidamente. Una ventana de 8 con un mínimo de 3 agentes únicos fuerza el progreso.

Swarm funciona mejor cuando la complejidad del cliente potencial varía y los agentes se benefician al volver a participar en etapas anteriores. Sin embargo, las rutas de ejecución son más difíciles de predecir y el consumo de tokens aumenta debido a la sobrecarga del razonamiento de transferencia.

Gráfico: flujo de trabajo estructurado

La Figura 3 ilustra cómo un gráfico dirigido comienza con una investigación paralela y puntos de entrada de búsqueda, luego converge en el análisis, con una ventaja condicional hacia el correo electrónico. En la orquestación de Graph, los agentes siguen un flujo de trabajo dirigido fijo. Trend Research y Search Specialist funcionan en paralelo como puntos de entrada. El análisis espera a que ambos terminen antes de ejecutarse. Una ventaja condicional activa la generación de correo electrónico, que solo se ejecuta si el cliente potencial obtiene una puntuación de 60 o más.

Diagrama de orquestación de gráficos con investigación paralela y puntos de entrada de búsqueda que convergen en el análisis, luego una ventaja condicional para la generación de correo electrónico

Entrada paralela, control completo de todas las dependencias y umbral de puntuación condicional

El patrón Graph conecta a los agentes a un flujo de trabajo fijo con bordes explícitos y unidireccionales. Trend Research y Search Specialist se ejecutan en paralelo, lo que reduce a la mitad el tiempo de recopilación de datos. El análisis espera que ambos terminen. El correo electrónico se ejecuta solo si el cliente potencial obtiene una puntuación de 60 o más, lo que actúa como puerta de entrada de políticas.

El siguiente código muestra cómo definir un gráfico con puntos de entrada paralelos y aristas condicionales:

builder = GraphBuilder() builder.add_node(trend_agent, "investigación") builder.add_node(search_agent, "search") builder.add_node(analysis_agent, "análisis") builder.add_node(email_agent, "email") builder.set_entry_point("investigación") builder.set_entry_point("búsqueda") wait_for_both = _all_dependencies_complete(["investigación", "búsqueda"]) builder.add_edge("investigación", "análisis", condición=wait_for_both) builder.add_edge("búsqueda", "análisis", condición=wait_for_both) builder.add_edge("análisis", "correo electrónico", condición=_score_above_threshold)

Graph brilla cuando el flujo de trabajo es repetible y la auditabilidad es importante. Cada ejecución sigue el mismo camino, por lo que puedes reproducir errores reproduciendo la misma entrada. La limitación es que no puede retroceder dinámicamente sin bordes de retroalimentación explícitos. Si un agente necesita más contexto, deberá agregar una ventaja de retroalimentación dedicada en la definición del gráfico acíclico dirigido (DAG).

Resultados cara a cara

Ambos patrones se ejecutaron tres veces contra 50 prospectos de Hacker News. Dos revisores calificaron la relevancia del correo electrónico en una rúbrica del 1 al 10 (especificidad, tono, precisión).

Gráfico de enjambre métrico Latencia promedio por cliente potencial 45 s 32 s Latencia P95 78 s 38 s Promedio de tokens por cliente potencial ~12 000 ~8 500 Relevancia del correo electrónico (calificado por humanos) 8,2 7,6 Costo por cliente potencial (est.) ~$0,08 ~$0,06

Impacto empresarial: para un lote de 1000 clientes potenciales, Graph ahorra aproximadamente 3,6 horas de tiempo de procesamiento y 20 dólares en costos de tokens en comparación con Swarm.

Swarm produjo mensajes de correo electrónico de mayor calidad (8,2 frente a 7,6) porque los agentes recurrieron a más contexto cuando los datos eran escasos, mientras que Graph costó un 25 % menos por cliente potencial con límites de latencia más estrictos. Thrad.ai eligió Graph para el procesamiento por lotes nocturno y Swarm para profundizaciones semanales en prospectos de alto valor.

Cómo decidir: elija Gráfico cuando el flujo de trabajo sea repetible y necesite una latencia predecible. Elija Swarm cuando la calidad de la entrada varíe y los agentes necesiten adaptarse. Puede ejecutar ambos en la misma base de código, conmutados por un indicador de configuración.

Implementación en Amazon Bedrock AgentCore

Las cargas de trabajo de producción necesitan aislamiento de sesiones, gestión de capacidad y observabilidad que vayan más allá de la creación de prototipos locales. Amazon Bedrock AgentCore los maneja como servicios administrados. La pila CDK (código de orquestación del lado del cliente que define su infraestructura) implementa cuatro servicios mediante construcciones aws-cdk-lib/aws-bedrock-agentcore-alpha L2:

Runtime aloja agentes en microVM aisladas (máquinas virtuales livianas) con controles de ciclo de vida y autenticación de AWS Identity and Access Management (IAM) (tiempo de espera de inactividad de 15 minutos, vida útil máxima de 8 horas). Gateway proporciona un único punto final de protocolo de contexto modelo (MCP) para las nueve herramientas. MCP es un protocolo estándar para la comunicación de la herramienta LLM. Los agentes descubren herramientas dinámicamente durante el inicio a través de Strands MCPClient. La memoria almacena contexto a corto plazo dentro de las sesiones y datos semánticos a largo plazo entre sesiones. Opcional; los agentes se degradan con gracia sin él. La observabilidad captura rastros distribuidos a través de OpenTelemetry (un estándar abierto para datos de telemetría) con latencia a nivel de intervalo y recuentos de tokens. Se integra con Amazon CloudWatch y servicios de terceros.

Thrad.ai descubrió que las llamadas a la API de YouTube representaron el 40% de la latencia total. Los datos de seguimiento llevaron al equipo a agregar get_with_retry con retroceso exponencial a las llamadas HTTP.

El archivo README complementario de esta publicación de blog y la documentación de AgentCore proporciona la pila de CDK completa, la configuración de Gateway y el tutorial de implementación.

Tutorial: una carrera real

Esto es lo que produce una ejecución de Graph en comparación con el feed actual de Hacker News:

[Gráfico] Nodos iniciales: investigación, búsqueda (paralela) [investigación] 12 publicaciones de HN de tendencia + 4 señales de intención de Reddit, filtradas a 3 lanzamientos de IA [búsqueda] Enriquecimiento de 3 prospectos: estrellas de GitHub, contexto de Wikipedia, discusiones de Lobste.rs [Gráfico] Todas las dependencias completas → inicio: análisis [análisis] Obtuvo 3 prospectos: – Prospecto A (herramienta de revisión de código de IA): 88/100, intención: recomendación_seeking – Prospecto B (panel de monitoreo de ML): 61/100, sin señal de intención – Prospecto C (CLI de ajuste fino de LLM): 45/100, por debajo del umbral, omitido [Gráfico] Borde condicional: puntuación >= 60 → inicio: correo electrónico (Prospectos A, B) [correo electrónico] Se generaron 2 correos electrónicos personalizados, persistieron en DynamoDB

Aquí hay un ejemplo de correo electrónico generado para el cliente potencial A:

Asunto: Vi el lanzamiento de su revisión de código de IA como tendencia en HN Hola, [Nombre], Felicitaciones por cruzar 2400 estrellas en GitHub esta semana: tracción impresionante para una herramienta de revisión de código de IA. Noté el hilo r/SaaS donde los desarrolladores solicitan alternativas a [Competidor]; Su enfoque de las sugerencias contextuales parece abordar exactamente lo que les frustra. Estamos creando Thrad para equipos que amplían el alcance de los desarrolladores. Nuestros clientes lo utilizan para convertir señales como la suya en conversaciones calificadas. Me encantaría tener 15 minutos para compartir cómo fundadores de herramientas de desarrollo similares acortaron su ciclo de ventas. Mejor, [Remitente]

El cliente potencial A obtuvo una puntuación de 88 debido a las señales de fuentes cruzadas (HN + Reddit + dev.to), 2400 estrellas de GitHub que coinciden con los criterios de ICP y todas las señales con menos de 48 horas de antigüedad (1,5 veces el peso temporal). El prospecto C obtuvo una puntuación inferior a 60 y se omitió, ahorrando ~3000 tokens. El patrón Graph procesó los 50 prospectos en menos de 30 minutos.

lo que aprendimos

La creación y evaluación comparativa de ambos patrones de orquestación reveló varios conocimientos para los sistemas de producción multiagente.

Las señales de intención superan las tendencias pasivas: agregar la detección de intenciones de Reddit aumentó los prospectos con una puntuación superior a 80 en un 22 % en nuestras pruebas. Un cliente potencial que pregunta "¿Qué herramienta debo utilizar para X?" convierte a tasas más altas que una tendencia pasiva.

La caída temporal ayuda a prevenir el alcance obsoleto: las señales de menos de 24 horas obtienen un peso 1,5 veces mayor, mientras que las señales de más de 7 días obtienen un peso de 0,5 veces. Un aumento de Stack Overflow de ayer inicia una conversación. Uno del mes pasado es ruido.

Elija el patrón según el trabajo: Swarm gana en calidad cuando los datos son escasos. Graph gana en costo y previsibilidad para el trabajo por lotes. Ejecutar ambos en el mismo sistema, conmutados por un indicador de configuración, le brinda flexibilidad sin mantener bases de código separadas.

Gobernanza y participación humana

Cuando los agentes asuman más decisiones, necesitará barreras de seguridad. El sistema implementa controles en tres niveles:

Puertas de política a través de márgenes condicionales: el borde de análisis a correo electrónico comprueba la puntuación de relevancia. El sistema registra prospectos menores de 60 pero omite la generación de correo electrónico. Puede ampliar este patrón para requerir la aprobación humana antes de la generación del correo electrónico agregando un nodo de revisión. Acceso a herramientas con alcance: cada agente recibe solo las herramientas que necesita. El agente de correo electrónico obtiene store_lead y retrieve_brand_knowledge. Trend Research obtiene check_existing_leads además de herramientas de descubrimiento. Un agente no puede invocar herramientas fuera de su alcance. Límites de seguridad de enjambre: la detección de transferencia repetitiva detiene los bucles. max_handoffs yexecution_timeout limitan el comportamiento autónomo. Estas barreras de seguridad ayudan a evitar el gasto descontrolado de tokens.

Conclusión

Ahora tiene un plan para crear sistemas de inteligencia social de múltiples agentes con Strands Agents y Amazon Bedrock AgentCore. Con los patrones Swarm y Graph, puede adaptar su estrategia de orquestación a las necesidades de su carga de trabajo. Estas técnicas van más allá de la inteligencia de ventas:

Inteligencia competitiva: Reemplace las herramientas de descubrimiento con monitoreo de la competencia. La misma fusión de señales múltiples detecta lanzamientos y cambios económicos. Búsqueda de candidatos: Reemplace el alcance de ventas con el reclutamiento. Las contribuciones de GitHub, la actividad de Stack Overflow y los artículos dev.to son fuertes señales de candidatos. Curación de contenido: reemplace la generación de correo electrónico con recomendación de contenido. Las señales de intención identifican lo que le importa a su audiencia en este momento.

"Trabajar con el equipo de AWS PACE nos ayudó a convertir lo que honestamente era un problema complicado y de múltiples fuentes en algo que realmente podíamos ejecutar en producción. Con Strands Agents y Amazon Bedrock AgentCore, hemos reducido gran parte de la investigación manual y, al mismo tiempo, hemos mejorado el tiempo y la relevancia de nuestro alcance.

Lo que ha sido especialmente útil en la práctica es poder utilizar Graph y Swarm según el trabajo. Graph nos permite procesar lotes grandes de forma rápida y económica, mientras que Swarm nos ayuda a profundizar en clientes potenciales de mayor valor donde el contexto adicional realmente marca la diferencia”.

— Marco Visentin, cofundador y director de tecnología de Thrad.ai

Próximos pasos

Para implementar y personalizar:

Clona el repositorio complementario. Implemente la infraestructura con cdk implementar –all. Configure claves API en AWS Secrets Manager. Intercambie fuentes de datos registrando nuevos destinos Lambda en infra/gateway_stack.py.

Para evaluar Swarm vs. Graph:

Ejecute python scripts/benchmark.py –prospects 50. Compare los resultados de seguimiento en CloudWatch con sus requisitos de latencia y calidad.

Limpiar

Para evitar cargos continuos, elimine los recursos implementados cuando haya terminado de experimentar:

cd infra cdk destruir –todos

Confirme la eliminación cuando se le solicite. Esto elimina las tablas de DynamoDB, las funciones de Lambda, los secretos de Secrets Manager y los servicios de AgentCore. Advertencia: esta acción elimina permanentemente todos los datos de clientes potenciales almacenados en DynamoDB. Exporte cualquier dato que necesite conservar antes de ejecutar el comando de destrucción. Verifique la eliminación en la consola de AWS CloudFormation confirmando que se hayan eliminado todas las pilas.

Sobre los autores

Amit Deol

Amit Deol

Amit es ingeniero sénior de IA en AWS Prototyping e AI Customer Engineering. Se asocia con clientes de AWS para experimentar con nuevas ideas y crear soluciones listas para producción a través de IA generativa, datos y análisis, y transmisión en tiempo real.

Hin Yee Liu

Hin Yee Liu

Hin Yee es gerente senior de participación de IA en AWS Prototyping and AI Customer Engineering. Lidera interacciones con clientes que llevan la IA generativa desde el prototipo hasta la producción, enfocándose en la arquitectura, las prácticas operativas y de equipo que hacen que estas cargas de trabajo sean confiables a escala.

Andrea Tortella

Andrea es cofundadora y directora ejecutiva de Thrad.ai. Antes de Thrad, trabajó en marketing de crecimiento en Perplexity.

Marco Visentin

Marco es el cofundador y director de tecnología de Thrad.ai. Era candidato a doctorado en Aprendizaje Automático en el Imperial College de Londres antes de abandonar sus estudios para crear Thrad.ai.