Apuesto mi empresa a los agentes proactivos

Los agentes pueden hacer casi cualquier cosa que les pidas, y ese es el problema: todavía tienes que pedirlo.

No dejo de oír a gente llamar a los agentes “compañeros digitales”. Ese marco es erróneo. Un compañero que se queda callado hasta que le entregas una tarea perfectamente acotada, la completa y vuelve a esperar, no es un compañero. Todos los agentes que has usado funcionan exactamente así. Los modelos se volvieron más listos, los harnesses mejoraron, las ejecuciones se alargaron, pero la interfaz nunca cambió: tú traes el trabajo, el agente pone la mano de obra.

Y la mayoría no se ha dado cuenta, porque la caja del prompt se ha convertido en silencio en lo que la IA es en nuestras cabezas.

Ask anything about your stack...

Cada interfaz sigue siendo una caja de prompt

La caja de entrada es como empezó toda esta era. ChatGPT puso una encima de un modelo y se convirtió en el producto de crecimiento más rápido de la historia, y todos lo copiamos. Cada producto de IA desde entonces ha sido una variación de la misma interacción: el humano teclea, la máquina responde, la máquina espera.

Claude Code fue la siguiente evolución. El agente se mudó a tu terminal, tomó tus archivos, tu shell y tu historial de git, y empezó a hacer trabajo real en lugar de hablar de él. Cambió lo que los agentes podían hacer, pero no cómo empiezan: tú tecleas, trabaja, se detiene y espera a que vuelvas a teclear.

~/app

$ claude

✳ 12 files · main · last session 2h ago

> fix the failing checkout tests

? for shortcuts

Después los agentes se mudaron a la nube. Codex, Devin, Claude Code en la web. Corren durante horas en lugar de minutos, lanzan subagentes para paralelizar el trabajo y no mueren cuando cierras el portátil. Le entregas una tarea a uno antes de comer y vuelves a un pull request.

El prompt incluso dejó de ser algo exclusivo del teclado. Los agentes en segundo plano pueden arrancar con una alerta o un webhook, y la mayoría de plataformas de agentes ofrecen ahora automatizaciones: cuando se dispare este evento, o cuando toque este cron, ejecuta un agente con estas instrucciones.

Triage Sentry alerts Enabled

When

a Sentry alert fires

Do

investigate, open an incident if it's real

Then

post the findings to #incidents

Pero ¿qué es una automatización? Es un prompt que escribiste por adelantado. Predijiste el modo de fallo, elegiste el evento y anotaste qué hacer al respecto. El disparador lanza el agente, pero el criterio que hay dentro es tuyo, congelado en el momento de configurarlo. Una automatización atrapa exactamente lo que anticipaste, y nada más.

Tú eres el planificador

Quita las herramientas y la división del trabajo no se ha movido en tres años. El agente hace el trabajo. Decidir cuál es el trabajo sigue siendo cosa tuya.

Tú lees los paneles, tú escuchas a los usuarios, tú decides qué importa, y comprimes todo lo que has aprendido en un prompt, ya sea en vivo frente al teclado o por adelantado en un disparador. El agente ejecuta de maravilla, pero cada pizca de criterio del sistema se origina en ti.

La siguiente evolución: agentes que encuentran el trabajo

Apuesto a que la siguiente evolución son agentes que descubren por sí mismos el trabajo que hay que hacer. Sin prompt, sin disparador que configurar, sin instrucciones escritas por adelantado. Conectas tu stack, y el agente encuentra el trabajo por su cuenta: vigila las mismas señales que tú vigilas, nota qué está mal, decide si importa y se pone a trabajar en ello de forma autónoma.

Es fácil de decir y brutalmente difícil de construir, porque la proactividad son tres problemas apilados uno sobre otro, y saltarse cualquiera de ellos te da algo peor que el agente detrás de una caja de entrada.

Contexto. Obviamente, el agente necesita un modelo vivo del mundo en el que opera, no una instantánea que pegaste en la ventana de contexto al escribir el prompt. Un agente reactivo con mal contexto te da una mala respuesta. Un agente proactivo con mal contexto borra tu base de datos de producción porque pensó que era staging.

Criterio. Esto es lo que más trabajo me ha dado. En cualquier momento dado, miles de cosas en un sistema de producción están ligeramente mal. Un agente que las señala todas es una máquina de ruido, las máquinas de ruido se silencian, y los agentes silenciados son agentes muertos. Todo el valor de la proactividad vive en el hueco entre “algo cambió” y “algo importa”:

[
  {
    "signal": "memory up 3% on checkout-edge",
    "verdict": "no anomaly",
    "reasoning": "within the seasonal range for this hour on this worker"
  },
  {
    "signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
    "verdict": "incident",
    "reasoning": "error class never seen on this worker, tightly correlated with a deploy"
  }
]

Acción. Notar sin actuar es solo una alerta más lista, y las alertas son justo lo que intento matar. El agente tiene que terminar el trabajo, dentro de límites que hagan segura la autonomía: acciones reversibles, pruebas de todo y una puerta firme antes de que ocurra nada irreversible.

Ninguno de estos tres implica que el agente decida qué aspecto tiene lo bueno. Decide qué está mal, si importa y qué hacer al respecto, y esa es toda la lista, porque en producción nadie tiene que definir lo bueno: errores a cero, latencia en su línea base, colas vacías, certificados válidos. El estado deseado viene con el territorio.

Lo que significa que el cambio real no es de “tú escribes el prompt” a “el agente se escribe el prompt a sí mismo”. Es de operaciones imperativas a operaciones declarativas. Una automatización es imperativa: enumeras los modos de fallo por adelantado y programas una respuesta para cada uno. Un agente proactivo es un ciclo de reconciliación: contrasta el sistema que tienes con el sistema que deberías tener, y trabaja para cerrar el hueco. Kubernetes hizo esto por la infraestructura hace una década, escribes tres réplicas y un controlador hace lo que haga falta para mantener tres réplicas vivas. Nadie lo ha hecho por la operación del software en sí. Y aquí ni siquiera hay YAML que escribir, porque el estado deseado ya se conoce. Funciona de fábrica.

Empecé por las operaciones

Pídele a un agente proactivo que elija la hoja de ruta de tu producto y obtienes un becario con opiniones, porque la dirección de producto es cuestión de gusto. Producción no. Es el único dominio donde los tres problemas tienen solución hoy.

El trabajo se anuncia solo: las tasas de error suben, un despliegue sale mal, un certificado caduca, una cola se acumula. El trabajo ya está en la telemetría, esperando a que alguien lo note. Y a diferencia de los dominios guiados por el gusto, existe una verdad de referencia: la tasa de error se disparó o no, el rollback restauró la línea base o no, así que el criterio del agente lo puntúa el propio sistema, de forma continua, sin espacio para sensaciones.

Sobre todo, ya cubrimos este trabajo con personas. Lo llamamos guardia: una persona durmiendo junto a un teléfono, esperando a que una máquina diga que otra máquina está descontenta. Pasé años en observabilidad, fundé una empresa de observabilidad que Cloudflare adquirió, y escribí todo un manifiesto sobre estructurar la telemetría para que la respuesta esté a una consulta de distancia. Su tesis es la razón por la que existe esta empresa: nadie debería estar de guardia en 2026.

Porque la verdad incómoda de la última década de observabilidad es que hicimos los sistemas más fáciles de interrogar para los humanos a las 3 de la mañana, y luego cantamos victoria mientras los humanos seguían siendo a quienes despertaban. Los paneles se volvieron más bonitos y el buscapersonas siguió en la mesita de noche. La observabilidad sin acción es solo almacenamiento caro.

Qué aspecto tiene

Esto es lo que hace Polylane. Este es un martes concreto:

Nadie configuró una comprobación para este modo de fallo. No hay reglas que escribir ni umbrales que ajustar: los agentes evalúan cada recurso conectado con una cadencia continua, y tus paneles y consultas guardadas existentes se convierten en su lista de comprobación. El criterio es donde soy más estricto. El veredicto por defecto es sin irregularidades, porque es mucho mejor pasar por alto un issue dudoso que despertar a alguien por ruido. “Un despliegue podría introducir un bug” es cierto de todos los despliegues y nunca es motivo para avisar a nadie.

Cuando algo es real, la investigación ejecuta varias hipótesis rivales en paralelo, y el trabajo de cada agente es refutar su hipótesis en lugar de confirmarla, así que la correlación nunca llega a disfrazarse de causa. Cuando la causa raíz confirmada es un cambio de código, el arreglo llega como un pull request con la investigación adjunta:

Restore Hyperdrive pool size in checkout-edge

PR open coreplane/checkout-edge

Investigation report attached Checks passing

Opened by Polylane · gated on review and CI

Proactivo no significa sin supervisión

La autonomía está en el notar, el triaje, la arqueología de las 3 de la mañana y la mitigación. Todo lo que restaura un estado conocido y bueno, el agente lo hace por su cuenta: revertir el despliegue malo, volver a desactivar el flag. Esas acciones son reversibles por construcción, y son las que de verdad silencian el buscapersonas. Lo que sigue tras una puerta es todo lo que crea un estado nuevo: un cambio de código se publica a través de tu revisión y tu CI, nunca esquivándolas.

La línea no es humano frente a agente. Es reversible frente a no reversible. Y por eso no sigues secretamente de guardia: el rollback terminó el incidente a las 02:33, seis horas antes de que fusionaras el pull request. El PR nunca fue lo que detuvo la hemorragia. Es lo que evita que vuelva a pasar, y eso puede esperar al café.

Y la puerta es tuya para delegarla. Los agentes de revisión de código ya leen cada pull request de tu repositorio. Hay un mundo, no muy lejos de este, donde tu agente de revisión lee el arreglo a las 02:41, lo contrasta con la investigación, lo aprueba y tu CI despliega a producción antes de que despiertes. Nada del ciclo cambia salvo quién tiene el botón de aprobar. Ahí es donde termina esto: software que se arregla solo, contigo escribiendo la política en lugar de hacer clic en merge.

Fíjate en lo que falta en ese ciclo:

Ask anything about your stack...

La caja del prompt fue una gran manera de aprender a confiar en estos sistemas, y es una manera terrible de operar producción. El agente ha visto cada despliegue, cada línea de log y cada métrica de todos los servicios a la vez. Mantenerlo detrás de un prompt significa que el miembro mejor informado de tu equipo solo habla cuando le hablan.

Nadie debería estar de guardia en 2026.