Cómo crear un asistente de IA que use herramientas

Un agente fiable es un sistema con estado, herramientas y límites externos al modelo

El modelo propone el siguiente paso, pero no debe poseer la autoridad final. La aplicación conserva identidad, permisos, presupuesto, estado, herramientas disponibles, validación y registro. Esta separación permite cambiar de modelo sin rehacer las reglas de negocio.

Solicitud → política → contexto autorizado → modelo → propuesta de herramienta
          → validación de argumentos → aprobación cuando corresponde
          → ejecución aislada → comprobación del resultado → respuesta

Un chat con una única llamada a función puede ser más seguro y útil que un agente autónomo general. Añade capacidad solo cuando una evaluación demuestre que el siguiente nivel aporta valor.

Crear funciones pequeñas, tipadas y comprensibles para el revisor

Una herramienta debe representar una acción de negocio concreta. Evita funciones como «ejecutar SQL», «hacer petición HTTP» o «modificar ERP»: conceden demasiada libertad y son difíciles de auditar. Prefiere contratos como «consultar estado de pedido», «crear borrador de respuesta» o «proponer cambio de fecha».

consultar_pedido({
  "numero": "string",
  "campos": ["estado", "transportista"]
})

crear_borrador_respuesta({
  "mensaje_id": "string",
  "asunto": "string",
  "cuerpo": "string"
})

• Esquema cerrado y tipos validados por el servidor
• Longitud, formato, rangos y enumeraciones limitados
• Identidad y permisos obtenidos fuera del prompt
• Tiempo máximo y número de reintentos definidos
• Resultado estructurado con código de error
• Operación idempotente o protegida por una clave única
• Registro suficiente para reconstruir la decisión

No ejecutes directamente el JSON del modelo. Analízalo con un validador, descarta campos desconocidos y vuelve a comprobar permisos justo antes de la acción.

Tratar correo, páginas y documentos como contenido potencialmente adversario

La inyección de prompt aparece cuando una fuente intenta convencer al modelo de que cambie sus instrucciones, revele datos o utilice una herramienta. El texto puede estar visible, oculto en un documento o incluido en resultados recuperados. No existe una frase de sistema que elimine por completo este riesgo; la defensa combina arquitectura y pruebas.

1. Separa instrucciones y datos. Etiqueta el contenido externo y prohíbe que defina políticas o herramientas.
2. Reduce el contexto. Entrega únicamente los fragmentos necesarios y autorizados para la tarea.
3. Limita herramientas por paso. Una tarea de lectura no necesita funciones de escritura disponibles.
4. Valida argumentos fuera del modelo. Bloquea rutas, dominios, destinatarios o identificadores no permitidos.
5. Solicita aprobación para efectos relevantes. El revisor debe ver la fuente, la propuesta y el efecto exacto.
6. Comprueba el resultado. Verifica que la operación se realizó una vez y sobre el recurso previsto.
7. Prueba entradas hostiles. Incluye documentos que piden ignorar reglas, revelar secretos o llamar a otras herramientas.

Los secretos no deben entrar en el contexto. La herramienta utiliza credenciales en el servidor y devuelve el mínimo resultado. Los mensajes de error tampoco deben revelar tokens, rutas internas o consultas.

Conservar lo necesario sin transformar cada conversación en un expediente permanente

El historial completo es una forma costosa y poco controlada de estado. Resume hechos aprobados en campos explícitos y conserva la procedencia. Una preferencia, una instrucción de empresa y un dato transitorio no tienen la misma autoridad ni la misma retención.

Cuando un modelo resume memoria, la aplicación debe validar campos y asociarlos a una fuente. No permitas que una suposición se convierta silenciosamente en un hecho persistente.

Evaluar trayectorias, efectos y recuperación ante errores

Una respuesta final correcta puede ocultar llamadas innecesarias o peligrosas. Registra la trayectoria: decisiones, herramientas propuestas, argumentos, validaciones, aprobaciones, errores y resultado. La puntuación debe penalizar efectos laterales incluso cuando el texto final sea aceptable.

1. Fija un conjunto de escenarios. Incluye normales, límites, errores y ataques.
2. Ejecuta varias veces. Los modelos son probabilísticos; mide tasa de éxito, no una demostración favorable.
3. Valida con reglas deterministas. Esquemas, permisos y efectos se comprueban con código.
4. Revisa una muestra humana. Especialmente en decisiones que afectan a clientes, empleados o contratos.
5. Bloquea regresiones. Un cambio de modelo o prompt no se publica si empeora seguridad o exactitud.

Pasar de asistente a agente sin saltar directamente a la autonomía

Define una condición de parada técnica y operativa. El agente debe finalizar al alcanzar el objetivo, agotar pasos, superar tiempo, recibir un error no recuperable o requerir información humana. La ausencia de salida no justifica seguir llamando herramientas.

Ejemplo seguro: preparar un borrador de correo

1. El disparador obtiene un mensaje autorizado.
2. Se eliminan firmas, rastreadores y adjuntos no necesarios.
3. Un RAG recupera política y datos permitidos.
4. El modelo devuelve asunto, cuerpo, nivel de confianza y fuentes en JSON.
5. El validador comprueba esquema y destinatarios.
6. Microsoft Graph crea un borrador; no se llama al método de envío.
7. La persona revisa y decide desde Outlook.

La guía n8n + Ollama + Outlook desarrolla esta integración con separación entre modelo, coordinación de pasos y correo.

Dimensionar para contexto, herramientas y sesiones simultáneas

Los agentes consumen más contexto que un chat simple: instrucciones, esquema de herramientas, resultados, memoria y varios ciclos. Mide tokens de entrada por paso, número medio y máximo de pasos, latencia de cada herramienta y sesiones concurrentes. Un modelo rápido no compensa una herramienta lenta ni un flujo con demasiadas iteraciones.

Construir un agente local mínimo con una herramienta de solo lectura

El primer agente no debería enviar correos, modificar el ERP ni ejecutar órdenes. Empieza con una función que solo consulta un dato acotado, valida sus argumentos y devuelve una estructura pequeña. El modelo decide si necesita la herramienta; la aplicación conserva la autoridad para permitirla, ejecutarla y registrar el resultado.

import json
import re
from ollama import chat

MODEL = "familia:variante-validada"
MAX_STEPS = 4

# Sustituye este diccionario por una consulta de solo lectura con permisos mínimos.
INCIDENCIAS = {
    "INC-100": {"estado": "en_revision", "responsable": "soporte"},
    "INC-101": {"estado": "resuelta", "responsable": "sistemas"},
}

def consultar_incidencia(codigo: str) -> dict:
    if not re.fullmatch(r"INC-[0-9]{3,8}", codigo):
        raise ValueError("Formato de incidencia no permitido")
    return INCIDENCIAS.get(codigo, {"estado": "no_encontrada"})

TOOL_SCHEMA = {
    "type": "function",
    "function": {
        "name": "consultar_incidencia",
        "description": "Consulta el estado de una incidencia por su código",
        "parameters": {
            "type": "object",
            "properties": {"codigo": {"type": "string"}},
            "required": ["codigo"],
            "additionalProperties": False,
        },
    },
}

ALLOWED_TOOLS = {"consultar_incidencia": consultar_incidencia}
messages = [{"role": "user", "content": "¿En qué estado está INC-100?"}]

for _ in range(MAX_STEPS):
    response = chat(model=MODEL, messages=messages, tools=[TOOL_SCHEMA])
    messages.append(response.message)

    calls = response.message.tool_calls or []
    if not calls:
        print(response.message.content)
        break

    for call in calls:
        name = call.function.name
        if name not in ALLOWED_TOOLS:
            raise RuntimeError(f"Herramienta no autorizada: {name}")
        try:
            result = ALLOWED_TOOLS[name](**call.function.arguments)
        except (TypeError, ValueError) as exc:
            result = {"error": str(exc)}
        messages.append({
            "role": "tool",
            "tool_name": name,
            "content": json.dumps(result, ensure_ascii=False),
        })
else:
    raise RuntimeError("El agente superó el límite de pasos")

Este ejemplo incorpora cuatro límites que deben mantenerse al conectar sistemas reales: lista explícita de herramientas, validación de parámetros, máximo de pasos y función de solo lectura. En producción añade identidad del usuario, autorización por recurso, timeout, evitar acciones duplicadas, registro de decisiones y una salida que el revisor pueda entender.

Elegir entre n8n, Open WebUI y un orquestador en Python

El framework organiza el bucle, pero no resuelve autorización, calidad del dato ni responsabilidad. Para el primer despliegue, una sola herramienta de lectura y una métrica clara ofrecen más información que un sistema con muchos agentes y permisos amplios.

Antes de habilitar escritura, conecta la evaluación descrita en esta guía con la arquitectura de n8n, Ollama y Outlook y con los controles de IA local y RGPD.