El bucle de investigación que sabe cuándo no ejecutarse

Respuesta directa

Este es un sistema de investigación programado que gasta dinero real, y la mayor parte de su ingeniería está dedicada a no gastarlo. Tres agentes se ejecutan cada semana contra mi propio sitio: una comprobación de posicionamiento, un escaneo pagado de visibilidad en IA, y un brief de contenido. Lo interesante no es que se ejecuten. Es que el escaneo puede negarse a empezar de ocho maneras distintas, cada una con su propio código de salida, y que cada rechazo se reporta a una persona en lenguaje claro en lugar de reintentarse.

Este es el sistema operativo que uso para mi propio negocio, no un caso de estudio de un cliente. Lo describo porque los artefactos son inspeccionables: un archivo de precios versionado, un libro de costes, instantáneas de datos fechadas, e informes de ejecución semanales.

Puntos clave

• La autonomía no es permiso para actuar. Es una programación más una lista explícita de condiciones bajo las cuales el sistema se detiene.
• La barrera de presupuesto se ejecuta antes de la primera solicitud, calculada a partir de un archivo con fecha.
• Disparar el mismo trabajo semanal dos veces se rechaza, no se cobra dos veces.
• Una medición parcialmente terminada se reporta como inutilizable en lugar de suavizarse.
• La misma arquitectura es el primer sistema en automatización de flujos de trabajo con IA.

¿Qué problema posee realmente este sistema?

El trabajo es investigación que tiene que ocurrir con un ritmo: dónde se posiciona el sitio, si los motores de respuesta de IA lo citan, y qué escribir a continuación. Hecho a mano son tres o cuatro horas a la semana, se salta cada vez que la semana está ocupada, y el resultado va derivando en silencio de la evidencia a la opinión: terminas escribiendo sobre el tema que parece interesante en lugar del que respaldan los datos.

Es la misma forma que el problema de ventas en el análisis del sistema de seguimiento en el CRM: un camino repetible, sostenido por la memoria de una persona, que se degrada en cuanto la atención se desplaza. Distinto departamento, mismo patrón de fallo.

La diferencia está en el perfil de riesgo. Un seguimiento perdido cuesta una oportunidad. Un bucle de investigación con acceso a APIs y un programador puede costar dinero cada vez que falla, y también puede producir un número seguro de sí mismo que está equivocado, lo cual es peor, porque actúas sobre él.

El flujo de trabajo existente que mapeo primero

Todo lo que hace el sistema ahora se corresponde con una fila de esa tabla. No se automatizó nada porque fuera automatizable; se automatizó porque estaba en esa tabla.

Cómo se ejecuta el bucle

Tres agentes programados, todos en Europe/Athens, todos definidos como archivos de instrucciones legibles en el repositorio en lugar de configuración oculta en un panel de SaaS.

Lunes — comprobación de posicionamiento

Obtiene datos frescos de la API de Search Console y escribe una instantánea fechada, de modo que la comparación semana a semana deja de depender de que alguien recuerde exportar. Luego verifica que la ventana de datos no tenga más de cuatro días de antigüedad antes de analizar nada. Si una obtención falla, reporta el fallo y la antigüedad de los datos existentes. La regla en el archivo es tajante: no analizar archivos obsoletos en silencio.

Miércoles — escaneo de visibilidad en IA

El único paso que cuesta dinero. Pregunta un conjunto fijo de consultas de comprador a varias plataformas de IA con búsqueda web activada, y registra quién fue citado. A mitad de semana por diseño, para que haya tiempo de reaccionar antes del viernes.

Viernes — brief de contenido

Clasifica oportunidades sobre las filas que produjeron los dos días anteriores, y escribe un brief. No tres. Si no existe un informe de brechas completado, tiene instrucciones de no inventar un tema: termina recomendando que se ejecute la auditoría de brechas en su lugar.

Cuándo el sistema se niega a actuar

Esta es la parte que vale la pena copiar.

El escaneo del miércoles tiene ocho resultados posibles, y solo uno de ellos significa “se tomó una medición completa”.

Cuatro mecanismos producen esos rechazos.

Una barrera de presupuesto que se ejecuta antes de la primera solicitud. El escaneo calcula el precio exacto de lo que está a punto de enviar, usando un archivo de precios con una versión, una pricing_date, y una nota que registra cómo se verificó cada tarifa. Si la estimación supera el máximo configurado por ejecución, se detiene e imprime lo que habría costado. No se envía nada. Superar el límite requiere una bandera pasada deliberadamente por una persona, y el script programado es explícito en que nunca debe pasarse desde una programación automática.

Un guardián de idempotencia. El trabajo semanal deriva un ID de ejecución estable a partir de la semana ISO. Dispararlo dos veces en la misma semana hace que la segunda ejecución se rechace con el código de salida 3 en lugar de cobrarse de nuevo. Forzar una ejecución genuinamente nueva significa elegir un ID nuevo a propósito.

Reanudación que no vuelve a pagar. Si un escaneo muere a mitad de camino, volver a ejecutarlo con el mismo ID envía solo las tareas que nunca tuvieron éxito. El trabajo completado no se compra dos veces. Un par de fallos de red transitorios no debería costar un reescaneo completo para repararse.

Una comprobación de desajuste de plan. Si la lista de consultas cambia después de que un ID de ejecución haya comenzado, el sistema se niega a reanudar, porque reanudar mezclaría dos conjuntos de preguntas distintos en una sola cifra semanal. Le dice que inicie un nuevo ID de ejecución en su lugar.

Debajo de los cuatro hay un mismo principio: una repetición cuesta dinero real, así que es decisión del propietario, no del programador. Las ramas de fallo lo dicen en texto, y terminan con una instrucción de no lanzar otro escaneo para compensar.

Qué permanece bajo control humano

• Publicar. El agente del viernes produce un brief y se detiene. Redactar es decisión del propietario.
• Gastar por encima del límite. Una bandera manual, nunca una programación.
• Volver a ejecutar un escaneo pagado que falló. Se reporta, nunca es automático.
• Reportar una semana incompleta. El script establece con claridad que un escaneo incompleto no debe reportarse como la cifra semanal.

La nota de Anthropic sobre construir agentes efectivos hace el mismo argumento desde el lado contrario: empezar con un flujo de trabajo simple e inspeccionable y añadir autonomía solo donde se la gane. Los códigos de rechazo son cómo mantengo el flujo de trabajo inspeccionable una vez que se ejecuta sin supervisión.

Cómo mido el propio bucle

Dos hábitos hacen la mayor parte del trabajo aquí, y ambos consisten en negarse a halagar al sistema.

Las métricas que miden cosas distintas nunca se combinan. El reconocimiento de marca y el descubrimiento de categoría no marcado se reportan por separado. Combinarlos produce un único número que siempre parece mejor que la realidad, porque tu propio nombre lo infla.

Las reglas de coincidencia se ajustan cuando están mal. El comparador de marca originalmente aceptaba el nombre y apellido a secas. Eso coincidía con personas no relacionadas e inflaba la tasa de menciones con resultados que no se podían auditar, así que se eliminaron y se registraron como alias rechazados con el motivo adjunto. El número bajó. Ese fue el resultado correcto.

La misma disciplina se aplica a las brechas: una plataforma sin clave de API se registra como unavailable, nunca se estima. Y los informes llevan una advertencia permanente: son resultados de API con búsqueda web activada, que rastrean la dirección de forma fiable pero no son una copia de lo que ve una persona en una app de consumo.

No estoy publicando una afirmación de rendimiento para este sistema. La afirmación honesta es más estrecha: la investigación ahora ocurre con una programación, cada ejecución pagada tiene un registro de coste, y las semanas en las que no se midió nada son visibles como tales. Eso es lo que puedo mostrar.

Cuándo esta es la construcción equivocada

• El trabajo ocurre una vez al mes y una persona puede simplemente hacerlo.
• Nadie va a leer el resultado. Un informe programado sin lector es un coste programado.
• El equipo quiere un panel en lugar de una decisión. Este bucle termina con una acción recomendada.
• No hay un propietario del presupuesto. Cualquier sistema con una clave de API necesita una persona de cuyo dinero se trate.

Si la restricción es el sitio web público en lugar de las operaciones detrás de él, ese es un problema distinto y pertenece a SimplySites.

Cómo se conecta esto con el servicio

Dos análisis, dos departamentos, una sola arquitectura: un disparador que la empresa ya posee, un modelo haciendo la preparación, una persona en todo lo irreversible, y una medición a la que se le permite no reportar nada.

Ese patrón es lo que construyo dentro de las empresas durante un acompañamiento de IA integrado. Las operaciones de investigación suelen ser el lugar más seguro para empezar, porque el modo de fallo es una ejecución desperdiciada en lugar de un error de cara al cliente, lo cual la convierte en un buen primer sistema para un equipo que está aprendiendo a supervisar uno.

Si un camino repetido en tu negocio ya depende de que una persona recuerde hacerlo, describe el cuello de botella y delimitamos el bucle útil más pequeño posible.

Resumen

Construí un bucle de investigación que se ejecuta tres veces por semana y está diseñado sobre todo alrededor de las condiciones bajo las cuales debe detenerse: una barrera de presupuesto antes de la primera solicitud, un guardián de idempotencia que se niega a pagar dos veces, una semántica de reanudación que nunca vuelve a comprar trabajo ya hecho, y ocho códigos de salida que le dicen a una persona exactamente qué pasó. Autonomía aquí significa que el sistema actúa según una programación sin supervisión y se niega a actuar sin permiso. Únete al boletín de automatización con IA para el próximo análisis.