En los últimos seis meses el discurso sobre agentes de IA ha pasado por una fase interesante. A finales de 2024 todavía era casi todo demo llamativa: un agente navegando por una web, otro escribiendo un email, otro reservando un vuelo. Entre enero y marzo de 2025 el cambio se ha notado: OpenAI publicó el Agents SDK y la Responses API en su evento de marzo, Anthropic consolidó Computer Use y extendió el Model Context Protocol, Google avanzó con Gemini 2.0 y la integración con sus herramientas. La infraestructura para montar un agente serio existe. La pregunta ya no es si es posible; es si compensa y, sobre todo, cómo se mide.
Este post es una reflexión sobre cómo se hace ese salto en empresa, qué casos he visto que devuelvan valor real, y qué patrones de fracaso se repiten cuando el equipo intenta llevar un agente a producción sin pasos intermedios.
Por qué este momento es distinto
Durante 2024 los agentes que se publicaban eran en su mayoría construcciones artesanales sobre un modelo potente y un puñado de librerías abiertas (LangGraph, AutoGen, CrewAI). La experiencia de usar ese stack era frustrante: herramientas a medio pulir, patrones inestables, trazabilidad pobre. El primer trimestre de 2025 ha traído tres cambios concretos.
El primero es que los proveedores ofrecen primitivas pensadas para agentes. El Agents SDK de OpenAI, el Model Context Protocol de Anthropic, las Function Calling extensions de Google. Esto baja el coste de integración de semanas a días y, sobre todo, reduce los bordes afilados donde antes se perdían horas depurando.
El segundo cambio es que los modelos han mejorado en la parte más difícil del problema: la ejecución fiable de secuencias largas. Claude 3.7 Sonnet y GPT-4o, con sus variantes de razonamiento, completan secuencias de doce o quince pasos con menos desvíos que los modelos de hace seis meses. No es perfecto, pero es suficientemente fiable para construir casos de uso no triviales.
El tercero es la normalización de la capa de herramientas. MCP se está convirtiendo en un estándar de facto, con servidores para bases de datos, sistemas de archivos, APIs internas, sistemas de ticketing. Eso significa que integrar un agente con el stack corporativo deja de ser un proyecto de consultoría.
Los casos donde hoy compensan de verdad
No todos los problemas de empresa son candidatos a agente. Los que he visto devolver valor medible entran en tres patrones claros.
El primero es el triaje inicial de entradas no estructuradas. Correos de soporte, formularios internos, notificaciones de alertas. Un agente que lee la entrada, la clasifica, decide a qué equipo mandarla, y enriquece el ticket con contexto relevante de la wiki o del historial. Este patrón funciona porque el agente opera sobre una unidad bien definida (un ticket), con una salida estructurada y verificable (una clasificación y unos campos). El valor se mide en tiempo ahorrado por agente humano y en tasa de reclasificación.
El segundo patrón es el análisis de reportes recurrentes. Informes semanales que antes alguien compilaba a mano agregando datos de tres sistemas, ahora los construye un agente. Aquí la clave es que el agente tiene acceso de lectura a los sistemas relevantes vía MCP o APIs directas, y el formato del reporte está acotado. El valor se mide en horas ahorradas por semana y, no menos importante, en consistencia del formato.
El tercer patrón es el asistente técnico interno. Un agente que sabe responder preguntas sobre la propia infraestructura usando documentación interna, runbooks y acceso de solo lectura a herramientas de observabilidad. Aquí el valor se mide en reducción de interrupciones al equipo de plataforma y en el tiempo medio de resolución de incidencias menores.
Lo que estos tres tienen en común es que el agente opera dentro de un perímetro acotado, con acceso de lectura principalmente, y la salida es verificable por un humano antes de actuar sobre algo crítico. Ese patrón (agente como acelerador, no como decisor autónomo) es el que ha pasado de demo a producción con más éxito en los equipos que conozco.
Los patrones de fracaso más frecuentes
El camino está sembrado de proyectos que se quedaron a medias. Los modos de fallo que he visto repetirse son consistentes.
El primero es confundir demo con producto. Alguien hace un prototipo que impresiona, el cliente interno pide llevarlo a producción ya, y el equipo descubre que la demo funcionaba en un entorno controlado con dos casos de ejemplo. Las cien variantes reales rompen el agente y el proyecto pierde credibilidad. La lección es que una demo en agentes es todavía más engañosa que una demo en software tradicional, porque el modelo parece genérico.
El segundo es subestimar el coste de observabilidad. Un agente ejecutando veinte herramientas en una sesión genera un volumen de trazas importante, y sin observabilidad seria (idealmente con estándar OpenTelemetry y un sistema que soporte trazas anidadas) es imposible depurar por qué un caso fue mal. Sin ese instrumental, los fallos se convierten en anécdotas irreproducibles.
El tercero es dar al agente acceso de escritura demasiado pronto. Un agente que solo lee es difícil de romper de forma grave. Un agente que modifica tickets, envía correos o edita documentos puede causar daño acumulativo antes de que nadie se dé cuenta. El camino sano es separar claramente lectura de escritura, empezar en solo lectura, y añadir acciones una por una con validación humana previa.
El cuarto es no definir qué es éxito. Un agente sin métrica clara se vuelve inmune a la crítica porque nadie puede demostrar que no funciona. He visto proyectos correr durante meses sin ningún KPI concreto, solo con la sensación de que «estaba ayudando». La métrica no tiene que ser sofisticada, pero tiene que existir antes del primer despliegue.
Cómo diseñar el primer agente interno
Si tuviera que empezar hoy un agente en una empresa que no tiene experiencia previa, iría por un camino muy conservador.
Primero, elegiría un caso donde la entrada esté bien definida y la salida sea verificable. Nada de agentes que deciden cosas ambiguas; mejor un agente que clasifica, enriquece o compila. La calidad de la primera experiencia marca la aceptación del resto.
Segundo, usaría el entorno oficial del proveedor (Agents SDK si usas OpenAI, Claude Agent SDK si usas Anthropic, similar para Google) en lugar de orquestar con librerías de terceros. Los entornos abiertos son potentes pero su coste de mantenimiento es alto y el equipo interno no suele tenerlo. La reducción de fricción con los primeros compensa muchas veces la menor flexibilidad.
Tercero, introduciría observabilidad desde el primer commit: registro estructurado de cada paso del agente, grabación de los prompts completos, trazas con identificador de sesión. No más tarde; desde el principio. Sin esto, no se puede mejorar el agente.
Cuarto, validaría con un piloto acotado. Diez usuarios internos, durante dos o tres semanas, con un canal directo para reportar fallos. Un piloto pequeño revela errores que ningún test sintético detecta. Y pasado el piloto, haría el pase a producción por fases, con la posibilidad clara de deshacer si algo va mal.
El coste operativo es la sorpresa más grande
Un tema que no se discute bastante: los agentes son caros de operar. Una conversación de soporte que un humano resuelve con diez consultas a los sistemas internos puede convertirse, bajo un agente, en cuarenta llamadas al LLM con miles de tokens cada una. La factura mensual se dispara rápido.
La mitigación pasa por tres caminos. Uno, elegir el modelo más barato que resuelva el caso con calidad suficiente. Claude 3.5 Haiku y GPT-4o mini son opciones razonables para muchos casos y cuestan una fracción de las variantes premium. Dos, instrumentar el coste por sesión desde el principio para detectar cuáles son las interacciones caras y optimizarlas. Tres, meter caché de respuestas cuando la interacción es consultable.
Sin atender estos tres puntos, un agente exitoso en pequeña escala se vuelve insostenible al escalar. Y esto es lo más fácil de pasar por alto cuando el piloto va bien y se decide producción.
Cómo pensar la decisión
Mi lectura, después de ver muchos intentos de agentes en empresa en los últimos meses, es que el salto de demo a valor medible se gana con disciplina más que con novedad. Las tres preguntas que marcan si un proyecto va a sobrevivir son simples: ¿qué métrica va a mover?, ¿quién va a convivir con los fallos?, ¿cómo se va a medir el coste operativo?
Si se pueden responder antes de empezar, el agente tiene muchas probabilidades de llegar a producción y aportar. Si las respuestas son «ya veremos», el proyecto seguramente se convierta en otro prototipo que impresionó en una demo y no llegó a nada.
Para quien está pensando en qué caso elegir ahora, mi recomendación es buscar el aburrido. El triaje de tickets, el asistente de wiki interna, el compilador de reportes semanales no son casos llamativos, pero mueven métricas reales de forma medible. Lo llamativo se reserva para cuando el equipo ya tiene experiencia cuidando un agente en producción. Y esa experiencia se gana solo haciendo.
