Cómo crear agentes de IA: guía práctica paso a paso (2026)

Un agente de IA no es un chatbot con más prompts. Es un sistema que puede planificar, ejecutar acciones en el mundo real, observar los resultados y ajustar su comportamiento. La diferencia entre un chatbot y un agente es la misma que entre un libro de recetas y un chef: el libro responde preguntas, el chef cocina.

En 2026, crear agentes de IA ya no es experimental. Es una disciplina de ingeniería con frameworks maduros, patrones establecidos y herramientas de producción. Pero también es un campo donde es fácil sobredimensionar: muchos proyectos de "agentes" son en realidad cadenas de prompts disfrazadas, y muchos frameworks prometen autonomía que luego no entregan.

Esta guía es práctica. Vamos a construir la comprensión desde los fundamentos hasta multi-agente y deployment, con código real, decisiones de arquitectura y los errores que he visto en producción. Si buscas la teoría sobre qué son los agentes, tenemos la guía conceptual. Aquí vamos a construir.

Qué es un agente de IA (y qué no es)

Un agente de IA tiene tres capacidades que lo diferencian de un simple LLM:

1. Razonamiento: decide qué hacer basándose en la situación actual y el objetivo.
2. Acción: ejecuta operaciones en el mundo real (llamar APIs, leer archivos, enviar emails, consultar bases de datos).
3. Observación: evalúa el resultado de sus acciones y decide si necesita hacer algo más o si ha terminado.

Este ciclo Razonar-Actuar-Observar es el corazón de todo agente. El LLM piensa, el tool ejecuta, el resultado vuelve al LLM, y el ciclo se repite hasta completar la tarea o alcanzar un límite.

Lo que NO es un agente:

• Un chatbot con un system prompt largo. Eso es un chatbot.
• Una cadena de prompts ejecutados en secuencia. Eso es un pipeline.
• Un LLM que genera JSON estructurado. Eso es structured output.
• Un workflow de n8n con un nodo de IA. Eso es una automatización (que puede ser muy útil, pero no es un agente).

Un agente decide dinámicamente qué hacer en cada paso. No sigue un script fijo. Puede usar 2 tools o 20, dependiendo de lo que encuentre. Puede pedir más información, cambiar de estrategia o decidir que no puede completar la tarea. Esa flexibilidad es lo que lo hace poderoso y, al mismo tiempo, lo que lo hace difícil de controlar.

Frameworks: LangGraph, CrewAI, AutoGen y Anthropic SDK

En 2026 hay cuatro frameworks principales para construir agentes. Cada uno tiene un enfoque diferente y encaja en distintos escenarios.

LangGraph (LangChain). El más completo y el más complejo. LangGraph modela el agente como un grafo de estados: cada nodo es una acción o decisión, y las aristas definen las transiciones. Ventajas: control total sobre el flujo, checkpointing (puedes pausar y reanudar), subgraphs para multi-agente, streaming nativo. Desventajas: curva de aprendizaje pronunciada, verboso para casos simples. Usa LangGraph cuando necesites flujos con decisiones condicionales, estado persistente entre ejecuciones, o multi-agente coordinado. Para empezar con LangChain, revisa nuestro tutorial en español.

CrewAI. Enfocado en equipos de agentes con roles definidos. Cada agente tiene un rol, un objetivo y un set de tools. CrewAI orquesta la colaboración entre agentes de forma simple. Ventajas: API intuitiva, configuración declarativa, bueno para prototipos rápidos. Desventajas: menos control que LangGraph, difícil de personalizar para flujos no estándar. Usa CrewAI cuando quieras un equipo de agentes con roles claros (investigador, escritor, revisor) y no necesites un flujo de estado complejo.

AutoGen (Microsoft). Diseñado para conversaciones multi-agente. Los agentes se comunican entre sí en un patrón conversacional. Ventajas: bueno para escenarios de debate/refinamiento, soporte para ejecución de código, integración con Azure. Desventajas: el modelo conversacional no encaja en todos los casos de uso, documentación a veces confusa. Usa AutoGen cuando el workflow sea "agente A genera, agente B revisa, agente A refina".

Anthropic SDK (tool use nativo). No es un framework en el sentido tradicional. Es la API de Claude con tool use integrado. El LLM decide cuándo llamar a qué tool y procesa los resultados. Ventajas: la implementación más simple posible, excelente calidad de razonamiento (Claude es uno de los mejores modelos para tool use), sin dependencias externas. Desventajas: necesitas construir tú la lógica de estado, memoria y orquestación. Usa el SDK de Anthropic cuando quieras un agente simple sin framework, o cuando la calidad del razonamiento sea más importante que la infraestructura.

# Agente mínimo con Anthropic SDK (Python)
import anthropic

client = anthropic.Anthropic()
tools = [
    {
        "name": "search_web",
        "description": "Busca información en la web",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "Consulta de búsqueda"}
            },
            "required": ["query"]
        }
    }
]

messages = [{"role": "user", "content": "Busca las últimas noticias sobre IA en España"}]

# Loop del agente: razonar -> actuar -> observar -> repetir
while True:
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=4096,
        tools=tools,
        messages=messages
    )

    # Si no hay tool calls, el agente ha terminado
    if response.stop_reason == "end_turn":
        print(response.content[0].text)
        break

    # Procesar tool calls
    for block in response.content:
        if block.type == "tool_use":
            result = execute_tool(block.name, block.input)  # Tu implementación
            messages.append({"role": "assistant", "content": response.content})
            messages.append({
                "role": "user",
                "content": [{"type": "tool_result", "tool_use_id": block.id, "content": result}]
            })

Tools y function calling

Los tools son las manos del agente. Sin tools, un agente solo puede pensar y hablar. Con tools, puede actuar. El function calling (o tool use) es el mecanismo por el que el LLM decide qué tool usar y con qué parámetros.

Principios para diseñar buenos tools:

• Nombres descriptivos. search_customer_by_email es mejor que search. El LLM usa el nombre para decidir cuándo usar el tool.
• Descripciones claras. Incluye qué hace, cuándo usarlo y qué devuelve. El LLM lee la descripción para entender el contexto.
• Parámetros mínimos. Cuantos menos parámetros, menos posibilidad de error. Si un tool tiene 10 parámetros, probablemente debería ser 3 tools diferentes.
• Outputs estructurados. Devuelve JSON limpio con los datos relevantes. Evita devolver texto narrativo largo que el LLM tenga que parsear.
• Gestión de errores. Cuando un tool falla, devuelve un mensaje de error claro, no una excepción cruda. El agente necesita entender qué salió mal para decidir qué hacer.

Categorías de tools comunes:

• Lectura: consultar APIs, leer archivos, buscar en bases de datos, web search.
• Escritura: crear registros, enviar emails, escribir archivos, publicar contenido.
• Computación: ejecutar código, transformar datos, calcular métricas.
• Comunicación: enviar mensajes a otros agentes, notificar a usuarios, solicitar aprobación humana.

Un patrón importante: los tools de escritura siempre deben tener un mecanismo de confirmación. Un agente que puede enviar emails sin supervisión humana es un riesgo. Implementa human-in-the-loop (HITL) para acciones irreversibles.

Memoria: short-term y long-term

La memoria es lo que distingue un agente que ejecuta tareas aisladas de uno que aprende y mejora. Hay dos tipos fundamentales.

Short-term memory (memoria de conversación). Es el contexto de la sesión actual: los mensajes anteriores, los resultados de tools, las decisiones tomadas. Todos los LLMs tienen esto por defecto (la ventana de contexto). El problema: la ventana tiene un límite. Claude tiene 200K tokens, GPT-4o tiene 128K. Para sesiones largas, necesitas una estrategia de compresión: resumir mensajes antiguos, descartar tool results procesados, mantener solo las decisiones clave.

Long-term memory (memoria persistente). Información que persiste entre sesiones. Preferencias del usuario, hechos aprendidos, resultados de tareas anteriores. Se implementa con bases de datos vectoriales (Qdrant, Pinecone, ChromaDB) para búsqueda semántica, o con stores de key-value para datos estructurados. El patrón: al final de cada sesión, el agente extrae los hechos relevantes y los persiste. Al inicio de la siguiente, recupera el contexto relevante.

Scratchpad. Un espacio temporal donde el agente puede escribir notas durante la ejecución. Es como el papel borrador de un examen: el agente escribe su razonamiento intermedio, resultados parciales y plan actualizado. No va al usuario, es para consumo interno del agente. Esto mejora significativamente la calidad del razonamiento en tareas complejas.

Planning: ReAct y Plan-and-Execute

El planning es cómo el agente decide qué hacer y en qué orden. Hay dos patrones dominantes.

ReAct (Reasoning + Acting). El agente razona paso a paso: piensa qué hacer, ejecuta una acción, observa el resultado, y vuelve a pensar. No planifica toda la secuencia de antemano, sino que decide el siguiente paso basándose en lo que acaba de aprender. Ventajas: adaptativo, reacciona bien a resultados inesperados. Desventajas: puede entrar en loops, no tiene visión global de la tarea.

Plan-and-Execute. El agente primero genera un plan completo (lista de pasos) y después los ejecuta uno a uno. Si un paso falla o produce un resultado inesperado, puede re-planificar. Ventajas: más predecible, mejor para tareas con estructura conocida. Desventajas: el plan inicial puede ser subóptimo si falta información, re-planificar consume tokens.

En la práctica, la mayoría de agentes de producción usan un híbrido: Plan-and-Execute para la estructura general y ReAct para la ejecución de cada paso. El agente genera un plan de 5 pasos, ejecuta el primero con ReAct (razonando sobre los resultados de cada tool call), y al terminar el paso, verifica si el plan sigue siendo válido antes de pasar al siguiente.

# Pseudo-código: Plan-and-Execute con ReAct por paso
plan = agent.create_plan(task)  # "1. Buscar datos, 2. Analizar, 3. Generar informe"

for step in plan.steps:
    result = agent.execute_with_react(step)  # ReAct loop para cada paso

    if result.requires_replan:
        plan = agent.replan(task, completed_steps, result)

    if result.task_complete:
        break

Multi-agente: coordinator + workers

Cuándo una tarea es demasiado compleja para un solo agente (o requiere diferentes habilidades), se divide en múltiples agentes. El patrón más robusto es coordinator + workers.

Coordinator. Un agente que no ejecuta tareas directamente. Su trabajo es: entender la tarea global, descomponerla en subtareas, asignar cada subtarea al worker adecuado, recopilar los resultados, verificar la calidad y combinar todo en la respuesta final. El coordinator usa un modelo potente (Claude Sonnet, GPT-4o) porque su trabajo es pensar, no ejecutar.

Workers. Agentes especializados que ejecutan una subtarea específica. Cada worker tiene sus propios tools y su propio contexto. Un worker de investigación tiene tools de búsqueda web. Un worker de análisis tiene acceso a la base de datos. Un worker de redacción tiene el estilo guide y los templates. Los workers pueden usar modelos más ligeros (Claude Haiku, GPT-4o-mini) porque su tarea es acotada.

Comunicación entre agentes. Los workers NO se comunican directamente entre sí. Todo pasa por el coordinator o por un scratchpad compartido. Esto evita el caos de N agentes hablando entre sí sin control. El coordinator lee los resultados de cada worker, decide si son suficientes, y pasa la información al siguiente worker si es necesario.

Anti-patrón: el coordinator perezoso. Un coordinator que dice "basándote en lo que encontró el researcher, escribe un informe" sin pasar los datos específicos es un coordinator perezoso. El coordinator debe leer los resultados del researcher, extraer lo relevante, y dar instrucciones precisas al writer. Si quieres entender mejor los subagentes, consulta la guía de subagentes en Claude Code.

Deployment y observabilidad

Un agente que funciona en tu portátil no es un agente en producción. El deployment y la observabilidad son lo que separa un demo de un sistema que funciona de verdad.

Deployment. Los agentes se despliegan como servicios backend: FastAPI, Express o similar, expuestos via API. El agente recibe una tarea, la procesa (potencialmente durante minutos, no milisegundos) y devuelve el resultado. Para tareas largas, usa un patrón async: el cliente envía la tarea, recibe un ID, y consulta el estado periódicamente. WebSockets o SSE para streaming de progreso.

Circuit breakers. Obligatorio. Un agente sin límites puede entrar en un loop infinito, consumir miles de tokens de API y no producir nada útil. Implementa: max_iterations (máximo de ciclos del loop del agente), max_tokens (presupuesto total de tokens por ejecución), timeout (tiempo máximo de ejecución), max_tool_calls (máximo de tool calls por ejecución). Si cualquier límite se alcanza, el agente se detiene y devuelve lo que tiene hasta el momento.

Observabilidad. En producción, necesitas ver qué está haciendo el agente en cada paso. Herramientas: Langfuse (open source, trazas de agentes), OpenTelemetry (trazas distribuidas estándar), LangSmith (de LangChain, integrado con LangGraph). Cada tool call, cada decisión del LLM y cada resultado debe quedar registrado. Cuando algo falla en producción a las 3 de la mañana, necesitas las trazas para entender qué pasó.

Evaluación continua. Los agentes necesitan tests, igual que el código. Crea un dataset de evaluación: pares de (tarea, resultado esperado). Ejecuta el agente contra el dataset regularmente y mide: tasa de éxito, calidad de resultados, tokens consumidos, tiempo de ejecución. Si la calidad baja (porque el modelo se actualizó o porque un tool cambió), lo detectas antes de que afecte a usuarios.

Errores comunes al crear agentes

1. El agente monolítico. Un solo agente que hace todo: investiga, analiza, escribe, revisa y envía. Funciona en demos, falla en producción. El contexto se satura, el razonamiento se degrada, y los errores se acumulan. Divide en coordinator + workers.

2. Demasiados tools. Un agente con 30 tools es un agente confundido. El LLM pierde precisión al elegir el tool correcto cuando hay demasiadas opciones. Máximo 7-10 tools por agente. Si necesitas más, divide en múltiples workers especializados.

3. No implementar HITL. Human-in-the-loop no es un "nice to have" para agentes que ejecutan acciones en el mundo real. Enviar emails, modificar bases de datos, publicar contenido, todas estas acciones necesitan un checkpoint de aprobación humana. Al menos en las primeras semanas de producción, hasta que confíes en el agente.

4. Ignorar los costes. Un agente con Claude Sonnet que hace 50 tool calls por tarea consume tokens rápidamente. A escala (1000 tareas/día), puedes estar pagando más en API que en desarrolladores. Optimiza: usa modelos ligeros para clasificación y routing, modelos grandes solo para razonamiento complejo. Cachea resultados de tools cuando sea posible.

5. No tener un fallback. Cuando el LLM falla (y falla), el agente necesita un plan B. Si el tool de búsqueda web no responde, usa un cache local. Si el LLM genera un output inválido, reintenta con un prompt más específico. Si después de 3 reintentos sigue fallando, escala a un humano. Nunca dejes al agente bloqueado sin salida.

6. Prompts no versionados. Los prompts de un agente son código. Si cambias un prompt sin versionarlo, no puedes reproducir un bug ni hacer rollback. Guarda los prompts en archivos versionados (docs/prompts/), con número de versión y fecha. Cada cambio de prompt debería pasar por el mismo proceso que un cambio de código: review, test, deploy. Más sobre agentes en nuestra guía conceptual de agentes de IA.

Preguntas frecuentes