Marco adaptativo de inteligencia agéntica usando Strands Agents

Las organizaciones que crean agentes de IA enfrentan un desafío común: cada solicitud, ya sea una verificación de estado de rutina o un análisis complejo, generalmente se enruta a un solo modelo grande y costoso. Este enfoque único para todos puede aumentar los costos de API, introducir latencia impredecible y eliminar la posibilidad de operar sin conexión. Incluso las consultas de rutina que podrían resolverse localmente terminan requiriendo un viaje de ida y vuelta completo por la red hacia un modelo de lenguaje extenso (LLM) alojado en la nube.

El Adaptive Agentic Intelligence Framework (AAIF), construido con Strands Agents, adopta un enfoque diferente. En lugar de enrutar todas las solicitudes a un único modelo grande, AAIF utiliza modelos de lenguaje pequeños (SLM) para manejar tareas rutinarias localmente. Las solicitudes más complejas se enrutan a modelos alojados en la nube a través de Amazon Bedrock. Este enfoque se basa en la postura de investigación de Belcak et al. en NVIDIA. Sostienen que los modelos de lenguaje pequeños son «suficientemente potentes, inherentemente más adecuados y necesariamente más económicos para muchas invocaciones en sistemas agénticos». Construido sobre Strands Agents, el marco demuestra cómo la orquestación inteligente de modelos puede ayudar a reducir costos mientras se mantiene una baja latencia para las operaciones locales.

En esta publicación, recorremos los componentes clave de AAIF usando Strands Agents con SLM locales a través de Ollama y modelos en la nube a través de Amazon Bedrock. Usamos un escenario de monitoreo de Internet de las cosas (IoT) como implementación de referencia.

Descripción general de la solución

AAIF organiza el procesamiento de IA en tres capas, cada una optimizada para diferentes tipos de tareas, como muestra la Figura 1:

1. La orquestación inteligente usa un SLM ligero (llama3.2:1b) como capa de toma de decisiones. Este orquestador clasifica las solicitudes entrantes y las enruta a la capa de procesamiento adecuada sin reglas codificadas de forma rígida.
2. El procesamiento local maneja tareas rutinarias como la recuperación de telemetría de dispositivos y el análisis de imágenes usando SLM que se ejecutan en hardware local a través de Ollama. Estas tareas se completan con baja latencia y sin dependencia de la nube.
3. El procesamiento en la nube maneja análisis de patrones complejos y recomendaciones estratégicas mediante modelos de frontera en Amazon Bedrock. Estas solicitudes requieren un contexto más amplio y un razonamiento de varios pasos que los SLM no pueden proporcionar de manera confiable.

Figura 1: Las tres capas de procesamiento de AAIF para la orquestación inteligente, el procesamiento local y el procesamiento en la nube

La Figura 1 muestra la arquitectura completa del sistema AAIF. En el centro se encuentra el agente de Strands, que se conecta a un runtime de Ollama que aloja tanto el modelo orquestador de 1B parámetros como el modelo de visión. El agente expone tres herramientas: get_device_telemetry para la recuperación de datos de sensores locales, analyze_camera_feed para el procesamiento de visión en el dispositivo a través de llama3.2-vision, y get_expert_insights que llama a Amazon Bedrock a través de boto3 para análisis complejos. Las solicitudes entrantes de los usuarios fluyen a través del orquestador SLM, que clasifica cada solicitud y la envía a una herramienta local o al endpoint en la nube según la complejidad de la tarea.

Figura 2: Arquitectura completa del sistema AAIF que muestra el agente de Strands, el runtime de Ollama, las integraciones de herramientas y la conectividad con Amazon Bedrock

El marco se adapta a sus restricciones de implementación en lugar de exigirle que reestructure su infraestructura en torno a él. Esta arquitectura se ejecuta en dispositivos perimetrales como una Raspberry Pi con 8 GB de memoria, en implementaciones totalmente en la nube donde toda la inferencia llega a Amazon Bedrock, o en configuraciones híbridas que combinan la velocidad local con el razonamiento en la nube. La flexibilidad proviene de separar la lógica de enrutamiento (el orquestador SLM) de las herramientas de procesamiento, que se pueden intercambiar o reconfigurar de forma independiente según el hardware disponible y la conectividad de red.

Requisitos previos

Para este recorrido, debe tener los siguientes requisitos previos:

• Una cuenta de AWS.
• Amazon Bedrock acceso a modelos configurado en la Región requerida.
• Python 3.10+ instalado.
• Ollama instalado con los siguientes modelos descargados:
  • ollama pull llama3.2:1b (orquestador).
  • ollama pull llama3.2-vision (análisis de visión).
• Strands Agents instalado: pip install strands-agents strands-agents-tools.
• AWS Command Line Interface (AWS CLI) configurado con las credenciales apropiadas.
• Boto3 instalado: pip install boto3.

Configurar el entorno

Cree un directorio de proyecto e inicie el servidor de Ollama:

mkdir aaif-demo && cd aaif-demo
ollama serve

Descargue los modelos necesarios:

ollama pull llama3.2:1b
ollama pull llama3.2-vision

Cree un archivo llamado aaif_agent.py y añada los siguientes componentes.

Implementar herramientas de procesamiento local

Strands Agents utiliza el @tool decorador para definir las capacidades que los agentes pueden invocar. Comience creando herramientas para el procesamiento local.

La primera herramienta recupera datos de telemetría del dispositivo. En un entorno de producción, esto se conectaría a sensores IoT reales. Para este recorrido, utiliza datos de dispositivo simulados:

from strands import Agent, tool
import random

DEVICE_TELEMETRY = {
    "sensor-001": {
        "device_type": "Temperature Sensor",
        "location": "Building A - Floor 2",
        "temperature": 72.5,
        "humidity": 45.2,
        "status": "normal"
    },
    "camera-001": {
        "device_type": "Security Camera",
        "location": "Main Entrance",
        "fps": 30,
        "resolution": "1080p",
        "status": "recording"
    },
    "hvac-001": {
        "device_type": "HVAC Controller",
        "location": "Building A - Central",
        "set_temp": 71.0,
        "current_temp": 72.5,
        "mode": "cooling",
        "status": "active"
    }
}

@tool
def get_device_telemetry() -> str:
    """Retrieve current telemetry data from connected IoT devices."""
    device_id = random.choice(list(DEVICE_TELEMETRY.keys()))
    device_data = DEVICE_TELEMETRY[device_id]

    report = f"Device: {device_id} ({device_data['device_type']})\n"
    report += f"Location: {device_data['location']}\n"
    report += f"Status: {device_data['status']}\n"
    for key, value in device_data.items():
        if key not in ['device_type', 'location', 'status']:
            report += f"{key}: {value}\n"
    return report

La segunda herramienta realiza análisis de visión utilizando un SLM local. El modelo llama3.2-vision se ejecuta completamente en hardware local, lo que significa que las transmisiones de cámara sensibles no salen del dispositivo:

import ollama

@tool
def analyze_camera_feed(image_path: str) -> str:
    """Analyze visual data from cameras using local vision model."""
    stream = ollama.chat(
        model='llama3.2-vision',
        messages=[{
            'role': 'user',
            'content': 'Describe this image in one sentence. '
            'What are the 3 most important things you see?',
            'images': [image_path]
        }],
        stream=True,
    )

    full_response = ""
    for chunk in stream:
        chunk_content = chunk['message']['content']
        print(chunk_content, end='', flush=True)
        full_response += chunk_content

    return f"Object Detection Report:\n{full_response}"

Implementar el procesamiento en la nube

Para análisis complejos que requieren un razonamiento más amplio, cree una herramienta que llame a Amazon Bedrock. Esta herramienta se invoca solo cuando el orquestador determina que los modelos locales no pueden manejar la solicitud:

import boto3

@tool
def get_expert_insights(context_data: str, question: str) -> str:
    """Get advanced analysis and expert recommendations
    for complex questions via Amazon Bedrock."""
    client = boto3.client("bedrock-runtime", region_name="us-east-1")

    conversation = [
        {
            "role": "user",
            "content": [
                {"text": f"Context: {context_data}\n\nQuestion: {question}"}
            ],
        }
    ]

    response = client.converse(
        modelId="<<model_id>", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
        messages=conversation,
        inferenceConfig={
            "maxTokens": 512,
            "temperature": 0.5,
            "topP": 0.9
        }
    )

    response_text = response["output"]["message"]["content"][0]["text"]
    return f"Expert Analysis:\n{response_text}"

Configurar el agente de Strands con orquestación inteligente

El núcleo de AAIF es la configuración del agente de Strands. El agente utiliza un SLM local (llama3.2:1b) como su orquestador. Strands Agents admite múltiples proveedores de modelos, y aquí usamos el proveedor de Ollama para ejecutar el orquestador localmente:

from strands.models.ollama import OllamaModel

model = OllamaModel(
    model_id="llama3.2:1b",
    host="http://localhost:11434",
    params={
        "max_tokens": 300,
        "temperature": 0.3,
    },
)

system_prompt = """You are a monitoring assistant for operational facilities.
You have access to device telemetry tools, analysis capabilities,
and expert insights to help monitor operations effectively.

When users ask for:
- Device status or telemetry: use get_device_telemetry
- Image or data analysis: use analyze_camera_feed
- Expert advice or complex questions: use get_expert_insights

Always return the complete tool results directly to the user."""

agent = Agent(
    model=model,
    system_prompt=system_prompt,
    tools=[
        get_device_telemetry,
        analyze_camera_feed,
        get_expert_insights,
    ],
)

El orquestador impulsado por SLM analiza cada solicitud y la dirige a la herramienta adecuada sin coincidencias de palabras clave codificadas. El enrutamiento ocurre a través de la comprensión que tiene el modelo de la solicitud:

Tabla 1: Solicitud, enrutamiento y estimaciones de latencia para la inferencia local en comparación con la nube

Ejecutar el agente

Con el agente configurado, puede interactuar con él directamente:

# Local processing - device telemetry
response = agent("What's the current status of our devices?")
print(response)

# Local processing - vision analysis
response = agent("Analyze the camera feed from camera-001")
print(response)

# Cloud processing - complex analysis
response = agent(
    "Based on current telemetry patterns, "
    "what optimization strategies do you recommend?"
)
print(response)

El agente clasifica automáticamente cada solicitud y la dirige a la capa de procesamiento adecuada. No se necesitan reglas de enrutamiento explícitas.

Adaptarse a diferentes escenarios de despliegue

La arquitectura de AAIF se adapta a diferentes requisitos de infraestructura cambiando la configuración del modelo:

Cuando su carga de trabajo se ejecuta completamente en la nube y no hay hardware de borde disponible, reemplace la configuración del modelo de Ollama con Amazon Bedrock para todo el procesamiento. Esto dirige cada solicitud a través de la inferencia administrada en la nube, lo que le proporciona autoescalado sin requerir recursos de GPU locales. Los equipos con conectividad confiable de baja latencia y sin restricciones de residencia de datos se benefician más de esta configuración:

from strands.models import BedrockModel

model = BedrockModel(
    model_id="<<model_id>", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
    region_name="us-east-1"
)

La configuración híbrida mantiene intacto el orquestador SLM local mientras agrega modelos en la nube para solicitudes que exceden las capacidades del modelo local. Esta es la configuración predeterminada de AAIF mostrada en este recorrido. Es adecuada para entornos donde la mayoría de las solicitudes son lo suficientemente rutinarias como para resolverse localmente, pero algunas requieren el razonamiento más amplio de un modelo más grande. El ahorro en costos puede provenir del aproximadamente 80 por ciento del tráfico que no alcanza un punto de conexión de API de pago.

Para entornos que están completamente aislados de la red (air-gapped) o que tienen requisitos estrictos de soberanía de datos, reemplace la herramienta en la nube con un modelo local más grande y ejecute todo el procesamiento en el dispositivo. Un modelo de 3B parámetros que se ejecute en hardware con memoria adecuada puede manejar tareas moderadamente complejas que, de otro modo, el orquestador de 1B escalaría. La contrapartida es una profundidad de razonamiento reducida en las consultas más difíciles, pero el beneficio es que los datos no salen de las instalaciones:

model = OllamaModel(
    model_id="llama3.2:3b", # Larger local model for complex tasks
    host="http://localhost:11434",
)

Mirando hacia adelante: Llamadas a herramientas centralizadas con servidores MCP

La implementación en esta publicación utiliza llamadas a herramientas locales definidas directamente en el código del agente. Para despliegues de producción con múltiples agentes que comparten herramientas entre servicios, exponga estas herramientas como servidores de Model Context Protocol (MCP). MCP proporciona una interfaz estandarizada para el descubrimiento y la invocación de herramientas, de modo que puede centralizar la gestión de herramientas y reutilizarlas entre diferentes agentes y entornos. En la Figura 3, mostramos cómo convertir las herramientas de AAIF en servidores MCP para llamadas a herramientas distribuidas y centralizadas.

En la configuración distribuida como se muestra en la Figura 3, el Device 1 actúa como el centro de orquestación, ejecutando el agente de Strands con el enrutador SLM y una herramienta de telemetría local. Se conecta a través del protocolo MCP al Device 2, que ejecuta un servidor de procesamiento de visión de borde con llama3.2-vision. El Device 3 sirve como una puerta de enlace de análisis en la nube conectado a Amazon Bedrock. Desde la perspectiva del orquestador, todas las herramientas remotas aparecen como llamadas a funciones locales porque la capa de transporte de MCP maneja la serialización y la comunicación de red de manera transparente.

Figura 3: Inteligencia distribuida con servidores MCP

Limpieza

Para evitar cargos futuros, complete los siguientes pasos de limpieza:

1. Deshabilite el acceso a los modelos de Amazon Bedrock: abra la consola de Amazon Bedrock, elija Model accessy revoque el acceso para Amazon Nova Lite. Para ver los pasos detallados, consulte Manage model access en la Amazon Bedrock User Guide.
2. Detenga el servidor de Ollama y elimine los modelos para liberar espacio en disco local (aproximadamente 2 GB):

   ollama stop
   ollama rm llama3.2:1b
   ollama rm llama3.2-vision

3. Elimine el directorio del proyecto si ya no necesita el código de ejemplo:

   rm -rf aaif-demo

Conclusión

Mostramos cómo construir agentes de IA rentables utilizando el Adaptive Agentic Intelligence Framework con Strands Agents. Al enrutar las solicitudes rutinarias a SLM locales y reservar los modelos en la nube de Amazon Bedrock para análisis complejos, AAIF puede ayudar a reducir los costos de API manteniendo una baja latencia en las operaciones rutinarias.

Antes de ejecutar este patrón en producción, añada controles de IA responsable a la ruta de inferencia en la nube, ya que esas solicitudes contienen salidas de herramientas, datos recuperados y entrada del usuario. Puede adjuntar Amazon Bedrock Guardrails al Strands BedrockModel con un ID y una versión de guardrail. Luego aplica filtros de contenido para categorías dañinas, filtros de inyección de prompt y comprobaciones de anclaje contextual que bloquean las respuestas no respaldadas por los datos de origen. Para aplicar las mismas políticas al nivel de SLM local, llame a la API independiente ApplyGuardrail en sus entradas y salidas. De esta manera, cada solicitud sigue un único estándar de seguridad sin importar qué modelo la gestione.

Este patrón arquitectónico se aplica más allá de la monitorización de IoT. Una organización de salud podría ejecutar la monitorización de pacientes localmente mientras enruta el apoyo al diagnóstico a modelos en la nube. Una empresa de servicios financieros podría procesar transacciones en sus instalaciones y reservar capacidad en la nube para el análisis de riesgos. Un equipo de manufactura podría ejecutar modelos de visión de control de calidad en el borde mientras envía solicitudes de optimización a la nube.

Para obtener más información sobre cómo construir agentes con Strands Agents, visite la documentación de Strands Agents. Para obtener información sobre los modelos fundacionales disponibles, consulte Amazon Bedrock.

Acerca de los autores