Tu IA sigue esperando que aprietes el botón

Una prueba para quien ya se volvió bueno usando IA: cuenta cuántas ejecuciones arrancaste esta semana. Cada resumen, cada borrador, cada reporte que produjeron tus skills guardados. ¿Quién apretó el botón?

Si la respuesta es tú, todas las veces, estás en el nivel donde se quedan casi todos los usuarios serios, convencidos de que ya llegaron arriba. Escribiste tus instrucciones, las convertiste en skills (flujos de trabajo guardados que la IA sigue igual cada vez) y ahora el resultado es consistente. Es un avance real, y en abril lo defendimos en la curva de aprendizaje de la IA y en usas Claude, pero no lo estás entrenando (ambos en inglés). El problema es que el negocio solo se mueve cuando tú te sientas a arrancarlo. Construiste una máquina rápida con una sola llave de encendido, y esa llave la llevas en el bolsillo.

¿Qué cambia cuando un skill corre sin ti?

Menos de lo que uno espera, y esa es la buena noticia. El skill sigue siendo el mismo: las instrucciones, el contexto y el formato del resultado se mantienen. Lo único que cambia es qué lo arranca.

Con el botón, lo arrancas tú. Sin el botón, lo arranca algo que pasa en el negocio: una hora del día, un formulario enviado, una llamada que termina, un archivo que aparece en una carpeta. En la jerga, al horario le dicen cron y al evento, webhook, pero no necesitas ninguna de las dos palabras para usarlos. Lo que sí necesitas es responder una pregunta por cada skill: ¿qué tiene que pasar en mi negocio para que este trabajo empiece?

Las cinco piezas que necesita un agente ya las explicamos en ¿GrokBot o Claude?, así que no voy a repetir la lista. Este artículo trata de la pieza que casi todos se saltan, el disparador, y de lo que pasa con tu trabajo cuando el disparador ya no eres tú.

¿Qué significa que la persona solo aprueba?

Aprobar es revisar un trabajo que ya está hecho. Dejas de hacer la tarea y empiezas a juzgarla: la apruebas, la corriges o la descartas. Suena a que te bajaron de puesto. En la práctica, es la primera vez que tu criterio se usa en cada ejecución, en lugar de gastarse en acordarte de arrancarla.

Eso solo funciona si el resultado está pensado para revisarse rápido. Nuestro monitor de sitios corre todos los días a las 7 de la mañana sin que nadie lo arranque. Hace veinte revisiones en los sitios de los que somos responsables, los nuestros y los de nuestros clientes. Cuando todo está bien, lo dice en una línea. Cuando algo falla, dice en qué sitio y cuál fue la revisión que falló.

Esa única línea es la decisión de diseño más importante de todo el sistema. Si el reporte de un día normal ocupara una página, yo dejaría de leerlo en la segunda semana y, a partir de ahí, nadie estaría aprobando nada. Una tarea automática cuyo resultado ya nadie lee es peor que una manual, porque da la impresión de que alguien está vigilando.

¿Por qué nuestra revisión funcionaba a mano y fallaba con el horario?

El mismo monitor nos dejó la lección que yo pondría primero en cualquier lista sobre automatización. Este mes agregamos una revisión que compara los inmuebles publicados en el sitio de un cliente de bienes raíces con el MLS. La corrimos a mano y pasó. La corrimos otra vez y pasó. Después falló en su primera ejecución programada, y también en la siguiente.

En el sitio del cliente no había nada mal: los siete inmuebles coincidían las dos mañanas. Lo que no podía correr era la revisión. En una Mac, el programador de tareas no tiene permiso para leer archivos del Escritorio, y la revisión guardaba su copia de referencia en una carpeta del Escritorio. Cuando la corría yo, corría con mis permisos. Cuando la corría el horario, no los tenía.

Ese es el problema de probar una automatización apretando el botón: estás probando tu propio contexto, con tus sesiones abiertas, tus archivos y tus permisos. El disparador trabaja en otro contexto. Un skill no está automatizado hasta que funcionó en el contexto que usa el disparador, y por eso ahora, antes de dar por terminada una revisión nueva, obligamos al propio programador a ejecutarla.

Cambiamos la revisión para que lea el sitio en vivo en lugar de un archivo, y resultó ser una mejor pregunta: ¿la página que ve el público coincide con el MLS? La segunda corrección fue más pequeña y pesó lo mismo. La ejecución fallida se había reportado como una lista de ocho problemas, porque el texto del error parecía una lista de problemas. Ahora, cuando una revisión no puede correr, lo dice en una línea y no saca ninguna conclusión sobre los inmuebles. Que una tarea no haya podido correr y que haya encontrado algo mal son dos hechos distintos, y la línea de la mañana tiene que mantenerlos separados.

¿Qué skills conviene poner primero en un disparador?

Los que ya corriste a mano tantas veces que te aburren. El aburrimiento indica que la información de entrada siempre llega igual y que ya sabes cómo se ve un buen resultado. Un skill es criterio puesto por escrito (lo explicamos en a los que construyen la máquina no los reemplaza la máquina), y un skill que todavía ajustas en cada ejecución es criterio que no terminaste de escribir. Los buenos candidatos tienen varias cosas en común:

• Siguen un ritmo que el negocio ya tiene: cada mañana, cada cliente nuevo, cada llamada que termina.
• La información llega a un lugar donde una máquina la puede ver, como una bandeja de entrada, una carpeta o un formulario.
• Un resultado equivocado te llega a ti antes que a nadie más.
• Puedes distinguir un buen resultado de uno malo en menos de un minuto.

Hay uno que todavía no pasamos al disparador. Cada llamada que grabamos ya queda guardada como transcripción cuando termina. Convertir esa transcripción en notas y pendientes es un skill que uso todo el tiempo, y aun así lo sigo arrancando yo, pidiéndolo. El evento ya existe, la transcripción siempre tiene la misma forma y un mal resumen me cuesta un minuto. Es el siguiente candidato obvio para dejar de depender del botón.

¿Qué trabajos nunca deberían correr con un disparador?

Mi regla es que nada sale del negocio solo porque se activó un disparador. El disparador puede preparar un correo para un cliente, pero lo envía una persona. Puede redactar un cambio de precio, un artículo o la respuesta a una reseña, pero una persona lo aprueba antes de que alguien de afuera lo vea. Todo lo que no tiene vuelta atrás, como pagos, borrados o envíos, se queda detrás de una persona, aunque la redacción sea automática.

Aquí es donde casi todos lo hacen al revés. Automatizan el final, porque enviar es el clic tedioso, y siguen preparando todo a mano porque sienten que ese es el trabajo de verdad. Hay que darle la vuelta. La preparación es justamente lo que un disparador debería hacer mientras duermes. El clic que pone tu nombre en algo es la parte que vale la pena conservar.

Hay otro tipo de trabajo que conviene dejar fuera del disparador: cualquiera en el que la decisión cambia cada vez. Si no puedes poner por escrito cómo se ve un buen resultado, ese trabajo todavía no es un skill, y automatizarlo solo produce trabajo malo con horario fijo.

¿Cómo sacas tu primer skill del botón?

Elige el skill que más ejecutaste el mes pasado. Anota qué revisas cuando miras su resultado: esa lista se convierte en tu paso de aprobación, y casi siempre es más corta de lo que esperas. Decide dónde va a llegar el resultado, en algún lugar que ya revisas todos los días y no en un tablero nuevo que vas a olvidar. Después define qué evento lo tiene que arrancar y conecta las dos cosas.

Antes de confiar en él, haz que el disparador lo ejecute una vez mientras miras. No tú apretando el botón, sino el horario o el evento real. Nuestra revisión pasó cada vez que la arranqué yo y falló cada vez que la arrancó el horario, y solo viendo una ejecución programada podía darme cuenta.

Después déjalo solo una semana y limítate a leer lo que te entrega.

Todos los días a las 7 de la mañana corren veinte revisiones en los sitios de los que somos responsables, y casi siempre el reporte completo es una sola línea. No lo arranco yo y no tengo que acordarme de que existe. Mi trabajo ahora es leer esa línea.