¿Qué es Strands Agents? El SDK de agentes de AWS de código abierto impulsado por modelos.

Si has construido un agente de IA con una máquina de estados gigante de if/else, sabes lo rápido que se vuelve frágil. Strands Agents propone otro enfoque: deja que el modelo planifique y tú define el prompt, el modelo y las herramientas. Es un SDK de código abierto de AWS, lanzado en mayo de 2025 bajo la Licencia Apache 2.0, y se usa en agentes de producción dentro de equipos de Amazon como Amazon Q Developer y AWS Glue.

Prueba Apidog hoy

Qué es Strands Agents

Strands Agents es un SDK para construir y ejecutar agentes de IA con poco código. A cada agente le das tres piezas:

1. Un modelo.
2. Un prompt del sistema.
3. Una lista de herramientas.

Con eso, el modelo decide qué herramienta llamar, ejecuta la llamada, analiza el resultado y continúa hasta completar la tarea.

El SDK está disponible para Python y TypeScript. El nombre hace referencia a las dos “hebras” principales de un agente: el modelo y las herramientas.

AWS lo publicó como código abierto después de usarlo internamente, por lo que su diseño está orientado a producción y no solo a demos. Desde su lanzamiento en vista previa, superó las 150 mil descargas en PyPI y llegó a una versión 1.0 con primitivas multiagente y soporte para el protocolo Agente-a-Agente, A2A.

Si ya has usado SDKs de agentes, el patrón te resultará familiar. Strands está en la misma categoría que LangGraph y Google ADK, pero delega más control de flujo al modelo en lugar de obligarte a definir todo el grafo manualmente.

Modelo primero: menos orquestación codificada

Muchos frameworks de agentes empiezan con un flujo de trabajo explícito. Defines nodos, aristas, condiciones y rutas. Eso da control, pero cada nueva capacidad implica modificar el grafo y volver a probar rutas.

Strands invierte esa responsabilidad. En vez de codificar cada transición, describes el objetivo y entregas herramientas. El modelo planifica los pasos.

Enfoque	Tú defines	El flujo de control vive en	Costo de añadir una capacidad
Orquestación codificada	Nodos, aristas, condiciones, enrutamiento	Tu código de grafo	Editar el grafo y volver a probar rutas
Impulsado por el modelo con Strands	Prompt y herramientas	El bucle de razonamiento del modelo	Añadir una herramienta y ajustar el prompt

La compensación es clara: Strands permite iterar rápido, pero reduce el determinismo. Si necesitas flujos estrictos y repetibles, puedes añadir estructura con hooks, patrones multiagente o incluso usar un framework basado en grafos para esa parte del sistema.

Crear un agente mínimo

Un agente básico en Strands requiere muy poco código. Defines una herramienta con @tool, creas el agente y lo llamas como una función.

from strands import Agent, tool

@tool
def word_count(text: str) -> int:
    """Count the words in a block of text."""
    return len(text.split())

agent = Agent(
    system_prompt="You are a concise writing assistant.",
    tools=[word_count],
)

response = agent("How many words are in this sentence?")
print(response)

El decorador @tool convierte una función normal de Python en una herramienta que el modelo puede invocar.

Strands usa:

• La docstring como descripción de la herramienta.
• Las anotaciones de tipo como esquema de entrada.
• El valor devuelto como resultado que el modelo puede razonar.

No necesitas mantener un registro separado de herramientas. Al ejecutar agent(...), Strands inicia el bucle del agente hasta que el modelo decide que la tarea terminó.

Diseñar herramientas para Strands

Las herramientas son la interfaz del agente con el mundo exterior. Pueden ser:

• Funciones Python que escribes tú.
• Herramientas empaquetadas por la comunidad.
• Servidores MCP completos expuestos al agente.

Una herramienta útil debe ser pequeña, explícita y fácil de validar. Por ejemplo:

from strands import tool
import requests

@tool
def get_order_status(order_id: str) -> dict:
    """Return the current status for an order by its ID."""
    response = requests.get(
        f"https://api.example.com/orders/{order_id}",
        timeout=10,
    )
    response.raise_for_status()
    return response.json()

Para producción, evita herramientas ambiguas. En lugar de una función genérica como call_internal_api, prefiere herramientas con intención clara:

@tool
def create_refund(order_id: str, reason: str) -> dict:
    """Create a refund request for an existing order."""
    ...

Esto ayuda al modelo a decidir cuándo usar cada herramienta y reduce llamadas incorrectas.

Proveedores de modelos

Strands usa Amazon Bedrock como proveedor predeterminado. Por defecto, un agente usa un modelo Claude Sonnet en la región us-west-2, aunque el ID exacto del modelo predeterminado ha cambiado entre versiones del SDK. Verifica tu versión instalada antes de codificar un ID.

También puedes usar otros proveedores:

• Modelos de Amazon Bedrock que soporten herramientas y streaming.
• Claude de Anthropic vía la API de Anthropic.
• Modelos Llama vía la API de Llama.
• Ollama para desarrollo local.
• Otros proveedores, como OpenAI, a través de LiteLLM.

La idea práctica es que puedes cambiar el objeto del modelo sin reescribir tus herramientas ni el prompt principal. Por ejemplo, puedes prototipar con Ollama localmente y desplegar con Bedrock más adelante.

Soporte multiagente y MCP

Un agente puede resolver muchas tareas, pero los sistemas reales suelen necesitar varios agentes especializados.

Strands 1.0 añadió primitivas multiagente, incluyendo:

• Agente-como-Herramienta: un agente puede llamar a otro agente igual que llama a cualquier herramienta.
• Coordinación tipo Swarm: varios agentes colaboran sobre un problema.
• Soporte A2A: agentes de Strands pueden comunicarse con agentes construidos en otros frameworks.

MCP también es una pieza central. El Protocolo de Contexto de Modelo, MCP, es un estándar abierto para conectar modelos con herramientas y fuentes de datos.

Con Strands puedes conectarte a servidores MCP y pasar sus herramientas al agente. Eso permite reutilizar integraciones existentes sin escribir código de pegamento personalizado.

El flujo general es:

1. Ejecutas o conectas un servidor MCP.
2. Creas un cliente MCP.
3. Obtienes la lista de herramientas disponibles.
4. Pasas esas herramientas al agente Strands.

Si ya tienes servidores MCP, esta es una forma rápida de ampliar capacidades. La desventaja es que ahora dependes del comportamiento de esos servidores, por lo que conviene probar sus endpoints por separado.

Desplegar un agente Strands

Strands está pensado para moverse de local a producción sin cambiar de framework. Puedes ejecutar el mismo agente en distintos destinos:

• Amazon Bedrock AgentCore para un runtime gestionado de agentes.
• AWS Lambda para agentes de corta duración basados en eventos.
• AWS Fargate o Amazon EKS para servicios contenerizados.
• Docker en cualquier entorno que ejecute contenedores.

Como el agente es código Python o TypeScript normal, lo empaquetas igual que cualquier otra aplicación.

Una estructura mínima de proyecto Python podría verse así:

strands-agent/
├── app.py
├── tools.py
├── requirements.txt
└── Dockerfile

Ejemplo de requirements.txt:

strands-agents
requests

Ejemplo básico de Dockerfile:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "app.py"]

Para producción, añade observabilidad. AWS documenta hooks para rastrear qué decidió el modelo y qué herramientas llamó. Esto es clave para depurar fallos que parecen “errores del modelo”, pero que en realidad son respuestas inesperadas de APIs externas.

Dónde encaja Apidog

Strands construye el agente. No construye las APIs que el agente llama.

En la práctica, un agente Strands suele depender de dos tipos de endpoints HTTP:

1. La API del proveedor LLM detrás del modelo.
2. Las APIs REST o herramientas detrás de tus funciones @tool y servidores MCP.

Si esos endpoints fallan, devuelven formatos inesperados o cambian contratos, el agente puede fallar de formas difíciles de diagnosticar.

Apidog encaja como banco de pruebas para esas APIs subyacentes antes de conectarlas al agente.

Usos concretos:

• Simular el modelo o un endpoint de herramienta mientras iteras en el bucle del agente, evitando gastar tokens o alcanzar rate limits en cada prueba. El artículo sobre cómo construir un arnés de prueba para agentes de IA con Apidog muestra este patrón.
• Validar formas de respuesta para detectar payloads mal formados antes de producción. La guía de aserciones de API explica cómo comprobar campos, tipos y códigos de estado.
• Levantar una API simulada que imite respuestas reales, incluidos casos de error que el agente debe manejar correctamente.
• Gestionar claves API por entorno para separar desarrollo, staging y producción sin hardcodear credenciales.

Apidog no reemplaza a Strands ni orquesta agentes. Strands sigue siendo el cerebro. Apidog ayuda a asegurar que la fontanería HTTP que el agente usa sea estable. Puedes descargar Apidog y configurar mocks para tus endpoints de herramientas en pocos minutos.

Flujo recomendado para implementar Strands con APIs externas

Una forma práctica de trabajar es separar la construcción del agente de la validación de endpoints.

1. Define las herramientas

Empieza con funciones pequeñas y tipadas:

@tool
def search_customer(email: str) -> dict:
    """Find a customer by email address."""
    ...

2. Documenta el contrato HTTP

Antes de conectar la herramienta al agente, define qué endpoint llama, qué parámetros necesita y qué respuesta espera.

Ejemplo de respuesta esperada:

{
  "id": "cus_123",
  "email": "[e-mail]",
  "status": "active"
}

3. Crea mocks para desarrollo

Usa un mock para probar el agente sin depender del backend real. Esto te permite validar cómo razona el modelo cuando recibe respuestas exitosas, errores 404, timeouts o datos incompletos.

4. Añade aserciones

Valida que el backend real mantenga el contrato:

• Código de estado esperado.
• Campos obligatorios.
• Tipos correctos.
• Mensajes de error consistentes.

5. Ejecuta pruebas en CI

Antes de desplegar el agente, ejecuta pruebas de API. Así evitas publicar un agente que falla por cambios en un endpoint externo.

Cuándo usar Strands Agents

Usa Strands cuando:

• Quieres construir agentes rápido.
• Confías en el modelo para planificar pasos.
• Ya trabajas en AWS o usas Bedrock.
• Quieres empezar con un agente y crecer hacia multiagente.
• Necesitas consumir herramientas MCP sin escribir integraciones desde cero.

Evítalo como primera opción cuando necesitas flujos completamente deterministas, auditables y predefinidos rama por rama. En esos casos, un framework basado en grafos puede ser más directo.

La decisión no es “Strands vs. grafos” para todo. Son enfoques distintos. Strands es más natural cuando el modelo puede decidir el camino; los grafos son mejores cuando el camino debe estar fijado por código.

Preguntas frecuentes

¿Strands Agents es gratuito y de código abierto?

Sí. Strands Agents es de código abierto bajo la Licencia Apache 2.0, con el código fuente en GitHub. No hay tarifa de licencia para el SDK.

Pagas por el modelo y por los recursos de infraestructura que uses, como inferencia de Bedrock, Lambda o contenedores, pero no por el framework.

¿Tengo que usar Amazon Bedrock con Strands?

No. Bedrock es el proveedor predeterminado, pero Strands también soporta la API de Anthropic, la API de Llama, Ollama para desarrollo local y otros proveedores a través de LiteLLM.

Cambias el objeto del modelo y mantienes el resto del código: herramientas, prompt y bucle del agente.

¿Cuál es la diferencia entre Strands y un framework basado en grafos?

Strands está impulsado por el modelo. Tú das un prompt y herramientas; el modelo decide los pasos.

Un framework basado en grafos te pide definir el flujo de control como nodos y aristas. Eso da más predictibilidad, pero requiere más mantenimiento cuando el flujo cambia.

¿Cómo pruebo las APIs de las que depende mi agente Strands?

Pruébalas independientemente del agente. Simula endpoints, valida respuestas y ejecuta aserciones en CI.

Una herramienta como Apidog puede encargarse de mocks y aserciones. La guía sobre cómo probar la API de ChatGPT con Apidog cubre autenticación, streaming y pruebas de llamadas a herramientas que se aplican directamente a backends de agentes.

Conclusión

Strands Agents ofrece una forma directa de construir agentes: defines un modelo, un prompt y herramientas, y dejas que el modelo ejecute el bucle. Escala de un agente a múltiples agentes, soporta MCP y A2A, y puede desplegarse en la pila de AWS sin reescribir el framework.

La parte crítica está debajo: las APIs que el agente llama. Si esas APIs no son estables, el agente fallará aunque el modelo razone bien. Por eso conviene simular, probar y validar endpoints antes de conectarlos al agente. Strands maneja el razonamiento; Apidog ayuda a que las dependencias HTTP sean confiables.