Si has construido un agente de IA conectando una máquina de estados gigante de if/else, sabes lo rápido que eso se vuelve frágil. Strands Agents apuesta por lo contrario: deja que el modelo haga la planificación, y tú proporcionas un prompt y una lista de herramientas. Es un SDK de código abierto de AWS, lanzado en mayo de 2025 bajo la Licencia Apache 2.0, y potencia agentes de producción dentro de equipos de Amazon como Amazon Q Developer y AWS Glue.
Qué es Strands Agents en realidad
Strands Agents es un SDK para construir y ejecutar agentes de IA en pocas líneas de código. A un agente se le dan tres cosas: un modelo, un prompt del sistema y un conjunto de herramientas. El modelo lee el prompt, decide qué herramientas llamar, las ejecuta, examina los resultados y continúa hasta que la tarea se completa. Ese ciclo es todo el producto.
Se distribuye para Python y TypeScript. El nombre es un guiño a las dos hebras que componen un agente: el modelo y las herramientas. AWS lo publicó como código abierto después de ejecutarlo internamente, por lo que el diseño refleja las necesidades de producción, no una demo. Desde su lanzamiento en vista previa, superó las 150 mil descargas en PyPI y alcanzó una versión 1.0 que añadió primitivas multiagente y soporte para el protocolo Agente-a-Agente (A2A).
Si has leído sobre otros SDK de agentes, la forma te resultará familiar. Strands se encuentra en la misma categoría que LangGraph y Google ADK, pero se apoya más en el modelo para impulsar el flujo de control en lugar de pedirte que dibujes el gráfico tú mismo.
La filosofía impulsada por el modelo vs. la orquestación codificada
La mayoría de los primeros frameworks de agentes te pedían que definieras el flujo de trabajo de antemano. Construías nodos, aristas y condiciones, y luego dirigías el modelo a través de ellos. Eso funciona, pero cada nueva capacidad significa más gráfico que mantener.
Strands invierte la responsabilidad. Los modelos modernos ya planifican, encadenan razonamientos, llaman a herramientas y reflexionan sobre los resultados. Así que, en lugar de codificar esa lógica a mano, describes el objetivo y entregas las herramientas. El modelo averigua los pasos.
Aquí está el contraste en términos sencillos:
| Enfoque | Tú defines | El flujo de control reside en | Costo de una nueva capacidad |
|---|---|---|---|
| Orquestación codificada | Nodos, aristas, condiciones, enrutamiento | Tu código de gráfico | Editar el gráfico, volver a probar rutas |
| Impulsado por el modelo (Strands) | Prompt + lista de herramientas | El bucle de razonamiento del modelo | Añadir una herramienta, actualizar el prompt |
La compensación es real. Los agentes impulsados por modelos son más rápidos de construir y adaptar, pero se renuncia a cierto determinismo. Para flujos de trabajo que deben ejecutarse de la misma manera cada vez, aún puedes añadir estructura con patrones de multiagente y ganchos (hooks). El punto no es que los gráficos estén mal; es que los usas cuando los necesitas en lugar de por defecto.
Un agente mínimo
El programa Strands útil más pequeño es corto. Importas la clase Agent, opcionalmente defines una herramienta con el decorador @tool y llamas al agente 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 de Python simple en algo que el modelo puede llamar. Tu docstring y las sugerencias de tipo se convierten en la descripción de la herramienta y el esquema de entrada, para que el modelo sepa cuándo y cómo usarla. No hay un registro separado que mantener. Llamar a agent(...) ejecuta el bucle hasta que el modelo decide que ha terminado.
Herramientas y proveedores de modelos
Las herramientas son la forma en que el agente interactúa con el mundo exterior. Una herramienta puede ser una función de Python que escribiste, una herramienta empaquetada de la comunidad o un servidor completo de Protocolo de Contexto de Modelo (MCP) expuesto al agente.
En cuanto al modelo, Strands es flexible en cuanto al proveedor. El proveedor predeterminado es Amazon Bedrock, y de forma predeterminada un agente usa un modelo Claude Sonnet en la región us-west-2 (el ID exacto del modelo predeterminado ha cambiado entre versiones del SDK, así que verifica tu versión instalada en lugar de codificarla). Puedes configurarlo en otro lugar:
- Cualquier modelo de Amazon Bedrock que soporte el uso de herramientas y streaming
- La familia Claude de Anthropic a través de la API de Anthropic
- Modelos Llama a través de la API de Llama
- Ollama para desarrollo local
- Otros proveedores como OpenAI a través de LiteLLM
Intercambiar proveedores es un cambio en el objeto del modelo, no una reescritura. El bucle del agente, tus herramientas y tu prompt permanecen igual. Esto hace que sea práctico desarrollar contra un modelo Ollama local y desplegar en Bedrock.
Soporte multiagente y MCP
Un solo agente maneja mucho, pero los sistemas reales a menudo necesitan varios. Strands 1.0 añadió primitivas para aplicaciones multiagente, incluyendo un patrón de Agente-como-Herramienta donde un agente llama a otro agente de la misma manera que llama a cualquier herramienta, y coordinación estilo Swarm para grupos de agentes trabajando juntos en un problema. También soporta el protocolo A2A, para que los agentes de Strands puedan comunicarse con agentes construidos en otros frameworks.
MCP es un ciudadano de primera clase. El Protocolo de Contexto de Modelo (MCP) es un estándar abierto para conectar modelos a herramientas y fuentes de datos. Con Strands puedes conectarte a servidores MCP publicados y usar sus herramientas directamente, lo que significa que miles de integraciones existentes están disponibles sin código de pegamento personalizado. Gestionas la conexión a través de un cliente MCP y pasas sus herramientas al agente como cualquier otra lista de herramientas.
Si ya estás ejecutando servidores MCP, esta es la forma más económica de dar nuevas capacidades a un agente. La desventaja es que ahora dependes del comportamiento de esos servidores, lo cual es una razón por la que la prueba de los endpoints subyacentes es importante.
Desplegando un agente Strands
Strands está construido para pasar de tu laptop a producción sin cambiar de framework. Haces pruebas localmente y luego despliegas al destino que se adapte a tu stack:
- Amazon Bedrock AgentCore para un entorno de ejecución de agentes gestionado
- AWS Lambda para agentes de corta duración impulsados por eventos
- AWS Fargate o Amazon EKS para servicios contenerizados de larga ejecución
- Docker simple en cualquier lugar donde puedas ejecutar un contenedor
Dado que el agente es Python o TypeScript ordinario, su empaquetado sigue las mismas reglas que cualquier aplicación. AWS también documenta los ganchos de observabilidad, para que puedas rastrear lo que el modelo decidió y qué herramientas llamó una vez que el agente esté activo.
Dónde encaja Apidog
Strands construye el agente. No construye las APIs que tu agente llama, y esa es la brecha que vale la pena planificar. Cada agente de Strands se apoya en dos tipos de endpoints HTTP: la API del proveedor LLM detrás del modelo, y las APIs REST o de herramientas detrás de tus funciones @tool y servidores MCP. Si esos endpoints se comportan mal, el agente falla de maneras que parecen problemas del modelo pero no lo son.
Apidog es donde pruebas y simulas esas APIs subyacentes antes de que el agente las toque. Algunos usos concretos:
- Simula el modelo o un endpoint de herramienta mientras iteras en el bucle, para no quemar tokens ni alcanzar límites de velocidad en cada ejecución. El artículo sobre la construcción de un arnés de prueba para agentes de IA con Apidog muestra el patrón.
- Verifica las formas de respuesta de las herramientas para que una herramienta que devuelve una carga útil mal formada sea detectada en una prueba, no en producción. Consulta la guía de aserciones de API para saber cómo validar campos, tipos y códigos de estado.
- Levanta una API simulada que imite las respuestas de un servicio real, incluyendo los casos de error que tu agente necesita manejar con elegancia.
- Gestiona las claves API por entorno para que tus agentes de desarrollo, staging y producción se autentiquen contra los backends correctos sin filtrar credenciales en el código.
Para ser claros, Apidog no es un framework de agentes y no orquesta nada. Strands sigue siendo el cerebro. Apidog es el banco de trabajo para la fontanería debajo de él. Puedes descargar Apidog y configurar simulaciones para tus endpoints de herramientas en unos minutos.
Cuándo usar Strands Agents
Recurre a Strands cuando quieras avanzar rápido y confíes en el modelo para planificar. Se ajusta bien si estás en AWS y ya usas Bedrock, si quieres empezar con un agente y luego crecer a multiagente, o si quieres herramientas MCP sin escribir código de integración.
Es menos adecuado cuando necesitas flujos estrictos, auditables y deterministas donde cada rama debe ser predefinida. Aún puedes lograrlo con ganchos y una estructura multiagente, pero un framework basado en gráficos podría ser una opción más directa. La verdad es que los enfoques impulsados por modelos y por gráficos resuelven problemas diferentes, y Strands es el impulsado por modelos.
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 cualquier recurso en la nube al que despliegues, como la inferencia de Bedrock o la ejecución de Lambda, pero el framework en sí no cuesta nada.
¿Tengo que usar Amazon Bedrock con Strands?
No. Bedrock es el proveedor predeterminado, pero Strands soporta la API de Anthropic, la API de Llama, Ollama para ejecuciones locales y otros proveedores a través de LiteLLM. Cambias el objeto del modelo y mantienes el resto de tu código. Esto facilita la creación de prototipos localmente y el cambio a un proveedor gestionado para producción.
¿Cuál es la diferencia entre Strands y un framework basado en gráficos?
Strands está impulsado por modelos: proporcionas un prompt y herramientas, y el modelo decide los pasos. Los frameworks basados en gráficos te piden que definas el flujo de control como nodos y aristas. Strands es más rápido de construir y adaptar; los frameworks de gráficos te dan una ejecución más ajustada y predecible. Muchos equipos usan ambos para diferentes servicios.
¿Cómo pruebo las APIs de las que depende mi agente Strands?
Pruébalas de forma independiente al agente, antes y durante el desarrollo. Simula los endpoints del LLM y de las herramientas, verifica sus formas de respuesta y ejecuta esas comprobaciones en CI. Una herramienta como Apidog se encarga de las simulaciones y aserciones, y la guía sobre cómo probar la API de ChatGPT con Apidog cubre la autenticación, el streaming y las pruebas de llamadas a herramientas que se mapean directamente a los backends del agente.
Conclusión
Strands Agents es una perspectiva clara sobre la construcción de agentes: defines un modelo, un prompt y herramientas, y luego dejas que el modelo ejecute el bucle. Escala de un agente a muchos, habla MCP y A2A, y se despliega en toda la pila de AWS sin una reescritura. El framework maneja el razonamiento. Tu trabajo es asegurarte de que las APIs subyacentes son sólidas, y ahí es exactamente donde Apidog se gana su lugar, simulando y probando los endpoints que tu agente llama para que los fallos aparezcan en tus pruebas en lugar de en producción.