Qué diferencia a un agente de un chatbot, qué trabajo tiene sentido delegarle y cómo mantener el control.
Contenidos
1. Qué no es un agente de IA
Un chatbot, por sí solo, responde. Un script, un programa con instrucciones predefinidas, ejecuta unas reglas. Un agente de IA recibe un objetivo, decide los pasos, utiliza herramientas, verifica el resultado y se detiene o pregunta cuando no puede seguir.
La diferencia no está en que escriba mejor. Está en que puede avanzar sobre una tarea y comprobar qué ha ocurrido después de actuar.
Eso no significa que deba tener la última palabra. En Èmfasi, nuestro agente de desarrollo puede preparar una solución, pero no dar por cerrada la tarea.
Mi regla es esta: «el bot propone y yo decido». Delego parte de la ejecución, no la responsabilidad sobre el resultado.
En Qué es una agencia AI-first y qué debería aportar realmente a un cliente expliqué el enfoque general. Aquí quiero concretar qué hay detrás de un agente y qué condiciones pongo antes de dejarlo trabajar.
2. Las cuatro piezas y un recorrido real
Para entender cómo funciona un agente, separo cuatro piezas:
Modelo: interpreta el objetivo y razona sobre el siguiente paso.
Herramientas: permiten actuar. Pueden ser APIs, conexiones entre aplicaciones; servidores MCP, un mecanismo para ofrecer herramientas al modelo; terminal, para ejecutar comandos; o navegador.
Memoria o contexto: documentación, tareas e historial necesarios para trabajar.
Bucle de control: observa, decide, actúa, verifica y repite dentro de sus límites.
En nuestro flujo de desarrollo, el recorrido empieza con una tarea. El agente crea una rama, una línea de trabajo separada del código principal, y escribe los cambios.
Después ejecuta el build, el proceso que construye la web y comprueba que puede generarse. Prueba el resultado en un navegador y prepara una pull request, una propuesta de cambios para revisión, con una captura y una vista previa.
Una persona revisa el trabajo y decide si puede cerrarse la tarea.
Si falla el build, el trabajo queda bloqueado aunque el agente afirme que ha terminado. También hay un límite de intentos: no puede encadenar correcciones indefinidamente.
El modelo propone pasos, pero las comprobaciones determinan si el trabajo puede avanzar. Una afirmación del agente no sustituye una prueba.
3. Para qué sirven de verdad
La primera pregunta no es qué puede hacer la IA, sino qué merece la pena automatizar.
Miro cuatro señales: frecuencia, fricción, riesgo de error y coste de revisión. Busco tareas repetidas, pasos que dificultan el trabajo, errores evitables y resultados que puedan revisarse sin rehacer todo desde cero.
En nuestro caso, las comprobaciones periódicas de las webs han permitido detectar problemas de medición. La utilidad está en encontrar algo que necesita atención, no en producir un informe porque ahora sea fácil generarlo.
También hay tres razones para frenar: un proceso inestable, información de entrada poco fiable o un resultado que nadie pueda comprobar.
Desarrollé estos criterios en Qué procesos automatizar primero con IA y cuáles no. Añadir un agente no cambia la pregunta de fondo: qué trabajo merece delegarse y quién podrá verificarlo.
Si no sé cómo distinguir un resultado correcto de uno incorrecto, todavía no tengo una tarea bien definida para un agente.
4. Para lo exacto, código. Para interpretar, un modelo
Haber construido agentes no me ha llevado a poner un modelo en cada decisión.
Para lo exacto utilizo reglas deterministas: ante las mismas condiciones, el código toma la misma decisión. Reservo el LLM, o modelo de lenguaje, para lo que necesita interpretación.
Un ejemplo es nuestro sistema de primera respuesta ante incidencias web. Confirma el problema, realiza comprobaciones externas, crea una tarea y avisa. Las decisiones siguen reglas escritas en código. El modelo solo redacta el aviso.
En ese flujo, el modelo no tiene herramientas para actuar: decide el código. Redactar un mensaje no le da permiso para ejecutar acciones.
En otro sistema, dedicado a comprobar la salud de las webs, las verificaciones funcionan sin consultar ningún modelo. No necesitan interpretar una petición: necesitan aplicar unas condiciones y señalar desviaciones.
Esto obliga a distinguir entre un agente de IA y una automatización convencional. No todo lo que automatizamos es un agente, ni necesita serlo.
Mi criterio no es añadir inteligencia artificial a todos los pasos. Es asignarle una función concreta. Si las reglas ya resuelven una comprobación, no introduzco un modelo para que vuelva a decidir lo mismo. Si necesito interpretar información o redactar una explicación, entonces valoro su intervención.
5. Límites por diseño, no por instrucciones
No baso la seguridad en un prompt, las instrucciones que recibe el modelo. Pedirle que no haga algo no equivale a impedir que pueda hacerlo.
Aplico el mínimo privilegio: cada agente dispone únicamente de los accesos y operaciones necesarios para su función. No recibe acceso general a la infraestructura por el hecho de necesitar una herramienta concreta.
También debe quedar rastro de sus acciones y existir una forma de detener su ejecución. Los límites no pueden depender de que el modelo recuerde obedecerlos.
En desarrollo, preparar una propuesta no significa poder incorporarla al código principal. Y cerrar una tarea sigue siendo una decisión humana.
Un ejemplo doméstico ayuda a entender la diferencia: consultar el consumo de una lavadora no es lo mismo que apagarla. La lectura puede estar permitida, mientras que la acción debe pasar por un control adicional con salvaguardas. Leer y actuar no tienen por qué compartir permiso.
Lo que delimita a un agente no es solo el objetivo que recibe. También son las acciones que el sistema le permite realizar para alcanzarlo.
6. Primero en sombra, con una salida medible
Antes de incorporarlo al trabajo habitual, cada agente funciona en modo sombra: trabaja, pero su resultado solo lo ve el responsable.
No doy por superada esa fase porque una demostración salga bien. Fijo de antemano un criterio medible, como un porcentaje mínimo de propuestas aceptadas o un periodo sin falsas alertas críticas.
El porcentaje o el periodo tienen que quedar escritos antes de evaluar. Así evito decidir después que el resultado ya parece suficiente.
Pero hay una lección anterior: medir antes de especificar.
Al preparar un agente para revisar la calidad de las tareas, contrastamos nuestras premisas con el historial real. Varias no se sostenían.
No era un problema del modelo ni de sus instrucciones. Era un problema de cómo habíamos definido la necesidad que queríamos resolver.
Por eso separo dos comprobaciones: primero, si el problema es realmente como creemos; después, si el sistema se comporta como necesitamos.
El modo sombra sirve para evaluar el funcionamiento. No sustituye el análisis previo. Un agente diseñado sobre premisas no verificadas genera ruido con mucha eficiencia.
7. El coste no termina al generar un resultado
En el agente de desarrollo separo el coste de producir código del coste de verificarlo. Son partes distintas del trabajo y ambas cuentan.
A eso se añade la revisión humana. Una propuesta barata de generar no implica que la tarea completa haya salido barata.
También distingo el consumo del modelo del resto de costes. Una automatización determinista puede funcionar sin consumir tokens, las unidades de texto que procesa un modelo. Eso no elimina su ejecución, mantenimiento o supervisión.
Hay decisiones de ahorro que tienen poco que ver con hacer al agente más sofisticado. Valoro una suscripción frente al pago por uso mediante una API cuando el volumen lo permite.
Y prefiero un cron del sistema, un programador que inicia tareas a horas fijadas, antes que mantener un agente activo esperando a que llegue el momento de trabajar.
No me interesa únicamente cuánto cuesta generar una respuesta. Me interesa cuánto cuesta llegar a un resultado que alguien pueda revisar y aceptar. En nuestro flujo de desarrollo, el cálculo no termina cuando aparece el código.
8. El trabajo se mueve a revisar y decidir
La IA abarata producir. No abarata decidir ni verificar.
Si producimos el doble con la misma tasa de error, tenemos el doble de errores. Por eso no me sirve medir el avance únicamente por la cantidad de trabajo generado.
En nuestro flujo de desarrollo, una propuesta no se convierte en trabajo terminado porque el agente lo diga. Tiene que pasar las comprobaciones y la revisión de una persona.
Eso cambia dónde ponemos el esfuerzo. Generar código deja de ser el único trabajo visible. Leerlo, probarlo y decidir si resuelve la tarea siguen formando parte de la entrega.
En Èmfasi, el estándar interno es de revisión, no de «más agentes». El autor responde del código, lo haya escrito él o la IA.
Delegar la escritura no permite delegar también esa responsabilidad. El trabajo puede empezar con una propuesta del agente, pero termina con alguien que la entiende y responde por ella.
Si no lo has leído y probado, no está hecho.
