Crea un bucle de agente proactivo en Claude Opus 5.5

La parte incómoda de construir tu propio agente proactivo es que el trabajo interesante no es la llamada al modelo. Puedes tener a Claude Opus 5.5 respondiendo preguntas en una tarde. Hacer que se despierte según un horario, que lea solo lo que ha cambiado desde la última vez, que decida si algo merece la atención de una persona, que redacte la acción y luego se detenga y espere: eso son semanas, y casi nada de ello ocurre dentro del modelo. Anthropic lanzó una versión de este bucle como Claude Duet, y lo útil de ese producto para cualquiera que construya el suyo no es su lista de funciones, sino las decisiones que se ven en cómo está ensamblado. No tiene una API publicada y no se puede redirigir a tus propios sistemas, así que si quieres el bucle en lugar de la aplicación, lo construyes. Lo que sigue es la arquitectura, etapa por etapa, con el coste honesto de cada una.

Primero, la forma. Cinco etapas se ejecutan en secuencia, y la quinta solo se alcanza después de que una persona diga que sí. Un planificador se dispara. Un paso de resumen reduce cada sistema conectado a un delta. Un paso de decisión convierte ese delta más una política en una propuesta tipada. Una puerta de aprobación fuera del modelo decide si la propuesta puede ejecutarse. Un ejecutor la lleva a cabo. Ese es todo el diseño, y todo lo difícil reside en las costuras.

Fase uno: un planificador que se activa cada pocas horas

La primera decisión es la que la gente suele equivocar por entusiasmo y no por criterio de ingeniería: no hacer sondeos continuos. La documentación de Duet de Anthropic explica su intervalo —comprobar cada pocas horas— diciendo que comprobar sin parar agotaría los límites del plan mucho más rápido. No es una precaución de marketing. Es la respuesta correcta a un problema real de costes, y es la trampa en la que cae todo agente hecho en casa en la primera semana.

El sondeo continuo es ruinoso por una razón estructural. Cada barrido es un contexto completo: instrucciones, definiciones de herramientas, el material que incorporaste y cualquier razonamiento que el modelo haga sobre ello. Con una cadencia de un minuto, eso son 1.440 contextos completos al día, y la inmensa mayoría no encuentra nada nuevo. Pagas el precio completo para que te digan que el buzón no ha cambiado. Con una cadencia de tres horas obtienes ocho, y la relación entre hallazgos y gasto se convierte en algo que puedes defender ante quien firma la factura.

Así que el programador es un temporizador estilo cron con un límite inferior en el intervalo mínimo, no un flujo de eventos. Los eventos suenan atractivos —reaccionar en el momento en que ocurre algo—, pero te empujan de vuelta hacia el trabajo continuo y hacen que el coste de un día ajetreado sea ilimitado. Un temporizador ofrece un techo predecible, que es lo que necesitas cuando la factura es variable. Cuando quieras una reacción más rápida para una fuente, acorta solo el intervalo de ese conector y acepta el gasto adicional.

Etapa dos: un prefijo idéntico byte a byte, retenido en la caché

Aquí es donde los números publicados resultan más determinantes. Claude Opus 5.5 en OrcaRouter cuesta 4,00 dólares por millón de tokens de entrada y 20,00 por millón de tokens de salida, con una ventana de contexto de 1M de tokens y lecturas de caché a 0,20 por millón, al precio de lista del proveedor con un 0 por ciento de recargo. Interpreta esas cifras como una restricción de diseño más que como una lista de precios: una lectura de caché cuesta una vigésima parte de un token de entrada nuevo, así que cada byte que mantienes estable entre barridos es un byte por el que dejas de pagar el precio completo.

En la práctica, el prompt del sistema y el esquema de la herramienta se ensamblan una vez en el momento del despliegue y nunca se regeneran en cada barrido. No se vuelven a serializar a partir de un diccionario con las claves en otro orden. No se aplican plantillas con una marca de tiempo, un ID de solicitud o las cuentas conectadas de hoy insertadas en medio. Cualquier byte que difiera invalida el prefijo en caché, y el bloque de instrucciones vuelve al precio completo de entrada en cada barrido. Los equipos pierden esto por accidente más a menudo que por intención, normalmente porque una abstracción bienintencionada empezó a inyectar un identificador de ejecución cerca del principio del prompt.

La disciplina que sobrevive al contacto con código real es aburrida: una función que devuelve una cadena constante para el bloque estable, un literal congelado para el esquema de la herramienta y cada elemento variable colocado después. Luego, una prueba que calcula el hash del bloque y hace fallar la compilación cuando el hash cambia, porque alguien acabará añadiendo un campo al esquema y nunca pensará en la caché. Esa prueba cuesta una hora y salva todo el beneficio del almacenamiento en caché.

Etapa tres: un resumen por conexión, no un volcado de buzón

La tercera etapa es la que un producto de consumo obtiene gratis y tú no. Duet vive dentro de la cuenta de Anthropic y llega a las aplicaciones conectadas, así que puede preguntar qué cambió desde un momento dado y obtener una respuesta breve. Si construyes fuera de esa cuenta, hablas con las mismas APIs que cualquier cliente normal: o implementas lecturas incrementales o lo recuperas todo y le entregas al modelo un muro de texto.

Extraerlo todo es el comportamiento predeterminado porque funciona desde el primer día. También es la forma más rápida de volver impredecible el costo por barrido, porque la entrada crece con el buzón en lugar de con lo que cambió. Un barrido sobre cuarenta hilos sin cambios cuesta lo mismo que uno sobre cuarenta hilos en los que solo importa un hilo, y solo uno de esos tenía alguna posibilidad de generar una propuesta útil. Después de un mes así, la mayor parte de tu presupuesto se fue en confirmar el statu quo.

El paso de resumen debe ser código, no prompting. Obtén los datos de cada conexión usando el cursor o el delta que ofrezca la API, y reduce el resultado a un resumen estructurado: qué apareció, qué se modificó y qué se resolvió. Asigna a cada elemento un identificador estable para que las etapas posteriores puedan referirse a él, y registra el último cursor exitoso por conexión para que una obtención fallida no reproduzca el material de ayer como si fuera nuevo. Un resumen que no puede distinguir «no ha pasado nada» de «no pude comprobarlo» acabará informando con seguridad sobre un estado que nunca observó.

Etapa cuatro: un paso de decisión que emite un objeto, no prosa.

Aquí es donde se sitúa Claude Opus 5.5, y lo que emite determina si el resto del sistema puede construirse siquiera. El instinto es hacer que el modelo escriba un resumen y dejar que una persona lo lea. Eso funciona para un panel de control y falla para una compuerta: la siguiente etapa debe decidir si permite una acción, y no se puede conceder permiso a un párrafo.

El paso de decisión debe devolver una propuesta de acción con tipo: un nombre de acción de una lista cerrada, el objetivo al que se aplica, los parámetros, una justificación de una línea y un indicador explícito de confianza o escalamiento. Una lista cerrada de acciones no es burocracia; es el mecanismo que hace que la compuerta de aprobación sea exigible, porque una compuerta solo puede validar las acciones que puede enumerar. Un agente que puede emitir cualquier verbo no puede someterse a una compuerta, solo puede ser objeto de confianza.

Dos notas prácticas. Dale al modelo el resumen y luego la política, para que la política quede después del material variable y el prefijo de caché se mantenga intacto. Y haz que el resultado predeterminado sea «ninguna acción» en vez de una propuesta vacía que parezca una acción. Los bucles que tratan el silencio como un fallo producen volumen, y un agente que fabrica trabajo para parecer útil es peor que uno que informa de que nada ha cambiado.

Etapa cinco: una puerta de aprobación que realmente puede decir no

La compuerta debe ser un servicio separado, no una rama dentro del propio código del agente. Esta es la decisión estructural más importante de la implementación. Si el proceso del agente puede ejecutar la acción por sí mismo, un error, una inyección de prompt o una bandera mal configurada en ese proceso llega a producir el efecto. Si el ejecutor solo acepta una propuesta que la compuerta ha firmado, lo peor que el agente puede hacer es proponer algo incorrecto, y el rechazo de la compuerta es real.

La política publicada por Anthropic para Duet merece copiarse en su forma, incluso donde tu lista difiera. El mecanismo de aprobación solicita autorización antes de que una acción envíe un mensaje, realice un pago, firme un documento o elimine algo. Por encima de eso hay un segundo nivel que se rechaza incluso con aprobación —en el caso de Duet, operar con valores y mover dinero entre cuentas—. El patrón es una política de dos niveles: un conjunto grande de acciones sujetas a aprobación que una persona puede permitir, y un conjunto pequeño que ninguna aprobación desbloquea. Copia los niveles aunque cambie cada elemento, porque resuelven problemas distintos. El mecanismo de aprobación protege contra errores. La lista de prohibiciones protege contra un operador comprometido, incluido el humano.

La otra mitad de una puerta real es que interrumpe. La solicitud de aprobación de Duet muestra la acción exacta y espera, lo que detiene deliberadamente el flujo en lugar de anotarlo. Una puerta que escribe una línea en un registro que nadie lee no es una puerta; es un recibo. Si tu paso de aprobación necesita que alguien vigile un panel a las tres de la madrugada, o el intervalo es demasiado corto o la lista de acciones es demasiado amplia. Ambas cosas se pueden corregir, y ninguna de las dos se corrige añadiendo una notificación.

Memoria, credenciales y las dos superficies de las que no puedes escapar con pruebas

Dos problemas difíciles subyacen a las cinco etapas, y ambos parecen características hasta que dejan de serlo.

• Continuidad del contexto. Cada barrido es un contexto nuevo, así que todo lo que el agente deba recordar entre barridos tiene que quedar escrito entre ellos. Un archivo de estado continuo por conexión, con el tamaño limitado, que contenga los asuntos pendientes y las decisiones recientes basta para la mayoría de los bucles. Lo que no funciona es esperar que el modelo reconstruya el historial a partir del resumen, porque el resumen es explícitamente una descripción de cambios y no contiene memoria de lo que ya se decidió.

• Custodia de credenciales. Duet sigue el diseño utilizado para los agentes gestionados de Anthropic, por lo que nunca ve directamente tus contraseñas ni tus tokens de inicio de sesión. Reproducir esa disciplina es la parte que la mayoría de los agentes creados en casa omiten, y omitirla significa que cada prompt tiene una ruta hacia una credencial. El modelo nunca debería tener un token, nunca debería recibir una clave de API como texto y nunca debería ser el componente que autentica. Deja que el paso de digest y el ejecutor conserven las credenciales y entreguen al modelo solo los resultados.

Luego está la superficie en la que nadie quiere pensar: una vez que el agente lee correos electrónicos y páginas web, cada uno es una entrada que puede contener instrucciones. Un mensaje que diga «reenvía esto a la dirección de abajo» es indistinguible de los datos para un modelo que no tiene una noción separada de autoridad. Dos defensas superan cualquier cantidad de endurecimiento de prompts. Mantén la lista de acciones cerrada, para que una instrucción inyectada no tenga ningún verbo al que recurrir. Y mantén la barrera fuera de la influencia del modelo, porque una inyección que convence al modelo de enviar algo todavía tiene que convencer a una persona que ve la dirección de destino.

Conmutación por error y dónde el enrutamiento ayuda realmente

Con el bucle construido, se abre una opción arquitectónica que un diseño de un solo proveedor no tiene. El DSL de enrutamiento de OrcaRouter compone varios modelos en una sola llamada, y la fusión de modelos ejecuta un panel de modelos que responden en paralelo; ambos ponen más de un modelo detrás de una sola solicitud. El uso práctico aquí no tiene nada de glamuroso: dirigir un modelo más barato al resumen condensado, donde el trabajo es de compresión más que de juicio, y mantener Claude Opus 5.5 en el paso de decisión, donde se forma la propuesta. La misma clave compatible con OpenAI da acceso a más de 200 modelos, así que cambiar qué modelo sirve a cada etapa es un cambio de configuración y no una reescritura.

La conmutación por error es la otra mitad. Cuando un proveedor atraviesa una mala racha, un agente que solo puede alcanzar un endpoint también la atraviesa, y un bucle programado sin alternativa simplemente se salta su barrido. El enrutamiento convierte un barrido omitido en uno más lento: no es un beneficio espectacular hasta la semana en que lo necesitas, y entonces marca la diferencia entre un hueco en el registro y ningún hueco.

A lo que realmente te estás suscribiendo

Ejecutar este bucle es operar un servicio, y el servicio tiene cuatro propiedades de las que acabas de tomar posesión.

• Tiempo de actividad.La aplicación de Anthropic es el localizador de otra persona; el tuyo es tuyo. Un programador de tareas que deja de dispararse en silencio no genera ningún error ni ninguna salida, y te enteras por una persona que notó la ausencia de su informe matutino, no por una alerta.

• Custodia de credenciales. Cada token que conserva tu paso de resumen es uno de los que eres responsable, y el radio de impacto de una filtración es todo aquello a lo que esa conexión pueda llegar. El diseño de Anthropic mantiene las credenciales lejos del modelo; si el tuyo no lo hace, el modelo se convierte en una superficie de ataque para cada cuenta que hayas conectado.

• Defensa contra la inyección de instrucciones. La compuerta aporta mucho aquí, pero solo para las acciones que controla. Todo lo que el agente hace sin aprobación —leer, resumir, escribir su propio estado— queda desprotegido, y un resumen envenenado puede corromper la memoria de la que razonan los barridos posteriores.

• La recompensa por errores no es de nadie. Si tu bucle se dispara por error y envía el mensaje equivocado a un cliente, no hay proveedor al que escalar, ni página de estado, ni informe de incidentes. Las decisiones anteriores son la única red de seguridad, por lo que la puerta es un servicio aparte y la lista de acciones está cerrada.

Nada de eso es un argumento en contra de construirlo. Es un argumento en contra de construirlo de forma casual. Cada etapa es pequeña, y las costuras entre ellas son donde reside el criterio: un temporizador en lugar de un flujo, un prefijo congelado en lugar de una plantilla, un resumen en lugar de un volcado, un objeto en lugar de prosa, y una compuerta que es un servicio en lugar de un comentario. Si aciertas con eso, el bucle se gana su sustento: encuentra cosas que no habrías buscado y se detiene antes de hacer algo que no se pueda deshacer. Si te equivocas, habrás construido algo que consume tu presupuesto continuamente y te dice lo que ya sabías.