Diseñamos agentes de IA para procesos donde no todos los casos siguen la misma ruta: triaje de correo, documentación, soporte, CRM/ERP o tareas que necesitan consultar contexto y elegir entre varias herramientas. El agente actúa dentro de límites definidos de permisos, memoria, estados, aprobaciones y coste; la autonomía sólo se amplía cuando los casos reales demuestran que compensa.
La diferencia importante no es que “razone”, sino que puede escoger acciones dentro de un espacio de decisión. Cuanto mayor sea ese espacio, más explícitos deben ser permisos, estado, evaluación y fallback.
Un agente de IA es un sistema que recibe un objetivo o un evento, interpreta el contexto disponible, decide qué acción o herramienta utilizar y continúa hasta alcanzar un estado de salida o pedir intervención. Puede consultar una base de conocimiento, leer un CRM, preparar un documento, llamar a una API, crear una tarea o dejar una respuesta pendiente de aprobación.
La palabra importante es decidir entre acciones permitidas. Un chatbot que sólo responde texto no necesita ser un agente. Y una automatización que siempre ejecuta los mismos cinco pasos tampoco. Reservamos la arquitectura agéntica para situaciones donde existe variabilidad suficiente para justificar esa capacidad de elección.
Chatbot o asistente: conversa y puede recuperar información, pero no necesariamente modifica sistemas.
Workflow automatizado: sigue una secuencia diseñada de antemano. Puede usar IA en pasos concretos, pero la ruta general está controlada por el flujo.
Agente: dispone de un conjunto de herramientas y decide cuál utilizar o qué siguiente paso intentar según el caso. Esa flexibilidad es útil cuando no todas las entradas siguen la misma ruta.
En producción solemos combinar los tres patrones. El error es convertir cualquier automatización en “agente” y pagar con más coste, latencia y superficie de fallo una autonomía que el proceso no necesitaba.
1. Objetivo y condición de salida. Qué intenta conseguir y cuándo debe considerar terminada la tarea.
2. Contexto. Qué información recibe al empezar y qué conocimiento puede recuperar después.
3. Herramientas. APIs, funciones, búsquedas o acciones concretas disponibles mediante tool calling.
4. Estado y memoria. Qué necesita recordar dentro de una ejecución, entre pasos o entre interacciones distintas. No toda “memoria” debe persistir.
5. Políticas y permisos. Qué puede leer, proponer, escribir o ejecutar; límites de gasto, volumen y acciones sensibles.
6. Observabilidad y evaluación. Cómo reconstruimos la secuencia, qué herramientas utilizó, qué resultado produjo y dónde falló.
Una herramienta debería tener un contrato estrecho. Es preferible exponer “crear borrador de oportunidad con estos campos” que dar acceso indiscriminado a una base de datos. Cuanto más específica es una acción, más fácil resulta validar parámetros, aplicar permisos y evitar que una mala interpretación produzca una modificación excesiva.
Las herramientas pueden exponerse mediante APIs, funciones internas o protocolos como MCP cuando encajan con la arquitectura. La decisión no cambia el principio: el agente recibe capacidades concretas, no acceso general al negocio.
Para profundizar en esta capa mantenemos contenidos propios sobre tool calling y MCP frente a API.
En un agente empresarial distinguimos contexto de la tarea, estado operativo y memoria persistente. El contexto contiene la información necesaria para resolver el caso actual. El estado registra qué pasos ya ocurrieron y qué queda pendiente. La memoria persistente sólo se utiliza cuando existe una razón de producto y una política clara sobre qué conservar.
Guardar indiscriminadamente conversaciones o datos “por si acaso” aumenta ruido, coste y riesgo. Preferimos recuperar información desde sistemas autoritativos cuando sea posible y persistir únicamente aquello que tenga una función concreta.
No existe sólo “autónomo” o “con humano”. Podemos diseñar niveles: el agente consulta y propone; prepara una acción que alguien aprueba; ejecuta automáticamente acciones reversibles de bajo riesgo; o actúa de forma más amplia únicamente cuando supera determinadas validaciones.
La autonomía puede variar incluso dentro del mismo agente. Consultar información puede ser libre; modificar un registro puede requerir validación; enviar una comunicación contractual puede quedar siempre fuera de su perímetro. Esa granularidad es más útil que prometer un empleado digital que trabaja sin supervisión.
Evaluar sólo la respuesta final oculta muchos fallos. También comprobamos selección de herramienta, parámetros, orden de acciones, número de pasos, capacidad de detenerse, recuperación ante errores y escalado a una persona.
Construimos casos normales, ambiguos y adversos. Registramos trazas suficientes para saber por qué una ejecución llegó a determinado resultado y comparamos versiones cuando cambian prompts, modelos o herramientas. En agentes, una pequeña mejora en razonamiento puede quedar anulada si aumenta demasiado la cantidad de llamadas o introduce caminos imprevisibles.
Una implementación fiable mezcla piezas distintas: software determinista para reglas previsibles, modelos cuando el lenguaje o la ambigüedad importan, recuperación de conocimiento cuando la respuesta debe apoyarse en fuentes y supervisión humana cuando el coste del error exige criterio. El objetivo no es maximizar la cantidad de IA, sino diseñar el sistema que mejor resuelve el trabajo.
Seleccionamos intersecciones donde cambia de verdad el perímetro del agente: herramientas disponibles, datos, acciones sensibles y necesidad de supervisión.
Soporte técnico, documentación y operaciones B2B pueden admitir agentes que consulten contexto y preparen acciones; las modificaciones sobre sistemas operativos requieren un perímetro mucho más estricto.
Atención y operaciones con separación estricta entre información, gestión y cualquier decisión que requiera criterio clínico o supervisión de una persona.
Incidencias, correo, documentación y coordinación multi-sistema son buenos terrenos para agentes acotados que sepan consultar estado y escalar excepciones.
Investigación, expedientes, borradores y seguimiento permiten agentes que combinen conocimiento y herramientas, manteniendo aprobación en entregables sensibles.
Agentes dentro de producto, soporte u operaciones con tool calling sobre APIs propias, estados claros y evaluación de regresiones antes de ampliar autonomía.
Consulta de catálogo, pedidos, CRM y ERP con herramientas muy específicas para que una interpretación probabilística no sustituya reglas transaccionales.
Las preguntas que separan un agente útil de una demo que simplemente llama a varias APIs.
Es un sistema que recibe un objetivo o evento, utiliza contexto y puede elegir entre un conjunto de herramientas para ejecutar pasos hasta alcanzar una salida o pedir intervención. La diferencia frente a una automatización fija es que parte de la ruta se decide según el caso. En empresa esa libertad debe estar limitada por permisos, condiciones de parada, presupuesto y reglas de escalado.
Un chatbot puede limitarse a conversar o responder con conocimiento. Un agente, además, puede utilizar herramientas y modificar el estado de un proceso: consultar un pedido, crear una tarea, preparar un registro o invocar una API. Un asistente conversacional con RAG no necesita llamarse agente si no existe ese componente de acción.
Una automatización puede seguir una ruta definida y usar IA en pasos concretos. Un agente decide parte de esa ruta: qué herramienta usar, qué información buscar o qué siguiente paso ejecutar. Si la secuencia puede definirse de antemano, preferimos el workflow porque es más fácil de probar, observar y mantener.
Sí, siempre que exista una interfaz técnica razonable. Diseñamos herramientas específicas sobre APIs, webhooks, bases de datos o capas internas y damos al agente únicamente las operaciones necesarias. Para acciones de escritura definimos validaciones, idempotencia, permisos y qué ocurre si la integración falla.
No siempre. Normalmente necesita estado de la tarea actual y contexto suficiente para decidir. La memoria persistente sólo tiene sentido si existe una necesidad clara entre sesiones o casos. Cuando la información ya vive en CRM, ERP o una base de conocimiento, suele ser mejor recuperarla desde su fuente autoritativa que duplicarla en una memoria opaca.
Sí en acciones acotadas, reversibles y suficientemente evaluadas. Otras pueden quedar en modo propuesta, exigir aprobación antes de ejecutar o escalar automáticamente si hay baja confianza, información insuficiente o una excepción. Diseñamos autonomía por acción, no con un único interruptor para todo el agente.
No hay ventaja automática en multiplicar agentes. Un único workflow con herramientas bien definidas suele ser más fácil de probar. Separamos agentes cuando existen responsabilidades realmente distintas, contextos incompatibles, permisos diferentes o coordinación que justifique la complejidad. “Multiagente” no es un objetivo arquitectónico por sí mismo.
Depende del número de herramientas, sistemas, estados, fuentes, requisitos de evaluación y autonomía. El coste operativo también depende de cuántos pasos y llamadas realiza por tarea. Antes de presupuestar necesitamos delimitar objetivo, herramientas y condiciones de salida; una demo conversacional y un agente que escribe en sistemas de negocio no tienen el mismo alcance.
Separar capacidades evita vender agentic AI para todo. Estas páginas cubren los componentes que pueden rodear al agente.
Cuéntanos qué objetivo tiene el proceso, qué herramientas usa hoy una persona y qué cambia entre un caso y otro. Podemos determinar si hace falta un agente, un workflow con IA o una automatización determinista más simple.