Con los cimientos puestos (cuentas, identidad, cómputo, red), empieza la integración: cómo se hablan las piezas de la plataforma. Este módulo es el que Felipe llamaría “la columna” — y es también donde se decide el carácter del sistema entero. Porque hay dos formas de conectar servicios: llamadas síncronas (A llama a B y espera la respuesta) y mensajería asíncrona (A deja un mensaje; B lo procesa cuando puede). La primera es intuitiva y encadena fragilidades; la segunda exige pensar distinto y es la razón por la que un agente autónomo puede llamarse autónomo.

La conexión con el módulo 3 es directa: dijimos que el agente es “trabajo que despierta cómputo”. Este módulo construye el mecanismo del despertar — los eventos, las colas y los relojes que convierten esa frase en arquitectura.

La tesis del módulo

En una plataforma de agentes, lo síncrono se reserva para humanos esperando; entre servicios, todo lo que pueda ser asíncrono debe serlo. Una cadena de llamadas síncronas hereda la disponibilidad del peor eslabón y convierte cada pico en una avalancha; una cola entre medio absorbe picos, sobrevive caídas y da reintentos gratis. El agente autónomo no es un servicio que espera peticiones: es un consumidor de colas y un suscriptor de eventos — el trabajo lo busca a él.

Las piezas, glosadas

API Gateway: la puerta de entrada administrada para APIs HTTP — recibe las peticiones del mundo, valida autenticación, aplica rate limits (límites de peticiones por cliente) y enruta al backend. Es la única cara pública de la plataforma; todo lo demás vive detrás, en las privadas del módulo 4.
SQS (Simple Queue Service): la cola administrada. Un productor deja mensajes; consumidores los toman a su ritmo. Cada mensaje se procesa y se borra; si el consumidor falla, el mensaje reaparece (visibility timeout) para reintento. Escala prácticamente infinito y cobra por uso.
DLQ (dead-letter queue, cola de cartas muertas): la cola adjunta donde van los mensajes que fallaron N veces. Sin DLQ, un mensaje venenoso (uno que siempre falla) reintenta para siempre; con DLQ, se aparta para diagnóstico y el flujo sigue.
SNS (Simple Notification Service): publicación en abanico — un mensaje publicado llega a todos los suscriptores (colas, Lambdas, emails). SQS es “uno lo procesa”; SNS es “todos se enteran”.
EventBridge: el bus de eventos — recibe eventos de servicios AWS y propios, y los enruta por reglas de contenido (“cuando llegue un evento tipo X, dispara Y”). Incluye el Scheduler: el reloj administrado que dispara acciones por cron o fecha única, sin cómputo esperando.

La arquitectura del despertar

Así se ve el mecanismo completo con los tres despertadores de un agente autónomo — evento, cola y reloj:

      QUIÉN DESPIERTA AL AGENTE

  correo llega     cada noche 2am     otro servicio
       │                │              publica evento
       ▼                ▼                   │
  ┌─────────┐    ┌─────────────┐            ▼
  │ SQS:    │    │ EventBridge │      ┌───────────┐
  │ cola de │    │ Scheduler   │      │EventBridge│
  │ trabajo │    │ (cron)      │      │ bus+regla │
  └────┬────┘    └──────┬──────┘      └─────┬─────┘
       │                │                   │
       └───────────┬────┴───────────────────┘
                   ▼
           ┌───────────────┐   falla N veces
           │ agente        │ ─────────────────┐
           │ (cómputo      │                  ▼
           │  efímero)     │            ┌──────────┐
           └───────┬───────┘            │   DLQ    │
                   ▼                    └──────────┘
              resultado a BD/cola siguiente

Nota lo que no hay en el diagrama: ningún proceso del agente encendido esperando. La cola retiene el trabajo, el scheduler cuenta el tiempo, el bus enruta los eventos — los tres esperan gratis — y el cómputo del módulo 3 nace cuando hay algo que hacer.

Por qué la cola y no la llamada directa

El caso A del catálogo (clasificar correos) sirve de banco de pruebas. Versión síncrona: el receptor de correos llama al agente por HTTP y espera. Versión con cola: el receptor deja el correo en SQS; el agente consume. Parecen equivalentes hasta que el mundo se porta como el mundo:

Escenario	Síncrono (llamada directa)	Asíncrono (cola)
Pico de 10× correos	El agente se satura; los correos se pierden o el receptor cae en cascada	La cola crece; el agente escala o procesa más lento; nada se pierde
El agente está caído 10 min	10 min de correos perdidos o el receptor los acumula en memoria	Los mensajes esperan; al volver, se procesan todos
Bedrock devuelve error en un correo	El receptor debe implementar reintentos	Reintento gratis: el mensaje reaparece; a la N, DLQ
¿Quién conoce a quién?	El receptor conoce la URL del agente (acoplados)	Ambos conocen la cola (desacoplados: reemplazables por separado)

La columna derecha es la definición operativa de resiliencia — y salió gratis, del patrón, no de código defensivo. Este es también el retry del componente 4 de la landing zone implementado en infraestructura: la cola es el mecanismo de reintento con tope y apartadero.

Cuidado — idempotencia, el precio de la cola: SQS estándar garantiza al menos una entrega — ocasionalmente un mensaje llega dos veces. El consumidor debe ser idempotente: procesar el mismo mensaje dos veces no puede duplicar el efecto (dos respuestas al cliente, dos cobros). Se resuelve con una clave de deduplicación (el ID del correo: “¿ya procesé este?”) antes de actuar. Para agentes esto es doblemente serio: sus acciones tienen efectos en el mundo. Todo consumidor de cola de tu plataforma se diseña idempotente, sin excepciones — y las colas FIFO (que garantizan orden y deduplicación a cambio de menos throughput) son la alternativa cuando el orden importa.

La puerta de entrada: API Gateway

Lo que sí es legítimamente síncrono — humanos y sistemas externos pidiendo cosas — entra por API Gateway, y su papel en la plataforma de agentes es de portero con tres funciones: autenticar (quién llama: API keys, IAM, JWT/Cognito), limitar (rate limits y cuotas por cliente — la primera línea contra el unbounded consumption: nadie, ni un bug de un cliente, puede meterte un millón de invocaciones), y desacoplar la entrada (detrás del gateway, la petición puede volverse asíncrona de inmediato: el gateway deja el trabajo en la cola y responde “recibido, ID 123” — el patrón para todo lo que tarde más de unos segundos, como una cotización del caso B).

Ojo: el LLM gateway del módulo 7 y el API Gateway de este módulo son porteros distintos. API Gateway es la puerta de entrada de la plataforma (el mundo → tus servicios); el LLM gateway es la puerta de salida hacia los modelos (tus agentes → Bedrock y proveedores). Se parecen en espíritu — punto único, límites, auditoría — y confundirlos es un error de mapa clásico.

Herramientas del agente como APIs internas

Última pieza conceptual: las herramientas del agente (consultar el CRM, buscar el historial) son, en arquitectura, llamadas a APIs — y conviene que sean APIs internas concretas y no un “fetch URL” genérico (la lección de egress del módulo 4). El estándar emergente para exponerlas es MCP (Model Context Protocol): servidores de herramientas que el agente descubre y llama con un contrato tipado. En AWS, un servidor MCP es simplemente otro microservicio de esta arquitectura — corre en el cómputo del módulo 3, vive en las privadas del módulo 4, y sus permisos son los del módulo 2. La plataforma no distingue “herramientas de IA” de “microservicios”: son lo mismo con contrato nuevo.

Errores comunes

Encadenar servicios con llamadas síncronas. A llama a B que llama a C: la disponibilidad total es el producto de las tres y el pico se propaga como avalancha. Cola entre medio salvo que un humano esté esperando la respuesta.
Colas sin DLQ. Un mensaje venenoso sin apartadero reintenta infinito, consume el throughput y entierra los mensajes sanos. DLQ en toda cola, con alarma cuando reciba algo (módulo 11).
Consumidores no idempotentes. “Al menos una entrega” + efectos en el mundo real = duplicados dolorosos. Clave de deduplicación antes de todo efecto, siempre.
Cron en un contenedor encendido. Un proceso 24/7 cuyo único trabajo es mirar el reloj es el anti-patrón del módulo 3 disfrazado. EventBridge Scheduler dispara; el cómputo nace.
Exponer los agentes directo, sin gateway. Sin autenticación central ni rate limits, cada servicio implementa (mal) su propio portero, y el unbounded consumption entra por la puerta menos vigilada.
Darle al agente un fetch genérico en vez de herramientas concretas. Cada herramienta como API interna concreta (idealmente MCP) mantiene el egress corto y el contrato auditable; el fetch genérico convierte al agente en proxy de exfiltración.

La frase para llevarse

“El agente autónomo no espera trabajo: el trabajo lo despierta — por cola, por evento o por reloj. Lo síncrono se reserva para humanos mirando la pantalla; entre servicios, la cola absorbe los picos, regala los reintentos y desacopla las piezas. Y todo consumidor es idempotente, porque ‘al menos una vez’ significa ‘a veces dos’.”

Qué viene

Módulo 6: estado y datos. El cómputo es efímero y las colas se vacían — pero el agente necesita memoria: el historial de conversaciones, el estado de cada flujo en curso, los embeddings para buscar, el caché para no pagar dos veces. AWS ofrece media docena de almacenes (DynamoDB, Aurora, S3, ElastiCache, OpenSearch) y el criterio para repartir cada tipo de dato en el correcto — incluida la decisión vectorial que todo el mundo pregunta: ¿OpenSearch, pgvector o S3 Vectors?

Arquitectura AWS — Módulo 5: microservicios y APIs