Cómo funcionan realmente los agentes de IA: arquitectura, memoria, herramientas y el bucle del agente

Introducción

Mucha gente resume los agentes de IA como "un LLM con herramientas". Es más o menos cierto, pero incompleto.

Para entender how AI agents work, necesitas una visión de sistemas: un agente es un bucle de control que (1) lee estado, (2) decide, (3) actúa y (4) mide lo que ocurrió. El LLM suele ser el módulo de decisión, pero el agente es todo el runtime alrededor.

Este artículo es una guía técnica sobre AI agent architecture: componentes, flujos de datos y patrones para construir LLM agents que funcionen en producción.

Por qué los agentes de IA son importantes ahora

Los agentes importan porque tres cosas se volvieron prácticas al mismo tiempo:

1. Los modelos ya planifican y eligen herramientas para muchas tareas acotadas.
2. El tool calling se volvió una interfaz de primera clase (function calls estructurados, JSON schemas, salidas restringidas).
3. Bajó el costo y la latencia lo suficiente como para correr bucles multi-paso.

Dónde se usan hoy

Ya hay agentes en producción para:

• Herramientas dev: búsqueda en código, refactors, generación de tests, triage de CI, revisiones de PR.
• Soporte y operaciones: clasificación de tickets, ejecución de runbooks, resumen de incidentes.
• Datos: generación de SQL con validación, explicación de dashboards, seguimiento de anomalías.
• Seguridad e IT: workflows de acceso, enrichment de alertas, remediación (con aprobaciones).
• Investigación: recolección de fuentes, resumen y síntesis (con checkpoints humanos).

Qué es un agente de IA?

Definición (simple y útil): un agente de IA es un sistema de software que usa un LLM (u otra policy) dentro de un bucle para elegir acciones que cambian el estado de un entorno con el fin de alcanzar un objetivo.

Tres elementos no negociables:

1. Bucle: múltiples pasos, no un solo prompt.
2. Acciones: efectos reales (APIs, escrituras en DB, edición de archivos, transacciones).
3. Estado: lee y actualiza una representación del mundo (observaciones + memoria).

LLM vs chatbot vs AI agent

Un modelo mental útil:

Cosa	Qué es	Qué produce	Fallo típico
LLM	Función probabilística texto -> texto	Tokens (texto / JSON)	"Hallucinations" convincentes
Chatbot	Un LLM con UI conversacional	Mensajes	Útil pero pasivo (sin acción)
AI agent	Bucle + estado + herramientas + policies con un LLM como planner	Acciones y resultados	Acciones inseguras, malos tool calls, loops

Callout: un LLM es stateless; un agente es stateful. Esa diferencia guia casi toda la arquitectura.

Arquitectura base de un agente de IA

Puedes implementar agentes de muchas formas, pero la mayoría de diseños de producción comparten los mismos componentes.

(inputs) User/Env
      |
      v
  +---------------------------+
  | Perception / I-O          |
  +-------------+-------------+
                |
                v
  +---------------------------+      +---------------------------+
  | Context Builder           | <--> | Memory                    |
  | (rules + RAG + schemas)   |      | (state + vector DB)       |
  +-------------+-------------+      +---------------------------+
                |
                v
  +---------------------------+
  | LLM Reasoner              |
  | (plan + choose next step) |
  +-------------+-------------+
                |
                v
  +---------------------------+
  | Tool Router + Guardrails  |
  | (validate + approve +     |
  |  retry + limits)          |
  +-------------+-------------+
                |
                v
  +---------------------------+      +---------------------------+
  | Tool Execution            | ---->| External systems / tools  |
  | (APIs, DBs, code, web)    |<---- | (APIs, DBs, services...)  |
  +-------------+-------------+      +---------------------------+
                |
                v
  +---------------------------+
  | Observations              |
  | (results + errors + state)|
  +-------------+-------------+
                |
                v
  +---------------------------+
  | Eval + Telemetry          |
  | (score + trace + alerts)  |
  +-------------+-------------+
                |
                +----> loop to Context Builder

(outputs) response / tool calls / state updates

Entradas

Las entradas no son solo "el mensaje del usuario". Un agente suele ingerir:

• un objetivo (que significa éxito)
• restricciones (no enviar emails, pedir aprobación antes de gastar, etc.)
• estado del entorno (ticket, repo, filas de DB, métricas)
• observaciones (resultados de herramientas, errores)
• policies (seguridad, compliance, aislamiento por tenant)

Razonamiento

El "razonamiento" suele ser una llamada al LLM, pero la decisión clave es:

• tratar al LLM como un planner no confiable
• mantener el orquestador determinista y estricto

Implementación: no dejes que el LLM ejecute herramientas directamente. Interpone un tool router entre el LLM y los efectos (ReAct, plan-and-execute, etc.).

Memoria

Los agentes necesitan memoria porque las llamadas al LLM son (en la practica) stateless.

Cuando hablamos de "memoria" suelen ser dos cosas: estado de corto plazo durante un run y conocimiento de largo plazo entre runs (hechos, preferencias, decisiones).

Herramientas

Las herramientas son como el agente actúa sobre el mundo. Una herramienta es una función con contrato:

• nombre + descripción
• esquema de entrada
• implementación determinista
• clasificación de riesgo (read-only vs write, reversible vs irreversible)

Acciones

Acciones = efectos producidos por herramientas:

• lectura: fetch de un record, listar archivos, consultar métricas
• escritura: actualizar ticket, abrir PR, enviar email
• comunicación: pedir información o aprobación

En producción, las acciones deben ser idempotentes y auditables.

Bucle de feedback

Sin feedback, un agente se convierte en un "demo loop": hace cosas sin saber si ayudó.

Feedback típico: métricas de resultado (success rate, correcciones), señales de seguridad, evaluación (rúbricas, regresión) y trazas por paso.

El agent loop explicado (Perceive, Think, Act, Evaluate, Repeat)

La mayoria de LLM agents se entienden con cinco fases:

1. Percibir: recolectar observaciones.
2. Pensar: elegir el siguiente paso.
3. Actuar: ejecutar una accion (herramienta o respuesta).
4. Evaluar: verificar impacto, seguridad y errores.
5. Repetir: actualizar estado y continuar hasta una condición de stop.

Pseudo-codigo minimo

type Observation = { kind: "user" | "tool"; payload: unknown };
type ToolCall = { tool: string; args: unknown };

type StepDecision =
  | { kind: "tool_call"; call: ToolCall }
  | { kind: "final"; output: string };

const MAX_STEPS = 12;

export async function runAgent(goal: string, userMessage: string) {
  const state = { goal, history: [] as Observation[] };

  for (let step = 0; step < MAX_STEPS; step++) {
    // 1) Perceive
    const observation: Observation = step === 0
      ? { kind: "user", payload: userMessage }
      : state.history[state.history.length - 1];

    // 2) Think
    const context = buildContext({ state, observation });
    const decision: StepDecision = await llmDecide({ context, toolSchemas });

    // 3) Act
    if (decision.kind === "final") return decision.output;

    const validated = validateToolCall(decision.call); // schema + policy checks
    const result = await executeTool(validated);

    // 4) Evaluate + 5) Repeat
    recordTrace({ step, validated, result });
    state.history.push({ kind: "tool", payload: result });

    if (isGoalSatisfied({ goal, result })) break;
  }

  return "Stopped: max steps reached (needs human review).";
}

Detalle importante: el loop es un programa normal con condiciones de corte (max pasos/tiempo, éxito, error no recuperable, riesgo alto -> aprobación).

Memoria en agentes de IA

La memoria es donde muchos prototipos se rompen en producción. El problema rara vez es "el modelo". Es el producto de memoria.

Memoria de corto plazo vs largo plazo

Piensa en capas:

Corto plazo (por run)
- objetivo y plan actuales
- resultados intermedios
- scratchpad (a menudo no se guarda)

Largo plazo (entre runs)
- perfil/preferencias
- hechos del proyecto (APIs, endpoints, repos)
- decisiones y outcomes (que funciono / que no)
- conocimiento del dominio que debe ser consistente

El corto plazo es lo que entra al siguiente prompt. El largo plazo es lo que guardas fuera del prompt.

Vector databases, embeddings y retrieval (RAG)

Un vector DB implementa recuerdo "fuzzy":

• guardas chunks + embedding vector
• embeddeas la query y haces similarity search
• inyectas top-k en el prompt

RAG (retrieval-augmented generation) suele ser la diferencia entre "plausible" y "correcto".

Detalles prácticos: chunking, filtros de metadata, re-ranking y compresión de contexto.

Pipeline de retrieval (sketch)

async function retrieveContext(input: { userId: string; query: string }) {
  const rewritten = await llmRewriteQuery(input.query);
  const q = await embed(rewritten);

  const candidates = await vectorDb.search(q, {
    topK: 12,
    filter: { userId: input.userId, docType: ["policy", "decision", "runbook"] },
  });

  const reranked = await rerank(candidates, { query: rewritten });
  const top = reranked.slice(0, 6);

  return compressForPrompt(top, { maxTokens: 900 });
}

Callout: la memoria de largo plazo debería guardar hechos, no transcripts. Guarda "refund denied el 2026-01-10 por policy v4", no 200 líneas de chat.

Herramientas y acciones externas

Las herramientas son la frontera entre lenguaje y realidad, y la principal superficie de riesgo.

APIs

Para APIs, aplica ingeniería backend: inputs tipados, timeouts/retries, idempotency para writes.

Ejemplo de schema de herramienta:

{
  "name": "search_tickets",
  "description": "Search support tickets (read-only).",
  "parameters": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20 }
    },
    "required": ["query"]
  }
}

Bases de datos

Separa read y write:

• read: SELECT safe, guards, límites
• write: operaciones explícitas, diffs validados, aprobaciones si riesgo

Ejecución de código

Si el agente ejecuta código: sandbox, límites de recursos, filesystem read-only por defecto y nunca exponer secretos.

Navegacion (browsing)

La web es input no confiable. La salida de herramientas puede contener instrucciones ("ignore previous rules") para desviar al agente.

Mitigaciones: tratar páginas como datos, aislar browsing de herramientas privilegiadas y exigir citas para claims factuales.

Single-agent vs multi-agent

Arquitecturas multi-agent pueden ayudar, pero también multiplican la complejidad.

Diferencias

• Single-agent: un loop, un estado, un set de herramientas. Más simple de depurar y más barato.
• Multi-agent: loops especializados (planner, researcher, executor, critic). Más paralelismo, más failure modes.

Use cases

Single-agent:

• workflows acotados (triage, resumen, formularios)
• tareas tool-heavy con restricciones claras
• asistentes interactivos con approvals/checkpoints

Multi-agent:

• investigación/análisis grande (fuentes en paralelo + síntesis)
• software engineering (design/implement/review separados)
• ops con roles monitor/remediate

Cuando elegir?

Empieza single-agent. Cambia a multi-agent solo si la especialización mejora outcomes.

             +------------------+
User/Task -->|  Orchestrator    |
             |  (policy + plan) |
             +---+----------+---+
                 |          |
        +--------+--+   +---+---------+
        | Researcher |   | Executor   |
        | (read-only)|   | (tool run) |
        +--------+---+   +---+--------+
                 |           |
                 +-----+-----+
                       v
                   Critic/Eval

Puntos de falla comunes

Hallucinations

A menudo es falta de retrieval o stop conditions.

Mitigaciones: RAG + hechos en prompt, outputs estructurados (schemas), citas (IDs de tools/docs).

Mal uso de herramientas

Síntomas: argumentos incorrectos, write tool innecesario, repetición de calls por errores mal manejados.

Mitigaciones: validación estricta, risk levels + approvals, fallbacks deterministas (retry/backoff).

Loops infinitos

Mitigaciones: max pasos/duración, heurísticas de progreso, detección de repetición.

Mala memoria

Sintomas: contexto stale, fuga de datos, retrieval ruidoso.

Mitigaciones: hechos estructurados + metadata, TTL/recency, filtros, redacción.

Arquitectura de referencia (estilo producción)

Client/UI
  |
  v
API (auth, rate limits)
  |
  v
Agent Orchestrator
- builds context (policy + retrieval + tool schemas)
- calls LLM (planner)
- routes tools with guardrails
  |
  +--> Tool Registry (read / write risk-gated)
  +--> Memory Stores (relational + vector DB)
  +--> Evaluation + Telemetry (traces, metrics, regression)

Flujo end-to-end

Request
  -> Authenticate + authorize
  -> Retrieve memory (RAG + structured facts)
  -> Build prompt/context (constraints + tool schemas)
  -> LLM decides next step (tool call or final answer)
  -> Validate + risk gate
  -> Execute tool (idempotent, traced)
  -> Store observation + update memory
  -> Evaluate outcome
  -> Respond (or continue loop)

Regla de ingeniería pragmática

Deja lo probabilístico en los bordes:

• LLM: planning, classification, summarization
• Código determinista: validación, authZ, efectos, persistencia, métricas

Esa es la esencia de "cómo funcionan realmente los agentes" en producción.

Conclusión

Ideas clave

• Un agente es un loop, no un prompt.
• Los LLM agents necesitan arquitectura: memoria, herramientas, validación, evaluación, trazas.
• La memoria es un sistema (RAG depende de chunking, filtros y compresión).
• Las herramientas son APIs: schema-validated, risk-gated, idempotent, auditable.
• Multi-agent es opcional. Empieza simple.

Hacia dónde va el campo

La próxima ola será menos "modelos más grandes" y más:

• runtimes estandarizados + tool contracts
• evaluación automática (regression suites)
• browsing/herramientas más seguras (prompt injection-aware)
• productos de memoria más confiables (recuerdo a largo plazo)

Lectura relacionada

• Por qué fallan los agentes de IA (y cómo arreglarlos)
• Cómo construir agentes de IA (tutorial LangChain)

Construir con IA y entregar bien

Necesitas un desarrollador capaz de llevar una idea a produccion?

Ayudo a equipos a entregar trabajo en React, Next.js, Node.js, IA y automatizacion con alcance claro, guardrails utiles y ejecucion rapida.

Ver perfilVer oferta freelanceContactarme