Cómo crear un sistema agéntico: guía práctica para equipos de ingeniería

Por qué los sistemas agénticos importan ahora

Un chatbot responde preguntas. Un pipeline RAG recupera documentos y los resume. Un sistema agéntico hace algo distinto: toma acciones—consulta tu base de datos, llama una API, crea un ticket, reinicia un servicio—a partir de un objetivo que le das.

Para equipos de ingeniería mid-market (aproximadamente 20–50 empleados), este es el salto de "IA que habla" a "IA que trabaja". No necesitas un equipo de investigación en IA. Necesitas una arquitectura clara, un conjunto pequeño de herramientas y la misma disciplina operativa que ya aplicas a web apps y APIs.

Esta guía recorre cómo crear un sistema agéntico desde cero: qué construir primero, qué dejar para después y qué separa un demo de algo que puedes operar en producción.

Qué hace que un sistema sea "agéntico"

Un sistema agéntico tiene cuatro propiedades:

1. Orientado a objetivos: Le das una meta ("encuentra por qué falló el checkout del pedido #4821"), no un guion de pasos.
2. Usa herramientas: Llama funciones, APIs o servidores MCP para obtener información y actuar sobre el mundo.
3. Iterativo: Corre un loop—observar, razonar, actuar, observar de nuevo—hasta cumplir el objetivo o escalar.
4. Acotado: Opera dentro de límites que defines: qué herramientas puede usar, qué puede modificar, cuándo debe detenerse y pedir ayuda a un humano.

Si tu sistema solo llama al LLM una vez y devuelve texto, no es agéntico. Si corre un loop de varios pasos con llamadas a herramientas y memoria, sí lo es—aunque el loop tenga solo tres pasos.

Sistema agéntico vs chatbot vs RAG

Muchos sistemas en producción combinan los tres: RAG para contexto, herramientas para acción, conversación como interfaz. El stack RAG con Postgres y Lambda es una capa de retrieval sólida; los agentes se apoyan encima.

Arquitectura central

Todo sistema agéntico comparte los mismos bloques:

1. El LLM (motor de razonamiento)

El modelo decide qué hacer después: llamar una herramienta, pedir aclaración o devolver una respuesta final. No necesitas el modelo más grande—uno de nivel medio con buen soporte de tool-calling basta para la mayoría de workflows internos.

2. Herramientas (las manos)

Las herramientas son funciones tipadas que el agente puede invocar: search_orders, get_server_logs, create_jira_ticket. Cada una tiene nombre, descripción (el modelo la lee para decidir cuándo usarla) y parámetros de entrada.

Mantén las herramientas pequeñas y componibles. Una herramienta que hace "investigar incidente" es difícil de depurar. Tres—fetch_metrics, search_logs, list_recent_deploys—dan flexibilidad al agente y observabilidad a ti.

3. El loop del agente (orquestación)

El loop es el corazón del sistema:

Objetivo del usuario → LLM razona → ¿Llamar herramienta? → Ejecutar → Devolver resultado → LLM razona → ... → Respuesta final

Limitas las iteraciones (p. ej. 10 pasos) para controlar costo y evitar loops descontrolados. Al llegar al límite, el agente escala a un humano.

4. Memoria (corto y largo plazo)

• Corto plazo: La conversación y resultados de herramientas en la sesión actual.
• Largo plazo (opcional): Preferencias del usuario, resoluciones pasadas o embeddings para retrieval. Empieza sin ella; agrégala cuando un caso de uso real necesite continuidad entre sesiones.

5. Barreras de seguridad (guardrails)

Reglas que corren fuera del modelo: bloquear acciones destructivas, exigir aprobación para escrituras, redactar PII en logs, imponer límites de gasto. Los guardrails son código—no prompts. Lo que nadie te cuenta sobre agentes de IA en producción explica por qué esta capa importa más que la elección del modelo.

Paso a paso: construye tu primer agente

Crearemos un agente mínimo de triage de soporte en TypeScript. Lee un mensaje del cliente, busca pedidos y redacta una respuesta.

Paso 1: Define tus herramientas

const tools = [
  {
    name: "search_orders",
    description: "Buscar pedidos por email del cliente o ID de pedido",
    parameters: {
      type: "object",
      properties: {
        query: { type: "string", description: "Email o ID de pedido" },
      },
      required: ["query"],
    },
  },
  {
    name: "get_order_status",
    description: "Obtener estado de envío y pago de un pedido",
    parameters: {
      type: "object",
      properties: {
        order_id: { type: "string" },
      },
      required: ["order_id"],
    },
  },
];

Implementa las funciones reales detrás de estas herramientas—llaman a tu base de datos o API interna.

Paso 2: Implementa el loop del agente

async function runAgent(userMessage: string, maxSteps = 8) {
  const messages = [
    {
      role: "system",
      content: `Eres un agente de triage de soporte. Usa herramientas para consultar pedidos.
Nunca inventes datos de pedidos. Si no encuentras información, dilo y escala.`,
    },
    { role: "user", content: userMessage },
  ];

  for (let step = 0; step < maxSteps; step++) {
    const response = await llm.chat({ messages, tools });

    if (response.tool_calls?.length) {
      for (const call of response.tool_calls) {
        const result = await executeTool(call.name, call.arguments);
        messages.push(response.message, {
          role: "tool",
          tool_call_id: call.id,
          content: JSON.stringify(result),
        });
      }
      continue;
    }

    return response.content; // Respuesta final
  }

  return "No pude resolver esto dentro del límite de pasos. Escalando a un humano.";
}

Este patrón funciona con OpenAI, Anthropic o cualquier proveedor con soporte de tool/function calling.

Paso 3: Conecta backends reales

Reemplaza implementaciones mock con fuentes de datos reales. Empieza en solo lectura: buscar y consultar, sin escrituras. Cuando el retrieval sea confiable, agrega herramientas de escritura (crear ticket, actualizar estado) detrás de puertas de aprobación.

Paso 4: Agrega observabilidad desde el día uno

Registra cada paso: entrada, herramienta llamada, resultado, tokens usados, latencia. Lo necesitarás cuando algo falle—y fallará. Logs estructurados superan rearmar conversaciones de memoria.

Conectar herramientas con MCP

Construir wrappers de herramientas por integración no escala. El Model Context Protocol (MCP) estandariza cómo los agentes descubren y llaman herramientas expuestas por servidores externos.

En lugar de hardcodear search_orders en tu agente, conectas un servidor MCP que expone tu CRM, base de datos o CLI interna. El agente ve un catálogo de herramientas en runtime. Cuando agregas un servidor MCP nuevo, el agente gana capacidades sin cambios en la capa de orquestación.

Para equipos mid-market, MCP es especialmente útil cuando:

• Varios agentes necesitan las mismas integraciones
• Quieres que no ingenieros expongan herramientas vía una interfaz estándar
• Te conectas a sistemas que no controlas (IDEs, consolas cloud, ticketing)

Patrones de producción que sí funcionan

Empieza con un workflow acotado

No construyas "la IA de la empresa." Elige una tarea dolorosa y repetitiva: triage de emails de soporte, resumen de alertas nocturnas o prellenado de reportes de incidentes. Despliégalo. Aprende. Expande.

Humano en el loop para escrituras

Deja que el agente redacte; que un humano apruebe antes de mutar datos de producción. Automatiza gradualmente acciones de bajo riesgo conforme crece la confianza.

Evaluación antes del despliegue

Arma un golden dataset: 20–50 escenarios reales con llamadas a herramientas y salidas esperadas. Corre el agente contra él después de cada cambio de prompt o herramienta. El comportamiento del LLM cambia; tu suite de eval detecta regresiones.

Control de costos

Cada paso de razonamiento y llamada a herramienta cuesta tokens. Define presupuestos por request, usa modelos más pequeños para routing y cachea resultados de retrieval. Hemos visto facturas dispararse cuando los agentes "piensan en voz alta" sin límites.

Escalar es una feature

Un buen agente sabe cuándo detenerse. Define disparadores claros de escalamiento: datos faltantes, intención ambigua, acción de alto riesgo, límite de pasos alcanzado. Escalar a un humano es éxito—no fracaso.

Qué construir vs qué comprar

No necesitas LangChain, CrewAI ni un framework multi-agente el día uno. Un loop de 50 líneas con llamadas directas a la API es más fácil de depurar y suele bastar para un primer agente en producción.

Cuándo agregar patrones multi-agente

Los setups multi-agente—uno planifica, otro ejecuta, un tercero revisa—añaden overhead de coordinación. Úsalos cuando:

• Las tareas requieren roles genuinamente especializados (investigación vs código vs revisión)
• El context window de un solo agente se satura
• Necesitas flujos paralelos con lógica de merge

Para la mayoría de casos mid-market, un agente bien equipado supera a tres mal coordinados.

Checklist antes de producción

• [ ] Las herramientas son solo lectura o las escrituras requieren aprobación
• [ ] Límite de pasos y presupuesto de tokens configurados
• [ ] Cada ejecución registrada con llamadas a herramientas y resultados
• [ ] Golden eval set pasa después de cambios
• [ ] Ruta de escalamiento definida y probada
• [ ] PII y secretos nunca enviados al modelo sin redactar
• [ ] Alertas de costo configuradas

Conclusión

Crear un sistema agéntico no es magia—es ingeniería. Define un objetivo, expón herramientas pequeñas, corre un loop acotado, agrega guardrails y observa todo. Empieza acotado, despliega en un workflow y expande cuando producción te enseñe qué se rompe.

Si exploras agentes de IA para operaciones empresariales, los mismos principios aplican: observar, razonar, actuar—dentro de límites que tu equipo define. Los equipos que triunfan tratan a los agentes como cualquier otro servicio en producción: aburridos, observables y mejorados de forma incremental.