AWS Strands Agents: el framework que hace simple lo que antes era complejo
Construir agentes de IA solía requerir meses de trabajo y orquestaciones complicadas. Con Strands, AWS cambió las reglas del juego: prompt + herramientas + modelo, y el agente razona solo. Acá te cuento cómo funciona, cómo integrarlo con tus servicios de AWS y cómo compara con el resto del mercado.

Si trabajás con AWS y empezaste a explorar el mundo de los agentes de IA, probablemente ya te cruzaste con LangChain, CrewAI o AutoGen. Son frameworks que resuelven el problema, pero con un costo alto: te obligan a aprender abstracciones propias, manejar estados manualmente y escribir muchísimo código de orquestación que no tiene nada que ver con tu lógica de negocio. Y encima, ninguno de ellos fue diseñado pensando en AWS, lo cual se nota.
En mayo de 2025, AWS lanzó Strands Agents, un SDK open source construido desde adentro del ecosistema AWS, por el equipo que ya lo estaba usando en producción en Amazon Q Developer. La filosofía es diferente: en vez de definir flujos de trabajo paso a paso, le das herramientas al modelo y dejás que él decida cómo usarlas. Menos código de infraestructura, más foco en lo que el agente tiene que hacer.
En este artículo vamos a ver cómo funciona Strands desde adentro, cómo conectarlo con los servicios que ya usás en AWS, casos de uso concretos para equipos de DevOps y cómo compara con las alternativas más usadas hoy.
¿Qué es Strands y cuál es la diferencia?
Strands no es un framework de orquestación tradicional. La diferencia fundamental está en quién toma las decisiones sobre cómo resolver una tarea: en LangChain o LangGraph, esas decisiones las tomás vos, definiendo grafos de nodos y bordes. En Strands, las toma el modelo de lenguaje.
El concepto central se llama model-driven approach: le pasás al LLM un prompt con el objetivo, un conjunto de herramientas disponibles, y él determina por sí mismo qué herramientas invocar, en qué orden, y cómo encadenar los resultados hasta completar la tarea. Esto es el agentic loop de Strands.
Este enfoque pega muy bien con los modelos actuales, que tienen capacidades de razonamiento mucho más sofisticadas que hace dos años. El equipo de Amazon Q Developer, que es donde nació Strands internamente, reportó que pasó de tardar meses en llevar un agente a producción a hacerlo en días o semanas.
Hoy el SDK tiene más de 14 millones de descargas, soporte para Python y TypeScript, y se usa en producción dentro de Amazon Q Developer, AWS Glue y el proyecto Kiro (el IDE con IA de AWS).
📌 Open Source
Strands es 100% open source (Apache 2.0). El repositorio está en
github.com/strands-agents/sdk-python. No estás atado a AWS para usarlo: soporta Anthropic, OpenAI, Gemini, Ollama, LiteLLM y más como proveedores de modelo.
Instalación y primer agente en minutos
Empezar con Strands es inusualmente simple. No necesitás configurar grafos, definir estados ni registrar handlers. Veamos cómo se ve desde cero.
Instalación
# Instalar el SDK y el paquete de herramientas pre-construidas
pip install strands-agents strands-agents-tools
# Asegurate de tener credenciales de AWS configuradas
aws configure
# O con variables de entorno:
export AWS_DEFAULT_REGION=us-west-2
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
Por defecto, Strands usa Amazon Bedrock como proveedor de modelo, específicamente Claude 4 Sonnet. Necesitás habilitar acceso al modelo en Bedrock antes de correr cualquier ejemplo.
El agente más simple posible
from strands import Agent
from strands_tools import calculator, current_time
# Así de simple. Prompt + herramientas = agente funcional.
agent = Agent(
system_prompt="Sos un asistente técnico para equipos de DevOps.",
tools=[calculator, current_time]
)
response = agent("¿Cuántos segundos hay en 3 semanas y 2 días?")
print(response)
El agente va a razonar, elegir la herramienta calculator, calcular el resultado y devolver la respuesta. Sin nada más de tu parte.
Crear una herramienta personalizada
Acá está una de las cosas que más me gusta de Strands: convertir cualquier función Python en una herramienta del agente es tan fácil como agregar un decorador. El docstring no es opcional: el modelo lo usa para entender qué hace la herramienta y cuándo invocarla.
from strands import Agent, tool
import boto3
@tool
def get_ec2_instances(region: str = "us-east-1") -> str:
"""
Lista las instancias EC2 corriendo en la región especificada.
Útil para obtener un inventario del estado actual de la infraestructura.
"""
ec2 = boto3.client("ec2", region_name=region)
response = ec2.describe_instances(
Filters=[{"Name": "instance-state-name", "Values": ["running"]}]
)
instances = []
for reservation in response["Reservations"]:
for i in reservation["Instances"]:
name = next(
(t["Value"] for t in i.get("Tags", []) if t["Key"] == "Name"),
"Sin nombre"
)
instances.append(f"{name} ({i['InstanceId']}) - {i['InstanceType']}")
return "\n".join(instances) if instances else "No hay instancias corriendo"
# El agente ahora sabe que puede usar esta herramienta
agent = Agent(
system_prompt="Sos un agente de operaciones AWS. Ayudás a los equipos a entender su infraestructura.",
tools=[get_ec2_instances]
)
agent("Dame un resumen de las instancias que tenemos corriendo en us-east-1")
Integración con servicios de AWS
Acá es donde Strands realmente brilla para quienes ya trabajamos con el ecosistema de AWS. El SDK viene con herramientas pre-construidas para los servicios más usados, y la integración con Bedrock, S3, DynamoDB, Lambda y más es directa.
Agente con acceso a una Knowledge Base de Bedrock
Uno de los patrones más potentes: un agente que busca en tu base de conocimiento interna antes de responder. Podés tener documentación de arquitectura, runbooks, post-mortems, todo indexado en Bedrock Knowledge Bases y disponible para el agente.
from strands import Agent, tool
import boto3
KNOWLEDGE_BASE_ID = "tu-kb-id"
@tool
def buscar_runbook(query: str) -> str:
"""
Busca en la base de conocimiento interna runbooks, guías de operaciones
y documentación de arquitectura. Usá esta herramienta antes de responder
cualquier pregunta sobre procedimientos o infraestructura.
"""
client = boto3.client("bedrock-agent-runtime")
response = client.retrieve(
knowledgeBaseId=KNOWLEDGE_BASE_ID,
retrievalQuery={"text": query},
retrievalConfiguration={
"vectorSearchConfiguration": {"numberOfResults": 5}
}
)
resultados = []
for r in response["retrievalResults"]:
resultados.append(r["content"]["text"])
return "\n---\n".join(resultados)
@tool
def get_cloudwatch_alarms(region: str = "us-east-1") -> str:
"""
Obtiene las alarmas de CloudWatch en estado ALARM.
Útil para diagnosticar incidentes en curso.
"""
cw = boto3.client("cloudwatch", region_name=region)
response = cw.describe_alarms(StateValue="ALARM")
alarmas = [a["AlarmName"] for a in response["MetricAlarms"]]
return f"Alarmas activas: {', '.join(alarmas)}" if alarmas else "Sin alarmas activas"
# Agente de guardia que puede consultar runbooks Y el estado actual
agente_ops = Agent(
system_prompt="""Sos el asistente de operaciones de turno.
Antes de responder cualquier pregunta sobre incidentes,
siempre consultá los runbooks internos y el estado de CloudWatch.""",
tools=[buscar_runbook, get_cloudwatch_alarms]
)
agente_ops("Tenemos latencia alta en el servicio de pagos. ¿Qué deberíamos revisar?")
Integración con MCP (Model Context Protocol)
Strands tiene soporte nativo para MCP, lo que significa que podés conectar tu agente a miles de servidores MCP disponibles en la comunidad. Bases de datos, APIs de terceros, herramientas de monitoreo, todo sin escribir código de integración desde cero.
from strands import Agent
from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters
# Conectar al servidor MCP de AWS (acceso a APIs de AWS via MCP)
aws_mcp = MCPClient(
lambda: stdio_client(
StdioServerParameters(command="uvx", args=["awslabs.aws-documentation-mcp-server@latest"])
)
)
with aws_mcp as client:
tools = client.list_tools_sync()
agent = Agent(tools=tools)
agent("¿Cuáles son los límites por defecto de Lambda en us-east-1?")
Deployment en Lambda o EKS
Para producción, Strands funciona sin problemas dentro de Lambda (para tareas cortas) o en un pod de EKS (para agentes de larga duración). También podés usar Bedrock AgentCore, el runtime managed de AWS para agentes, que soporta tareas de hasta 8 horas con gestión de estado incorporada.
# Wrapper mínimo para deployar en Lambda
import json
from strands import Agent
from strands.models import BedrockModel
model = BedrockModel(
model_id="us.anthropic.claude-sonnet-4-5",
region_name="us-east-1"
)
agent = Agent(
model=model,
system_prompt="Procesás consultas de infraestructura para el equipo de operaciones.",
tools=[get_ec2_instances, get_cloudwatch_alarms]
)
def handler(event, context):
query = event.get("query", "")
response = agent(query)
return {
"statusCode": 200,
"body": json.dumps({"response": str(response)})
}
Multi-agentes: coordinación sin burocracia
Strands 1.0 introdujo cuatro primitivas para orquestar múltiples agentes. El patrón más usado es Agents-as-Tools: transformás agentes especializados en herramientas que un agente orquestador puede invocar.
from strands import Agent
# Agente especialista en seguridad
security_agent = Agent(
system_prompt="Especialista en seguridad AWS. Analizás configuraciones, IAM policies y posibles vectores de ataque.",
tools=[...herramientas de seguridad...]
)
# Agente especialista en costos
cost_agent = Agent(
system_prompt="Especialista en optimización de costos AWS. Identificás recursos sobredimensionados y oportunidades de ahorro.",
tools=[...herramientas de billing y Cost Explorer...]
)
# Orquestador: puede delegar en cualquiera de los dos
orchestrator = Agent(
system_prompt="Coordinás análisis de infraestructura delegando tareas a especialistas según lo que se necesite.",
tools=[
security_agent.as_tool(
tool_name="analizar_seguridad",
tool_description="Analiza la postura de seguridad de un servicio o recurso AWS"
),
cost_agent.as_tool(
tool_name="analizar_costos",
tool_description="Analiza costos y oportunidades de optimización"
)
]
)
orchestrator("Hacé un análisis completo de nuestro entorno de producción en us-east-1")
✓ A2A Protocol
Strands 1.0 implementa el protocolo Agent-to-Agent (A2A), lo que permite que agentes de diferentes frameworks o equipos se descubran y comuniquen entre sí. Podés tener un agente Strands coordinando con un agente de otro framework sin escribir código de integración custom.
Casos de uso para equipos DevOps y AWS
Comparación honesta con los frameworks más usados
El ecosistema de frameworks para agentes explotó en 2025. Cada uno tiene su nicho, y en muchos casos se nota que fueron construidos para el ecosistema OpenAI o Azure, y después adaptados para soportar otros proveedores. Strands nació al revés: primero AWS, y después el resto. Esa diferencia de origen se siente en la práctica.
| Framework | Filosofía | Curva de aprendizaje | Integración AWS | Multi-agente | Soporte MCP | Ideal para |
|---|---|---|---|---|---|---|
| Strands (AWS) | Model-driven | 🟢 Baja | Nativa | Sí (v1.0) | Sí, nativo | Equipos AWS, agentes autónomos rápidos |
| LangGraph | Graph-based, stateful | 🔴 Alta | Parcial | Sí, avanzado | Parcial | Workflows complejos, control total del flujo |
| CrewAI | Role-based teams | 🟡 Media | Limitada | Sí, por diseño | Parcial | Equipos de agentes con roles definidos |
| AutoGen (MS) | Conversacional async | 🟡 Media | Limitada | Sí | No | Debates multi-agente, integraciones Azure |
| OpenAI Agents SDK | Minimalista | 🟢 Muy baja | Limitada | Sí | Parcial | Prototipado rápido en el ecosistema OpenAI |
Strands vs LangGraph: velocidad vs control
LangGraph es potente, pero tiene un costo: te obliga a pensar en grafos, nodos y bordes antes de escribir una sola línea de lógica real. Para alguien que viene del mundo DevOps y quiere automatizar operaciones, ese modelo mental es una barrera de entrada importante. A eso sumale que la integración con AWS requiere configurar adaptadores extra, y que el stack de observabilidad (LangSmith) es un servicio aparte.
Strands te deja llegar al mismo resultado con mucho menos código. Si tu caso de uso es un workflow determinístico con lógica de negocio muy específica donde cada bifurcación importa, LangGraph tiene su lugar. Pero para la mayoría de los agentes operacionales que necesitan un equipo DevOps, la complejidad de LangGraph es overhead que no agrega valor.
Strands vs CrewAI: la trampa de los roles rígidos
CrewAI tiene una propuesta atractiva en papel: modelar el problema como un equipo con roles definidos. El problema es que en operaciones reales, los problemas no llegan etiquetados. Un incidente de producción puede requerir diagnóstico, análisis de costos, revisión de seguridad y comunicación al mismo tiempo, en un orden que no podés predecir. Forzar eso en roles fijos termina siendo una rigidez que juega en contra.
Además, CrewAI fue construido sin pensar en AWS. Conectarlo a tus servicios existentes requiere trabajo extra, y el modelo de costos se puede complicar rápido: un crew con 5 agentes puede costar hasta 5x más en tokens que un único agente Strands bien configurado.
🎯 Veredicto: si usás AWS, Strands es la respuesta obvia
Los otros frameworks no nacieron en AWS. Se adaptaron después, y esa diferencia se siente: configuraciones extra, adaptadores, integraciones parciales. Strands es lo contrario: boto3 funciona de entrada, Bedrock es el provider por defecto, y deployar en Lambda o EKS no requiere nada especial. Es el único framework que no te hace sentir que estás peleando contra tu propia infraestructura.
Para equipos DevOps que viven en AWS, la pregunta no debería ser "¿uso Strands o LangChain?". La pregunta es "¿para qué caso puntual podría necesitar más control del que Strands me da?". Y la respuesta honesta es: para la gran mayoría de casos operacionales, Strands alcanza y sobra.
Cosas a tener en cuenta antes de arrancar
Strands es sólido, pero como cualquier herramienta tiene sus particularidades. Mejor saberlas de antemano que descubrirlas en producción.
El modelo importa. La filosofía model-driven funciona muy bien con modelos modernos como Claude 4 en Bedrock. Si usás modelos más chicos o menos capaces, la calidad de razonamiento baja y el agente puede tomar decisiones subóptimas sobre qué herramienta usar. La buena noticia: en Bedrock tenés acceso a los mejores modelos del mercado con un par de líneas de configuración.
La observabilidad requiere un poco de setup. Strands soporta OpenTelemetry y se integra nativamente con CloudWatch, pero no viene con un dashboard listo para usar. Para producción, conviene invertir unas horas configurando trazas desde el día uno.
Es un framework joven. Con un año de vida pública, la comunidad externa está creciendo. La documentación oficial de AWS es muy buena, pero el volumen de respuestas en Stack Overflow todavía es menor que en frameworks más viejos. Eso va a cambiar rápido dado el ritmo de adopción.
Monitoreá el uso de tokens. Los agentes model-driven hacen más llamadas al LLM para razonar. En Bedrock podés configurar presupuestos y alertas de costo desde el día uno, así que esto es más un recordatorio de buenas prácticas que un problema real.
Conclusión
Strands es lo que pasa cuando el framework lo construye la misma gente que opera la infraestructura. No hay adaptadores, no hay workarounds para hacer que funcione con boto3 o Bedrock, no hay que elegir entre integración nativa y flexibilidad. Simplemente funciona, porque fue diseñado para funcionar así.
La apuesta de AWS con Strands es clara: que construir agentes de IA sobre AWS sea tan natural como construir cualquier otro servicio. Y en gran medida, lo lograron. La misma lógica que usaste para integrar Lambda con S3, o EKS con IAM, aplica para conectar un agente Strands con tus recursos existentes.
Si ya invertiste en el ecosistema AWS, Strands no es solo una opción más. Es el camino natural hacia agentes de IA en producción. Y con 14 millones de descargas en menos de un año y soporte activo del equipo de AWS, la apuesta tiene muy buenas chances de seguir madurando.
🔗 Recursos
Documentación oficial: strandsagents.com
GitHub Python SDK: github.com/strands-agents/sdk-python
Ejemplos y samples: github.com/strands-agents/samples
Bedrock AgentCore (runtime managed): AWS Console → Bedrock → AgentCore




