Strands: crea agentes de IA agnósticos y listos para producción.

Imagina que, como ingeniero/a de software con experiencia en Python, te acaban de asignar tu primer proyecto "agéntico". La emoción es palpable. Comienza con una POC (Proof of Concept) prometedora en un playground web donde el modelo de lenguaje parece entenderlo todo.

Sin embargo, la realidad se impone muy pronto: el camino desde esa POC hasta una aplicación robusta, escalable, segura y lista para producción es un campo minado de decisiones arquitectónicas críticas.

Te enfrentas a un cruce de caminos con preguntas que definirán el futuro del proyecto:

• Proveedor de modelos (LLM). ¿Cuál será el "cerebro" de nuestro agente? ¿Apostamos por OpenAI, Anthropic (Claude), Google (Gemini), o los modelos de código abierto como Mistral? Y, fundamentalmente, ¿cómo nos aseguramos de que estos nuevos proveedores puedan cumplir con los requisitos y la burocracia necesarios para ser homologados en una gran empresa?
• Alojamiento (Hosting). ¿Dónde residirá esta inteligencia? ¿En la nube, aprovechando la escalabilidad de nuestro proveedor principal como AWS? ¿O queremos guardar la opción de tener un LLM en nuestro propio data center para datos sensibles que nunca han visto la nube?
• Acceso al conocimiento. ¿Cómo aprenderá el agente sobre nuestro negocio? ¿Implementamos un sistema de Retrieval-Augmented Generation (RAG) que consulte la documentación interna general, o necesitamos un acceso segregado a los datos en función del usuario que interactúa con el agente?
• Framework agéntico. Y la decisión más crucial de todas: ¿cuál será el sistema nervioso central que conecte el modelo, las herramientas y nuestros datos? Las opciones más conocidas son LangChain o alternativas como crewAI pero, ¿cuál se adapta mejor a nuestra visión a largo plazo?

Cada elección implica un compromiso. La necesidad de reducir el vendor lock-in por componentes es una prioridad estratégica; no queremos que la elección de un componente hoy limite nuestra capacidad de innovar mañana.

Al mismo tiempo, debemos capacitar fácilmente a nuestro equipo actual de ingeniería de datos y desarrollo en Python para que se conviertan en "especialistas en ingeniería agéntica" sin una curva de aprendizaje prohibitiva. El framework que elijamos es la pieza central de este rompecabezas, ya que dictará la arquitectura, la velocidad de desarrollo y la flexibilidad futura.

En este complejo panorama, Strands emerge como una opción especialmente atractiva. Aunque es una iniciativa impulsada por AWS, la base del proyecto es de código abierto y está diseñada para abordar directamente estas preocupaciones empresariales, sobre todo para un nuevo proyecto que:

• Tiene a AWS como principal proveedor: Strands ofrece integraciones nativas y un camino claro hacia la producción dentro del ecosistema de AWS.
• Cuenta con ingenieros/as de datos capaces en Python y AWS: al ser una librería de Python pura, la barrera de entrada es baja, permitiendo que el equipo existente sea productivo rápidamente.
• Quiere la flexibilidad de proveedores de LLM: es agnóstico al modelo y al proveedor, lo que permite experimentar y adoptar lo último en tecnología de modelos de lenguaje sin estar atado a un único ecosistema.
• Necesita cumplir con estándares empresariales: Strands está diseñado para la producción, facilitando la creación de infraestructuras que cumplen con los requisitos de grandes empresas y regulaciones como CI/CD, GDPR y gobernanza de datos.

A continuación, explicaremos cómo Strands logra este equilibrio y por qué podría ser la elección estratégica para tu primera aplicación agéntica de nivel de producción.

¿Qué es Strands? La anatomía de un agente "Model-Driven"

La filosofía de Strands se materializa en una arquitectura de una simplicidad radical. En lugar de una compleja red de abstracciones, la construcción de un agente se reduce a la definición de tres componentes fundamentales en código Python, una estructura que recuerda a las dos hebras de ADN que dan nombre al proyecto: el modelo y las herramientas unidos por el prompt.

Los tres pilares de un agente Strands

1. Modelo (Model)

Es el motor de razonamiento del agente, el cerebro que interpreta las intenciones, planifica los pasos y decide qué acciones tomar. Por defecto, Strands utiliza un modelo de la familia Claude 3.x Sonnet a través de Amazon Bedrock, lo cual ofrece un excelente punto de partida con un equilibrio entre capacidad y coste. Sin embargo, como se detalla más adelante, esta es solo una configuración inicial y no una dependencia.

2. Herramientas (Tools)

Son las capacidades de acción del agente, sus "manos" para interactuar con el mundo exterior. Una herramienta en Strands puede ser cualquier cosa, desde una simple función de Python decorada con @tool hasta un servicio externo complejo accesible a través de un MCP o AWS AgentCore, el puntero hacia todos los servicios de AWS. El agente no ejecuta estas herramientas a ciegas: el modelo las selecciona y las utiliza en función de su comprensión de la tarea a realizar.

3. Prompt

Es el "alma" del agente, el conjunto de instrucciones en lenguaje natural que define su propósito y comportamiento. Es crucial diferenciar entre el prompt del usuario, que especifica la tarea puntual a realizar (ej. "resume este documento"), y el system_prompt, que establece la identidad del agente, sus reglas, su personalidad y el contexto general en el que opera (ej. "eres un analista financiero experto. Sé conciso y basa tus respuestas únicamente en los datos proporcionados por tus herramientas").

En la práctica, combinar estos tres pilares es tan sencillo como instanciar la clase Agent y pasarle una tarea:

from strands import Agent
from strands_tools import http_request

simple_agent = Agent(
    name="Research Assistant",
    model="eu.amazon.nova-pro-v1:0",
    tools=[http_request],
    system_prompt="You are a research assistant with analytical capabilities. Use tools when needed to provide accurate, data-driven responses."
)
simple_agent("Compare the price of top 5 reasoning Bedrock models for text, from providers Anthropic and MistralAI")

Verificación de la licencia y uso comercial

Un factor determinante para la adopción de cualquier tecnología en el entorno empresarial es su modelo de licenciamiento. El SDK de Strands se publica bajo la licencia Apache 2.0, una de las licencias de código abierto más permisivas y respetadas en la industria. En términos prácticos, esto significa que cualquier individuo u organización puede:

• Utilizar el software libremente para cualquier propósito, incluidos proyectos comerciales y lucrativos, sin coste de licencia.
• Modificar el código fuente para adaptarlo a necesidades específicas.
• Distribuir copias del software original o de sus versiones modificadas.

Esta elección de licencia elimina una barrera de entrada crucial y fomenta un ecosistema abierto, asegurando que las empresas puedan construir soluciones críticas sobre Strands con total confianza legal y sin temor a costes ocultos o a un futuro "vendor lock-in".

Arquitectura agnóstica: libertad de elección en un ecosistema abierto

Una de las características más potentes y estratégicas de Strands es su diseño agnóstico. A pesar de haber sido iniciado por AWS, el SDK no genera ninguna dependencia obligatoria con su ecosistema. Es, en esencia, una librería de Python pura que puede ejecutarse en cualquier lugar donde Python pueda correr: en un portátil, en un servidor on-premise o en cualquier proveedor de la nube.

Agnosticismo de modelo y proveedor

La flexibilidad de Strands se manifiesta de forma más evidente en su capacidad para interactuar con una amplia gama de modelos de lenguaje de diferentes proveedores. Cambiar el "cerebro" de un agente es tan simple como instanciar un Model Provider diferente, a menudo con una sola línea de código.

A continuación, se muestran ejemplos de cómo instanciar un agente Strands con varios de los proveedores más populares:

• Amazon Bedrock (configuración por defecto):

from strands.models import BedrockModel
# Utiliza el modelo Claude 3.7 Sonnet en Bedrock
bedrock_model = BedrockModel(model_id="us.anthropic.claude-3-7-sonnet-20250219-v1:0")

• Google Gemini:

from strands.models.gemini import GeminiModel
gemini_model = GeminiModel(api_key="TU_API_KEY_GEMINI", model_id="gemini-1.5-pro-latest")

Es importante destacar que, aunque Strand promueve la posibilidad de usar directamente proveedores alternativos a AWS como Google, Ollama o MistralAI, las implementaciones de estos accesos no están actualizadas al mismo nivel que las de AWS Bedrock, que esponsoriza el proyecto.

Por ejemplo, la clase con el modelo de Gemini se limita al Gemini API Endpoint v1beta con una lista de modelos limitada y no permite el uso de credenciales Vertex (modelos Gemini por Google Cloud Computing). Siendo un proyecto Open Source, se puede solucionar con un fork y extendiendo una clase Model.

El ecosistema de herramientas: capacidades nativas, custom y de la nube

La misma filosofía de apertura se aplica al ecosistema de herramientas, que se pueden clasificar en cuatro categorías principales:

• Herramientas nativas: Strands se complementa con el proyecto hermano strands-agents-tools, que proporciona un conjunto de herramientas listas para usar. Estas incluyen funcionalidades esenciales como obtener la hora en tiempo real (current_time), acceso a ficheros (file_read, file_write), ejecución de comandos de shell (shell), peticiones HTTP (http_request) y un explorador web (browser). Esto permite que un agente, desde el primer momento, pueda interactuar con el mundo exterior.
• Herramientas custom: la forma más directa de ampliar las capacidades de un agente es convertir cualquier función de Python en una herramienta personalizada. Esto se consigue simplemente añadiendo el decorador @tool. Strands inspecciona la función, utilizando su nombre, sus anotaciones de tipo y su docstring para generar un esquema que el LLM puede entender. Un docstring bien escrito no es solo documentación para otros equipos de desarrollo; es la API que el modelo utilizará para decidir cuándo y cómo llamar a la herramienta.

from strands import tool

@tool
def get_user_details(user_id: int) -> dict:
    """
    Recupera los detalles de un usuario desde la base de datos.
    Utiliza esta herramienta cuando necesites obtener información sobre un usuario específico por su ID.
    """
    # Lógica para conectar a la BBDD y obtener los datos...
    return {"id": user_id, "name": "Jane Doe", "email": "jane.doe@example.com"}

• Herramientas de servidor con Model Context Protocol (MCP): para escalar y estandarizar el acceso a herramientas, Strands integra de forma nativa el Model Context Protocol (MCP). MCP es un estándar abierto que permite que los servicios expongan sus capacidades de una manera que los agentes de IA puedan descubrir y consumir de forma estandarizada. En lugar de que cada agente tenga que implementar un cliente de API personalizado para cada servicio, puede usar el MCPClient de Strands para conectarse a un servidor MCP y obtener acceso a todo su catálogo de herramientas.
• Herramientas de Bedrock AgentCore: para los equipos que operan dentro del ecosistema de AWS, AgentCore proporciona un acceso simplificado pero controlado a los grandes servicios de la nube. Por ejemplo, AgentCore Memory permite una transición sencilla pero robusta de las memorias a corto plazo (historial de la conversación) a las memorias a largo plazo, gestionando la persistencia y recuperación de información entre sesiones de forma transparente para el agente.

La estrategia de AWS con Strands y sus servicios gestionados es un ejemplo magistral de cómo una empresa puede fomentar un ecosistema abierto mientras crea un camino claro hacia sus propias soluciones de valor añadido.

Al lanzar Strands como un SDK de código abierto y agnóstico, AWS atrae a la comunidad de desarrollo que valora la flexibilidad y desconfía del "vendor lock-in". Una persona de desarrollo puede empezar a construir un agente en su máquina local, utilizando modelos de OpenAI, Google, Ollama… sin tocar la infraestructura de AWS.

Amazon Bedrock AgentCore

Sin embargo, una vez que ese agente está listo para pasar a producción, surgen preguntas críticas sobre escalabilidad, seguridad, observabilidad y gestión. Es en este punto donde AWS presenta su solución complementaria: servicios gestionados como Amazon Bedrock Agents y, más concretamente, Amazon Bedrock AgentCore.

AgentCore es un entorno de ejecución serverless diseñado específicamente para las cargas de trabajo agénticas, ofreciendo arranques rápidos, aislamiento de sesiones y tiempos de ejecución prolongados hasta 8 horas, características que las funciones serverless no siempre proporcionan.

Creando equipos de agentes especializados: patrones de colaboración

A medida que las tareas se vuelven más complejas, la idea de un único agente monolítico que lo sabe todo y lo hace todo se vuelve ineficiente y difícil de mantener. El prompt de un agente sobrecargado tiene más probabilidades de tener instrucciones contradictorias que provocan comportamientos imprevistos.

Un enfoque más potente es crear un sistema de múltiples agentes pequeños y especializados. Cada agente se diseña con un propósito claro, definido por un System Prompt específico, un conjunto de herramientas limitado a su dominio y un contexto enfocado en su área de especialización. Es una solución más fácil de definir y de mantener con el tiempo.

Ejemplo práctico: un equipo de proyecto virtual

Imaginemos que queremos construir un sistema de IA para ayudar en la gestión y operación de un proyecto de software. En lugar de un solo agente, crearemos un equipo de especialistas:

• Agente "Project Manager": este agente actúa como el coordinador principal, asegurando que el trabajo técnico esté alineado con los objetivos estratégicos del negocio.
• Agente "Operations Engineer": este agente es el especialista en la infraestructura y la estabilidad del sistema.

Orquestación y colaboración: ¿cómo se comunican los agentes?

Con los agentes especializados definidos, la siguiente pregunta es cómo orquestar su colaboración. Strands propone un conjunto de primitivas para la multi-agencia.

• Agents-as-Tools (delegación jerárquica). Este es el patrón más simple y directo. Un agente (el "manager") puede invocar a otro agente (el "especialista") como si fuera una herramienta más. En nuestro ejemplo, el project_manager_agent puede delegar una tarea de diagnóstico al operations_agent simplemente llamándolo. Strands gestiona el paso del contexto y la devolución de la respuesta.
• Swarms (colaboración Autónoma). Para problemas complejos y no estructurados que se benefician de un "brainstorming" o exploración paralela, el patrón Swarm es ideal. En un Swarm, un grupo de agentes trabaja sobre un problema en un espacio de memoria compartido. El flujo de trabajo no está predefinido, sino que emerge de las decisiones colaborativas de los agentes.
• Workflows (secuencias definidas). Para procesos que deben seguir una secuencia predecible y estructurada, se pueden definir flujos de trabajo. Por ejemplo, un proceso de despliegue de software podría requerir que un agente de "QA" ejecute pruebas y dé su aprobación antes de que el agente de "Operaciones" pueda proceder con el despliegue en producción. Este patrón garantiza que se sigan los pasos en el orden predefinido.

Strands en el ecosistema: análisis comparativo para perfiles de arquitectura

La elección de un framework es una decisión crítica. Para ayudar a los perfiles de arquitectura a posicionar Strands, vamos a compararlo con otras alternativas populares, centrándonos en el paradigma, el control y el caso de uso ideal.

Strands vs. LangChain / LangGraph

La diferencia fundamental es filosófica. LangChain y LangGraph operan bajo un paradigma "developer-driven", donde el equipo de desarrollo define explícitamente el flujo de control como una cadena o un grafo.

Strands, en cambio, es "model-driven": el equipo de desarrollo proporciona las capacidades (herramientas) y el objetivo (prompt), y el LLM decide dinámicamente el flujo de ejecución. LangGraph ofrece un control granular ideal para procesos de negocio complejos y auditables a costa de una mayor complejidad. Strands brilla en escenarios que demandan autonomía y resiliencia, donde el agente debe adaptarse a situaciones no previstas.

Strands vs. n8n

Aquí se enfrentan un SDK "code-first" (Strands) y una plataforma de automatización visual (n8n).

Mientras que n8n acelera la conexión de servicios a través de una vasta librería de conectores pre-construidos y una interfaz gráfica, presenta dos diferencias clave para equipos de desarrollo.

Primero, su licencia "fair-code" es de código abierto pero limitada, requiriendo rápidamente un plan de pago para uso profesional. Segundo, los flujos de trabajo de n8n solo se ejecutan en servidores n8n (cloud o auto-alojados), mientras que Strands es una librería Python estándar que se ejecuta en cualquier entorno Python. Strands se integra de forma nativa con el ecosistema de control de calidad de Python (versionado, CI/CD, testing), lo que lo convierte en una opción natural para la ingeniería de software.

Strands vs. agentes de AWS Bedrock

Esta es la comparación entre un SDK de código abierto y un servicio totalmente gestionado (PaaS).

Strands es una librería que el equipo de desarrollo ejecuta en su propia infraestructura, ofreciendo control total sobre el entorno, las dependencias y la lógica. Los agentes de Bedrock son un servicio "serverless" que ofrece máxima comodidad, gestionando AWS toda la infraestructura subyacente a cambio de una menor flexibilidad.

La gran ventaja de Strands es su flexibilidad para integrar rápidamente nuevos estándares emergentes como MCP y A2A, permitiendo construir una arquitectura preparada para el futuro sin renunciar a la robustez demostrada de los servicios de AWS cuando se decide desplegar sobre ellos.

Strands como el futuro estándar del desarrollo agéntico

Strands representa una evolución significativa en el campo de la inteligencia artificial agéntica, marcando un punto de inflexión desde los flujos de trabajo rígidos y pre-programados hacia una verdadera autonomía impulsada por el modelo.

Gracias a su modelo, herramientas y prompt, se reduce mucho la complejidad para construir agentes potentes y resilientes. Al delegar la carga de la orquestación al motor de razonamiento del LLM, Strands acelera el ciclo de desarrollo.

La arquitectura abierta y agnóstica del SDK es, quizás, su atributo más estratégico. Al liberarse de las ataduras de un único proveedor de modelos o de una plataforma cloud específica, Strands se posiciona como un lenguaje universal para el desarrollo de agentes.

Esta flexibilidad, combinada con un diseño pensado desde el inicio para la producción con características como la observabilidad nativa a través de OpenTelemetry y patrones de despliegue claros, lo convierte en una opción atractiva tanto para startups ágiles como para grandes empresas que buscan construir sistemas de IA robustos y mantenibles.

En las próximas semanas publicaremos una guía práctica con los primeros pasos. ¡Te leo en comentarios! 👇