Cuándo NO construir un agente de IA (y qué hacer)

Tabla de contenidos

Publicado en agosto de 2026.

TL;DR: La mayoría de las ideas de agentes de IA son la herramienta equivocada para el trabajo. Antes de escribir cualquier código de agente, reviso cinco señales descalificantes — un proceso inestable, baja frecuencia, ninguna prueba de aprobado/reprobado, una herramienta más simple que ya funciona, o un modo de fallo irreversible que no puedo controlar a tiempo. Si alguna de ellas es cierta, no construyo. En su lugar, bajo por una escalera de alternativas más baratas, y solo vuelvo a un agente personalizado si nada en esa escalera funciona.

[Perspectiva del operador] Gestiono más de 30 agentes en producción entre una marca de consultoría y Pickleland, una instalación de pickleball en Pflugerville, TX. He eliminado al menos tantas ideas de agentes como las que he lanzado, y casi ninguna murió porque la idea fuera mala — murieron porque un agente era la herramienta equivocada para ese trabajo en particular. Este post es el filtro que aplico antes de que “¿debería construir esto?” se convierta en “¿cómo lo construyo?”.

La respuesta por defecto es no

El marco de ROI que uso te dice si una automatización recupera su costo de construcción y mantenimiento. Esa es la segunda pregunta correcta. La primera pregunta es más simple y se salta constantemente: ¿esto necesita ser un agente siquiera?

“Agente” se ha convertido en la etiqueta por defecto para cualquier cosa que involucre un LLM, igual que “app” se convirtió en la etiqueta por defecto para cualquier cosa que involucrara una pantalla hace quince años. No todo lo que toca un modelo necesita un sistema permanente, autónomo, que llama herramientas, vigilando disparadores y tomando acciones por sí solo. Gran parte de lo que la gente llama “construir un agente” es en realidad “escribir un prompt realmente bueno y ejecutarlo a mano”, y eso no es un modo de fallo — a menudo es el estado final correcto.

Trato “construir un agente personalizado” como la opción más cara en una escalera de opciones, no como el primer peldaño. Antes de recurrir a ella, reviso si la tarea se descalifica por sí sola.

Cinco señales de que un agente es la herramienta equivocada

Cualquiera de estas, por sí sola, suele ser suficiente para detenerme.

1. El proceso todavía no es estable. Si el flujo de trabajo ha cambiado dos veces en el último mes porque el negocio mismo todavía está descubriendo qué quiere, un agente fija la versión de hoy de un proceso que está a punto de cambiar de nuevo. Reescribirás el prompt, el esquema de herramientas y el conjunto de evaluación cada vez que el proceso cambie — lo que significa que estás manteniendo un agente en vez de dirigir un negocio. Ejecútalo manualmente hasta que se mantenga estable durante un trimestre, y luego automatiza la versión ya asentada.

2. Ocurre con demasiada poca frecuencia para amortizarse. Una tarea que sucede dos veces al año no acumula suficientes ejecuciones para justificar el tiempo de construcción, el tiempo de pruebas y un conjunto de evaluación, sin importar qué tan bien funcionaría una vez construida. Baja frecuencia con alto esfuerzo de construcción es casi el peor cuadrante para la automatización — pagas el costo completo de construcción y recoges casi ningún ahorro.

3. No puedes escribir una prueba de aprobado/reprobado para ella. Si no puedes describir de antemano, con suficiente precisión para verificarlo de forma programática, cómo se ve una salida correcta, no puedes construir un arnés de evaluación para ella — y un agente que no puedes evaluar es un agente sobre el que estás volando a ciegas. Las tareas de puro gusto (“¿esto suena como yo?”) o de puro criterio sin una rúbrica consistente detrás se quedan manuales, o se quedan revisadas por un humano cada vez, lo que anula el propósito de automatizarlas.

4. Una herramienta más simple ya hace el trabajo. Antes de definir el alcance de un agente, pregúntate qué te daría una fórmula de hoja de cálculo, un flujo de trabajo de Zapier/Make/n8n con un solo paso de LLM, o un prompt guardado. Si la respuesta honesta es “90% del camino”, el último 10% rara vez justifica levantar un agente con su propia infraestructura, monitoreo e impuesto de mantenimiento. He definido el alcance de agentes para tareas que una vista filtrada y un recordatorio recurrente de calendario habrían resuelto igual de bien.

5. El modo de fallo es irreversible y no tienes tiempo para construir el filtro de aprobación correctamente. Algunas acciones — un envío masivo de correos, un reembolso, una publicación pública — no se pueden deshacer. Los filtros de aprobación humana existen exactamente para esto, pero un filtro apresurado que en realidad nadie revisa es peor que ninguna automatización: crea la apariencia de supervisión sin la sustancia. Si no tienes tiempo para construir y dotar de personal correctamente el filtro, eso es una señal para ir más despacio, no una razón para saltártelo.

Si ninguna de las cinco aplica — el proceso es estable, ocurre con suficiente frecuencia, puedes definir qué es correcto, ninguna herramienta más simple lo cubre, y el modo de fallo es reversible o está bien controlado — entonces vale la pena aplicarle las matemáticas de ROI.

La escalera que subo antes de construir

Cuando una tarea falla en una de las cinco verificaciones — o incluso antes de llegar tan lejos — bajo por esta lista en orden, y me detengo en el primer peldaño que realmente resuelve el problema.

1. Pregúntale al modelo directamente. Sin envoltorio, sin llamadas a herramientas, sin infraestructura permanente. Abre Claude, pega el contexto, haz la pregunta, usa la respuesta. Esto resuelve más tareas puntuales y ocasionales de lo que la gente espera, porque el instinto de “agente” aparece incluso para cosas que solo necesitan pasar una vez.

2. Un prompt guardado o instrucciones de proyecto. Si el mismo tipo de solicitud aparece repetidamente pero cada instancia todavía necesita que un humano reúna las entradas y revise la salida, guarda el prompt como una plantilla — instrucciones de proyecto, un conjunto de instrucciones personalizado, un fragmento — en vez de automatizar el disparador. Obtienes el beneficio de consistencia de un agente sin la infraestructura.

3. Una herramienta de automatización no-code con un solo paso de LLM. Para tareas que genuinamente necesitan un disparador (un nuevo envío de formulario, una nueva fila en una hoja de cálculo) pero cuya lógica en sí es simple, una herramienta de flujo de trabajo con una llamada al modelo en medio es dramáticamente más barata de construir y mantener que código personalizado. Recurro a esto antes que a infraestructura personalizada siempre que el disparador sea estándar y el volumen sea bajo a moderado.

4. Una plantilla ejecutada manualmente. Algunos procesos se benefician más de una lista de verificación que de la automatización, porque el valor está en que un humano piense cada paso, no en la velocidad. No automatices el pensamiento en tareas donde el pensamiento es el punto.

5. Subcontratación. Para cualquier cosa con ambigüedad o criterio real donde no tienes tiempo para construir y mantener un conjunto de evaluación, una persona — un asistente virtual, un especialista, un proveedor de servicio productizado — suele ser más rápida de poner en marcha y más fácil de corregir a mitad de camino que un agente que todavía estás ajustando.

6. Solo entonces: un agente personalizado. Si has bajado por la escalera y nada en ella se sostiene — el disparador necesita criterio real bajo carga, el volumen es demasiado alto para el manejo manual o subcontratado, y pasa las matemáticas de ROI — es entonces cuando un agente construido a medida con su propia pila de confiabilidad se gana su costo de construcción.

La prueba sombra de dos semanas

Para cualquier cosa que esté en el límite — pasa las cinco verificaciones pero todavía no tengo confianza — ejecuto una prueba sombra de dos semanas antes de comprometerme a construir. Hago la tarea yo mismo, usando el modelo como copiloto en vez de como sistema autónomo: el mismo prompt que eventualmente le daría al agente, las mismas entradas, pero leo cada salida antes de que vaya a cualquier parte.

De esa prueba salen dos cosas. Primero, si el modelo realmente es bueno en la tarea al nivel de calidad que necesito — si estoy reescribiendo a mano la mitad de su salida, la tarea no está lista para automatizarse sin importar todo lo demás. Segundo, un conjunto de evaluación real: dos semanas de entradas y las salidas que juzgué correctas son exactamente lo que necesita un arnés de evaluación, y normalmente ya lo he recolectado gratis para cuando decido construir.

La prueba sombra también saca a la luz los casos extremos antes de que estén en producción. Es mucho más barato descubrir durante una prueba manual que el 15% de las entradas necesita un manejo especial que descubrirlo por la queja de un cliente después de que el agente se lanzó.

Una regla que aplico después de matar una idea

Matar una idea de agente no es lo mismo que matar el problema subyacente. Si una tarea se descalifica por ahora — el proceso todavía está cambiando, el volumen es demasiado bajo — anoto por qué y fijo un punto aproximado de reevaluación (normalmente ligado a un disparador específico: “reevaluar cuando las reservas superen 50 por semana”, no solo una fecha). Las ideas de agentes que se matan una vez y nunca se revisan se convierten silenciosamente en trabajo manual permanente que nadie recuerda haber evaluado dos veces.

La disciplina inversa importa igual de mucho: una idea que pasa las cinco verificaciones y las matemáticas de ROI no se construye automáticamente hoy. Entra en la misma cola que todo lo demás, clasificada frente a las automatizaciones que ya demostraron que se amortizan. Pasar el filtro le gana a una tarea un lugar en la fila, no una exención de la priorización.

Preguntas frecuentes

¿No es esto simplemente un argumento en contra de la automatización?

No — es un argumento en contra de recurrir por defecto a la forma más cara de automatización. La mayoría de las alternativas en la escalera de arriba siguen siendo automatización; solo son más ligeras. Gestiono docenas de agentes en producción. El punto no es evitar construir; es dejar de saltar directo a “construir un agente personalizado” cuando un prompt guardado o un flujo de trabajo no-code te da el mismo resultado por una fracción del costo de construcción y mantenimiento.

¿Qué pasa si la tarea claramente va a crecer en volumen más adelante?

Esa es una razón legítima para construir por adelantado a los números actuales — cubro esta excepción en el marco de ROI. Sin embargo, no anula las cinco señales de arriba. Si el proceso todavía es inestable o todavía no puedes definir una salida correcta, un volumen creciente solo significa que mantendrás un agente roto a mayor escala. Arregla primero la inestabilidad y la capacidad de evaluación; la escala es una razón para construir más pronto una vez que esas cosas están resueltas, no una razón para saltárselas.

¿Cómo sé si un paso de una herramienta no-code es “suficientemente bueno” o si necesito código personalizado?

Pruébalo primero y mídelo contra tu conjunto de evaluación, aunque sea informal. Los pasos de LLM no-code manejan bien tareas de un solo propósito y una sola entrada. Empiezan a tensarse cuando necesitas uso de herramientas en varios pasos, estado persistente entre ejecuciones, o lógica condicional que el constructor de la herramienta no puede expresar con claridad. Si chocas con ese muro, esa es una señal real para pasar a infraestructura personalizada — no una razón para empezar ahí.

¿Esto aplica diferente a las herramientas internas que a las orientadas al cliente?

Las cinco señales aplican de la misma manera, pero lo que está en juego es distinto. Una herramienta interna con un proceso inestable solo desperdicia el tiempo de tu propio equipo cuando falla. Una orientada al cliente con un proceso inestable erosiona la confianza de personas que no se apuntaron para ser tu conjunto de evaluación. Aplico una versión más estricta de la señal cinco en particular a las automatizaciones orientadas al cliente — la barra para “bien controlado” es más alta cuando quien está del otro lado de un error es un desconocido, no un colega.

¿Cuál es la razón más común por la que matas una idea de agente?

La señal tres — ninguna prueba clara de aprobado/reprobado. Es la más fácil de pasar por alto al definir el alcance, porque la tarea se siente bien definida hasta que intentas anotar de antemano cómo se ve realmente una salida correcta. Si no puedo hacer eso en una o dos frases, sé que el agente va a ser inevaluable, lo que significa inmejorable, lo que significa que todavía no se construye.