Arquitectura de un agente empresarial: las 6 decisiones que importan

Tienes un modelo de lenguaje, tienes los documentos de tu empresa, tienes una lista de herramientas que quieres conectar. El problema no es tener los ingredientes. El problema es no saber en qué orden combinarlos para que el resultado sea algo que funcione en producción sin romper nada.

Estas son las seis decisiones de arquitectura que determinan el éxito o el fracaso de un agente empresarial. No están en orden alfabético ni por popularidad: están en el orden en que las tomaría yo.

Antes de seguir: este post asume que sabes qué es un agente IA (un modelo que puede tomar decisiones y usar herramientas de forma autónoma) y que tienes una idea básica de qué es el tool calling (cuando el modelo puede ejecutar funciones de tu código, no solo responder texto). Si aún no tienes claro eso, empieza por ahí.

Decisión 1: Define el objetivo con precisión real

Antes de escribir una línea de código, necesitas responder esta pregunta: ¿qué hace exactamente tu agente?

Parece obvio. No lo es.

Objetivo mal formulado:

“El agente ayuda con las operaciones de soporte al cliente.”

Objetivo bien formulado:

“El agente recibe un ticket de soporte con ID, busca el historial del cliente en la base de datos, clasifica el problema por categoría y urgencia, y devuelve una respuesta estructurada con la categoría, la urgencia y el siguiente paso recomendado. Si la urgencia es alta, escala automáticamente al equipo humano.”

La diferencia no es cosmética. El segundo tiene inputs definidos (ticket con ID), outputs verificables (categoría + urgencia + siguiente paso) y un criterio de éxito medible (¿la clasificación coincide con la que haría un humano?). El primero es un chatbot con aspiraciones.

Un agente con objetivo vago se convierte en un agente que “suele funcionar”. En producción, eso no es suficiente.

Un test útil: si no puedes escribir cinco casos de prueba con input y output esperado antes de construirlo, el objetivo no está suficientemente definido.

Decisión 2: ¿Agente único o sistema multi-agente?

Un agente único es exactamente lo que parece: un modelo con herramientas que completa una tarea de principio a fin. Un sistema multi-agente es un conjunto de agentes donde uno coordina (el orquestador) y otros ejecutan partes especializadas (los workers).

La tentación de ir directo a multi-agente es real. Parece más potente, más escalable. Pero añade una capa de complejidad operativa enorme: más puntos de fallo, más latencia, más debugging.

Usa este criterio para decidir:

Si tu caso de uso necesita…	Usa
Menos de 10 pasos para completar la tarea	Agente único
Herramientas de un solo dominio (solo base de datos, o solo email)	Agente único
Más de 15 pasos con decisiones que pueden ir en paralelo	Multi-agente
Herramientas de dominios radicalmente distintos con riesgos diferentes	Multi-agente
Que un error en ventas no pueda afectar a facturación (aislamiento)	Multi-agente

La mayoría de primeros proyectos empresariales caben perfectamente en un agente único bien diseñado. El multi-agente tiene sentido cuando ese agente único ya ha demostrado su valor y necesitas escalar o aislar responsabilidades. Cuando la complejidad o los requisitos de fiabilidad aumentan de forma sostenida, el agente único alcanza su límite natural: no suele ser un fallo de diseño, es la señal de que has validado el caso de uso y tienes argumentos reales para añadir la complejidad operativa del multi-agente.

Decisión 3: El diseño de herramientas no es un detalle

Cada herramienta que le das a tu agente es una superficie de ataque y un vector de error. Si le das acceso de escritura a toda la base de datos cuando solo necesita leer clientes, has creado un riesgo que no tenías antes.

El principio de mínimo privilegio aplica aquí: cada herramienta accede solo a lo que necesita para hacer su trabajo, nada más.

Aquí tienes la estructura de una herramienta bien diseñada:

// Herramienta de búsqueda de clientes — solo lectura
const searchCustomersTool = {
  name: "search_customers",
  // La descripción la lee el modelo para decidir cuándo usar esta herramienta
  // Si es vaga, el modelo la usará mal o en momentos equivocados
  description: "Busca clientes por nombre o email. Solo lectura. No modifica datos.",
  // Campo personalizado — la API de Anthropic no lo procesa; aplícalo en la capa de autorización de tu backend
  permissions: ["customers:read"],
  input_schema: {
    type: "object",
    properties: {
      query: {
        type: "string",
        // Validación: evita queries vacíos o demasiado largos
        description: "Nombre o email a buscar. Mínimo 2 caracteres.",
        minLength: 2,
        maxLength: 100
      },
      limit: {
        type: "number",
        description: "Número máximo de resultados.",
        default: 10,
        maximum: 50
      }
    },
    required: ["query"]
  }
};

Dos cosas sobre este código. La description no es documentación para ti: es la instrucción que el modelo lee para decidir si usa esta herramienta o no. Si es vaga, el modelo la usará en momentos equivocados. Y el input_schema con minLength y maxLength no es solo buenas prácticas: es la primera línea de defensa contra entradas inesperadas que podrían causar comportamientos raros. El SDK de TypeScript de Anthropic acepta inputSchema en camelCase y lo normaliza internamente, pero la documentación oficial usa input_schema en snake_case: usa la versión que encaje con tu setup, pero sé consistente.

El campo permissions del ejemplo es una convención propia, no parte del schema de la API de Anthropic. El SDK lo ignorará silenciosamente. La validación real de permisos debe aplicarse en tu backend antes de ejecutar la herramienta: comprueba que el agente tiene autorización para la operación antes de llamar a la base de datos o al servicio externo, no confíes en que la descripción de la herramienta sea suficiente control.

Un riesgo adicional que pocas implementaciones contemplan: prompt injection. Un input malicioso puede manipular al agente para que use herramientas fuera del flujo previsto, por ejemplo haciendo que una herramienta de búsqueda acabe escribiendo datos si el modelo interpreta una instrucción embebida en los resultados. Valida los inputs antes de pasarlos al modelo y nunca ejecutes herramientas con parámetros que no hayas sanitizado en el backend.

Decisión 4: Los tres tipos de memoria de un agente

Un agente sin memoria trata cada conversación como si fuera la primera. Uno con memoria mal diseñada acumula ruido que degrada su rendimiento. Para entender la diferencia, un ejemplo concreto.

Marta trabaja en operaciones de una empresa de logística y usa un agente para gestionar incidencias de envío.

Memoria de corto plazo (contexto de sesión)

Marta escribe: “El envío ENV-4821 lleva tres días parado en Zaragoza.” El agente recuerda ese dato durante toda la conversación. Cuando Marta luego pregunta “¿cuál es el número de teléfono del transportista?”, el agente sabe a qué envío se refiere sin que ella repita nada.

Este es el contexto de sesión. Vive en la ventana de contexto del modelo (la ventana de contexto es el espacio de “memoria activa” del modelo, el texto que puede leer en un momento dado). Cuando la sesión termina, ese contexto desaparece.

Memoria de largo plazo (historial relevante)

Al día siguiente, Marta abre una nueva sesión. El agente ya no recuerda ENV-4821. Pero cuando Marta lo menciona, el sistema recupera de una base de datos que ese envío ya tuvo una incidencia el mes pasado con el mismo transportista. Eso es largo plazo: información persistente que se guarda entre sesiones y se recupera cuando es relevante.

Conocimiento (RAG sobre documentación)

Marta pregunta: “¿Cuál es el protocolo de empresa para envíos parados más de 72 horas?” El agente no tiene esa respuesta en el contexto ni en el historial de Marta. Pero puede buscarla en la documentación interna usando RAG. RAG, o Retrieval-Augmented Generation, es cuando el agente busca en documentos externos antes de responder, en lugar de inventar la respuesta. El post de RAG empresarial entra en el detalle técnico de cómo construir ese pipeline.

Los tres tipos trabajan juntos. Si eliminas cualquiera de ellos, el agente parece torpe en algún aspecto concreto y previsible.

Decisión 5: Supervisión humana: no todo necesita aprobación

Dos errores opuestos: poner al humano en el loop para absolutamente todo (el agente se convierte en un formulario complicado) o darle autonomía total (y un día modifica algo que no debía). La solución es clasificar las acciones por reversibilidad y riesgo.

Nivel	Tipo de acción	Ejemplos	Mecanismo
Sin supervisión	Reversible, bajo riesgo	Leer datos, generar borradores, buscar información	El agente actúa solo
Confirmación	Impacto moderado, recuperable	Enviar un email, crear un ticket, actualizar preferencias	El agente muestra qué va a hacer y espera confirmación
Aprobación explícita	Irreversible o alto riesgo	Borrar registros, transferencias, cambios en permisos	El agente muestra contexto completo y consecuencias, requiere OK manual

En un agente de gestión de contratos que construí para un cliente, más del 90% de las acciones eran consultas de lectura sin supervisión. Pero cualquier modificación de términos contractuales requería aprobación explícita con el diff completo de lo que iba a cambiar. Esa granularidad evitó varios errores costosos en los primeros meses.

Diseña los tres niveles desde el día uno, aunque en la primera versión la pantalla de “aprobación explícita” sea muy básica.

Decisión 6: Observabilidad desde el primer día

Un agente sin trazabilidad (registro de cada paso del razonamiento y cada herramienta llamada) es imposible de depurar cuando falla. Y va a fallar. No porque el modelo sea malo, sino porque los sistemas reales tienen edge cases (casos límite que los tests no anticipan) que solo aparecen en producción con tráfico real.

Lo mínimo que necesitas instrumentar desde el principio:

• Cada llamada a herramienta: qué herramienta, con qué parámetros, qué devolvió
• Cada respuesta del modelo: cuántos tokens usó, si llamó a herramientas o respondió directamente
• El resultado final de cada conversación: completó la tarea, pidió ayuda humana, o falló con qué error
• El coste en tokens de cada llamada al modelo, para detectar conversaciones que se disparan en consumo antes de que afecten al presupuesto

Sin esa instrumentación, cuando algo falla en producción solo puedes adivinar qué pasó. Una advertencia para entornos empresariales: esos logs pueden contener datos sensibles de clientes. La observabilidad debe cumplir con las políticas de privacidad de datos de tu empresa: redacción de campos sensibles antes de persistir, control de acceso a los logs, y retención acotada en el tiempo. El post de evaluación de agentes en producción detalla qué métricas vigilar y cómo construir evals que detecten regresiones antes de que lleguen a usuarios.

Errores comunes

El objetivo que parece concreto pero no lo es

“El agente gestiona solicitudes de RRHH” parece específico. ¿Qué tipo de solicitudes? ¿Con qué información? ¿Qué hace cuando le falta contexto para responder? La vaguedad en el objetivo se convierte en comportamiento impredecible en producción, y el equipo acaba diciendo que “el agente a veces falla” sin saber por qué.

Herramientas con permisos más amplios de lo necesario

En un sistema que revisé, el agente tenía acceso de escritura a la tabla de usuarios completa cuando solo necesitaba actualizar el campo last_seen. Técnicamente funcionaba. Pero un bug en el prompt o un input inesperado podría haber sobreescrito datos de toda la base. Cada permiso extra que no es necesario es un riesgo que no aporta nada.

Memoria sin política de expiración

Si guardas el transcript completo de todas las conversaciones en el contexto de sesión, eventualmente llenarás la ventana de contexto y el modelo empezará a “olvidar” el inicio de la conversación para hacer sitio a lo nuevo. Define desde el principio qué se guarda en largo plazo y qué se descarta al cerrar la sesión. Los resúmenes comprimidos funcionan mucho mejor que los transcripts completos.

Implementar supervisión humana como “mejora futura”

En un proyecto de agente interno que arrancó sin esa capa, añadirla tres meses después obligó a rediseñar la mitad del flow de conversación porque cada acción ya asumía autonomía completa. Construye los tres niveles desde el primer sprint, aunque la implementación inicial sea básica.

Checklist de arquitectura

Este plano integra las seis decisiones en una sola vista de referencia. Antes de conectar tu agente a cualquier sistema real, verifica:

• El objetivo tiene inputs definidos, outputs verificables y criterios de éxito medibles
• Has decidido agente único o multi-agente con criterio documentado
• Cada herramienta tiene permisos mínimos y validación de parámetros en el schema
• Los tres tipos de memoria están diseñados: qué vive en sesión, qué persiste, qué viene de RAG
• Tienes una tabla de clasificación de acciones por nivel de supervisión
• El sistema registra cada herramienta llamada, cada respuesta y cada resultado
• Los logs redactan campos sensibles, tienen control de acceso y política de retención definida
• Tienes al menos cinco casos de prueba con input y output esperado antes de ir a producción

Preguntas frecuentes

¿Cuándo tiene sentido añadir RAG a un agente y cuándo no?

Añade RAG cuando la documentación sea demasiado extensa para el system prompt o cambie con frecuencia. Si cabe en el system prompt y es estable, úsala directamente ahí: menos latencia, menos complejidad. Criterio rápido: si puedes pegar la documentación en el prompt y sigue siendo manejable, no necesitas RAG todavía. Y si añades RAG en un entorno con datos regulados, asegúrate de filtrar los fragmentos recuperados por permisos del usuario antes de inyectarlos en el contexto: un pipeline RAG sin control de acceso puede surfacear documentos sensibles que el usuario no debería ver.

La memoria de mi agente crece con el tiempo y cada vez usa más tokens. ¿Cómo lo gestiono?

No guardes todo. Define una política de retención: qué información es útil para conversaciones futuras y qué es ruido. Un patrón que funciona bien es guardar resúmenes comprimidos de conversaciones pasadas en lugar del transcript completo. Otro es filtrar por relevancia: antes de inyectar historial en el contexto, recupera solo lo que es relevante para la consulta actual. El post de RAG empresarial explica cómo hacer ese filtrado por similaridad semántica.

Mi agente necesita acceder a un sistema legacy sin API. ¿Qué opciones tengo?

Tienes tres opciones reales, ordenadas de más a menos estable.

La primera: construir un adaptador propio, un servicio que envuelve el sistema legacy y expone una API que tu agente consume. Más trabajo inicial, pero el agente queda desacoplado de los detalles del sistema.

La segunda: si el sistema legacy exporta datos en algún formato (CSV, ficheros planos, exports periódicos), esa suele ser la opción más estable aunque sea más lenta. El agente consume los datos exportados en lugar de integrar directamente.

La tercera: automatización de navegador, donde el agente controla un navegador para interactuar con la interfaz web del sistema. Funciona, pero cualquier cambio en la UI rompe la integración. Úsala como último recurso y con tests de regresión visual para detectar roturas rápido.

¿Cómo versiono el comportamiento de mi agente cuando actualizo el modelo subyacente?

Trata los cambios de modelo como cambios de dependencia: con tests de regresión antes de desplegar. Guarda un conjunto de casos de prueba con inputs y outputs esperados y ejecútalos contra el nuevo modelo antes de actualizarlo en producción. El comportamiento del agente puede cambiar entre versiones de modelo aunque el system prompt sea idéntico, y algunos cambios son sutiles pero tienen impacto real en casos de uso específicos.

¿Cuándo NO usar un agente IA?

Cuando necesitas determinismo total, auditabilidad exacta o coste predecible por operación. Un motor de reglas o un workflow tradicional es más apropiado si la lógica es fija y no cambia con el contexto, si cada decisión debe ser 100% trazable para cumplimiento regulatorio, o si el volumen de operaciones hace que el coste de tokens sea prohibitivo comparado con una automatización simple.

Los agentes añaden valor cuando hay variabilidad en los inputs, cuando la lógica depende del contexto, o cuando necesitas que el sistema se adapte a casos que no puedes anticipar. Si tu problema tiene una respuesta correcta unívoca para cada input, probablemente no necesitas un agente.