Agentes de IA con el SDK 0.102 de Anthropic: qué eliminar en Cloudflare

Qué incorporaron realmente las versiones 0.100 a 0.102 del SDK

Tres versiones en ocho días, y la superficie del SDK de Python cambió más que durante los seis meses anteriores. Las fechas importan: cualquier sistema de producción anclado a anthropic==0.99.x quedó fuera de todo el entorno de ejecución de Managed Agents en un solo sprint.

v0.100.0 (6 de mayo de 2026) añadió soporte para sistemas multiagente, outcomes, webhooks y validación de vaults dentro del espacio de nombres beta. La pieza clave es esta: client.beta.managed_agents.sessions.create(thread=..., outcome=..., metadata=...) devuelve un session_id y se ejecuta de forma asíncrona en la infraestructura de Anthropic. El bucle de orquestación deja de estar bajo tu responsabilidad.

v0.101.0 (11 de mayo de 2026) incorporó el cliente de AWS para Claude Platform on AWS y actualizó todos los ejemplos del cookbook a claude-sonnet-4-5-20250929. Para quienes usan Bedrock, esta es la versión necesaria: el soporte de la variable de entorno ANTHROPIC_BEDROCK_SERVICE_TIER (default/flex/priority) llegó aquí, no en la 0.100.

v0.102.0 (13 de mayo de 2026) añadió los tipos BetaManagedAgentsSearchResultBlock, diagnósticos de caché para la beta de prompt caching y validación anticipada de iteradores de Pydantic. La superficie de tipos de bloque todavía está cambiando; esa es la principal razón por la que aún no migro mi código multiagente.

La función protagonista son los outcomes. Se define una rúbrica, un agente evaluador independiente califica el resultado y el agente reintenta la tarea hasta aprobar. La evaluación interna de Anthropic afirma una mejora de hasta +10 puntos en la tasa de éxito frente a los bucles de prompting convencionales, de +8.4% al generar docx y de +10.1% al generar pptx. Es una magnitud coherente con lo que observo en mi propio Critic Durable Object: un único intento adicional con las observaciones del juez equivale, aproximadamente, a subir un nivel de calidad del modelo.

La otra mitad son los webhooks. Ocho eventos de sesión se envían a una URL registrada en Claude Console: session.status_run_started, session.status_idled, session.status_rescheduled, session.status_terminated, session.thread_created, session.thread_idled, session.thread_terminated y, el más importante, session.outcome_evaluation_ended. El secreto de firma tiene el formato whsec_… y solo se muestra una vez al crearlo. La verificación se hace con client.webhooks.unwrap(payload, signature, secret).

También llegó la orquestación multiagente, aunque detrás de una solicitud de acceso a la versión preliminar de investigación. Más adelante explico por qué aún no voy a activarla.

Qué cambia para fundadores sin perfil técnico que usan agentes de IA

Anthropic ahora ejecuta el agente por ti. Tú redactas la rúbrica («¿el artículo llegó a 2,000 palabras, citó tres fuentes primarias y superó la expresión regular para detectar texto generado por IA?»). El agente evaluador de Anthropic califica el resultado y vuelve a ejecutar el agente hasta que aprueba. Tu ingeniero deja de programar el bucle de reintentos.

El costo cambia por dos vías. Primero, hay menos bucles de reintento hechos a medida en el código, así que se reduce el tiempo de ingeniería sénior necesario para mantenerlos. Segundo, hay más reintentos dentro de la sesión de Anthropic; cada uno se cobra a $0.08 por hora de sesión, además de los tokens. Que el saldo sea favorable depende por completo de cuánto duren las sesiones.

El cálculo realista es este: si el equipo está lanzando la v1 de un producto basado en agentes, Managed Agents sustituye cerca del 40% del código de orquestación que, de otro modo, tendría que construir un ingeniero sénior. Si el producto ya está en funcionamiento, reemplaza una parte menor, pero los webhooks eliminan el bucle de sondeo que casi con seguridad existe en algún punto del sistema.

La pregunta para el CTO esta semana es: «¿Seguimos consultando periódicamente si el proceso terminó o ya migramos a session.outcome_evaluation_ended?» Si la respuesta es «seguimos consultando», una refactorización de medio día permite reducir a la vez el costo de infraestructura y la latencia de las solicitudes.

La arquitectura de Cloudflare que uso hoy

Para entender qué se elimina, esta es la arquitectura: un único Worker de Hono en Cloudflare Workers (objetivo ES2021 y binding de Static Assets) sirve de entrada a seis Durable Objects, uno por rutina de publicación. Editorial, Discovery, Writer, Distribution, Maintenance y Manager, más un séptimo, ManualIntake, que da soporte a la interfaz de administración.

Cada rutina se activa mediante uno de seis Cloudflare Workflows: PublishWorkflow, WriteArticle, PublishArticle, EnrichIdea, DiscoverIdeas, DistributeArticle. El que concentra más trabajo es PublishWorkflow, con ocho pasos idempotentes: validar, fundamentar, generar, limpiar, persistir, indexar, crear la portada y publicar. Cada paso de E/S está envuelto así:

const result = await step.do(
  "generate-article",
  { retries: { limit: 3, backoff: "exponential" } },
  async () => env.WRITER.generate(brief)
);

D1 conserva el estado canónico (transiciones de editorial_brief.status: dispatched → drafting → published / failed). Vectorize gestiona los embeddings por bloque (Gemini-2 de 768d, con formato de recuperación asimétrico). Todas las llamadas pagadas a modelos pasan por un único punto de control, callAi(env, ctx, runner), que registra en ai_call_log los campos agent_id, workflow_instance_id e idea_id para consolidar costos, y aplica un límite diario de $20, además de otro de $1 por instancia.

Esta es la arquitectura de 6 DO que documenté antes. Para migrar a Managed Agents, lo relevante es dónde reside la lógica de reintentos. Está en dos lugares:

1. Reintentos de pasos del workflow (baratos y gratuitos si la llamada subyacente tiene éxito): interrupciones de red, límites de solicitudes y errores 5xx transitorios de proveedores externos.
2. Un bucle artesanal de evaluación y reintento en clean.ts: ejecutar Writer, ejecutar Critic y, si score < 0.75, enviar un nuevo prompt con las observaciones de Critic, hasta un máximo de 3 intentos.

Managed Agents sustituye el segundo. El primero se mantiene.

Las 280 líneas que el SDK 0.100 permite eliminar

El bucle de evaluación y reintento de src/worker/workflows/publish/clean.ts es el caso que mejor encaja con outcomes. Hoy ocupa unas 120 líneas de orquestación: invocar Writer, invocar Critic con una rúbrica almacenada en editorial_brief.rubric_md, interpretar la puntuación, bifurcar según el umbral, volver a enviar el prompt con las observaciones adjuntas como bloque de sistema y repetir hasta tres veces. El propio Critic suma otras 80 líneas de Durable Object (hooks de hibernación, SQLite por instancia para el historial de rúbricas y claves de idempotencia por intento). La consolidación de ai_call_log por intento en callAi.ts añade otras 40 líneas, porque cada intento se registra por separado y el panel los agrupa.

Los tres bloques se reducen a una sola llamada a Managed Agents:

const session = await anthropic.beta.managedAgents.sessions.create({
  thread: { messages: [{ role: "user", content: brief.body_md }] },
  outcome: {
    rubric: brief.rubric_md,
    evaluator: "claude-sonnet-4-5-20250929"
  },
  metadata: { brief_id: brief.id, workflow_instance: ctx.instanceId }
});
return { session_id: session.id, status: "pending" };

Eso es todo. La sesión se ejecuta de forma asíncrona hasta terminar en la infraestructura de Anthropic. El parámetro outcome asume el trabajo que antes hacía Critic DO: un agente evaluador independiente califica el resultado con la rúbrica y vuelve a ejecutar el agente principal hasta que aprueba.

El código que añado es una ruta en /api/admin/webhooks/managed-agents que verifica la firma whsec_…, evalúa event.type === "session.outcome_evaluation_ended" y escribe el resultado en D1.

app.post("/api/admin/webhooks/managed-agents", async (c) => {
  const raw = await c.req.text();
  const event = await anthropic.webhooks.unwrap(
    raw, c.req.header("anthropic-signature")!, c.env.WEBHOOK_SECRET
  );

  if (event.type !== "session.outcome_evaluation_ended") {
    return c.json({ ok: true });
  }

  await c.env.DB.update(editorial_brief).set({
    status: event.outcome.passed ? "published" : "failed",
    body_md: event.result.body,
    session_cost_usd: event.session.usage.total_cost_usd
  }).where(eq(editorial_brief.id, event.session.metadata.brief_id));

  return c.json({ ok: true });
});

Cuarenta líneas, con firma verificada e idempotencia basada en brief_id.

Diferencia neta: 240 líneas menos de orquestación. Un binding de Durable Object menos en wrangler.json. Un archivo de migración menos. 40 líneas más para gestionar el webhook. Un secreto más en Cloudflare Secrets Store.

El endpoint de sondeo en GET /api/admin/workflows/:id/status sigue funcionando. Ahora lee de D1 el estado de la sesión, que el webhook ya escribió, en lugar de consultar env.PUBLISH_WORKFLOW.get(id).status(). La interfaz no cambia. El panel de administración no nota la diferencia.

Una advertencia: los envoltorios de reintentos step.do se mantienen en los demás pasos de E/S. La generación de la imagen de portada, la revalidación de Vercel y la purga de caché de Cloudflare no obtienen ningún beneficio de las rúbricas de outcomes; los tres sí se benefician del almacenamiento en caché de pasos, seguro ante repeticiones, que ofrece Workflows. No conviene desmontar lo que ya funciona.

El único archivo que conservo y por qué las cuentas cambian a escala

callAi.ts se queda, junto con el límite diario de $20 y el límite de $1 por instancia. Todas las llamadas pagadas a modelos pasan por él, ya sean directas, a través de AI Gateway o mediante Managed Agents.

La razón está en el modelo de cobro. Managed Agents factura en tres ejes: tokens a precio estándar, más $0.08 por hora de sesión y $10 por cada 1000 búsquedas web. Con mi volumen —seis rutinas de publicación, un artículo por ejecución y cerca de 3 minutos por sesión—, el costo por hora de sesión suma aproximadamente $0.004 por artículo, además de los tokens. Es insignificante.

El punto de inflexión aparece cuando las sesiones se alargan. Una sesión de Anthropic Skills de 4 horas cuesta $0.32 solo en tiempo de ejecución, además de los tokens. Con 50 sesiones de ese tipo al día, son $480 al mes únicamente por horas de sesión, antes de contar tokens. Una sesión de investigación con varios pasos que queda inactiva una hora mientras espera en la cola de búsqueda web cuesta $0.08 que antes no se pagaban. El tiempo en el que una sesión espera a un servicio posterior también se factura (la documentación de Anthropic indica que el cálculo se hace al milisegundo, pero el contador sigue corriendo).

El punto de control impone un techo estricto que el panel de Managed Agents no ofrece. El panel muestra el costo de la sesión una vez consumido. callAi.ts lanza NonRetryableError en mitad del workflow, antes de iniciar la sesión, si la estimación previa supera el límite diario.

La estimación previa es conservadora:

async function estimateSessionCost(brief: Brief): Promise<number> {
  const tokenEstimate = brief.body_md.length / 3.5;
  const inputCost = (tokenEstimate / 1_000_000) * 3.0;
  const outputCost = (tokenEstimate * 1.5 / 1_000_000) * 15.0;
  const sessionHourEstimate = (brief.expected_minutes / 60) * 0.08;
  const safetyMargin = 1.4;
  return (inputCost + outputCost + sessionHourEstimate) * safetyMargin;
}

Las cifras por hora de sesión son el punto en el que más rápido fallan las arquitecturas mantenidas por una sola persona. Sin ese techo, un solo agente fuera de control —justo el comportamiento que puede fomentar el bucle de reintentos de outcome cuando la rúbrica es demasiado estricta— consume el presupuesto del día antes de que alguien lo advierta. Ya lo he visto.

Hay que conservar el punto de control. Conviene hacer que sessions.create() pase por él, registrar la estimación previa antes de iniciar la sesión y conciliarla con event.session.usage.total_cost_usd en el payload del webhook cuando la sesión termine.

La migración que todavía no haré: orquestación multiagente

La orquestación multiagente es la función estrella de Anthropic Dev Day. Un agente principal divide la tarea y encarga subtareas a subagentes especializados, cada uno con su propio modelo, prompt y herramientas. Los subagentes trabajan en paralelo sobre un sistema de archivos compartido y el agente principal reúne los resultados. En teoría, esto es exactamente lo que hace hoy mi DO Manager: distribuye trabajo en paralelo mediante RPC de DO a Writer, Discovery y Distribution, cada uno con su propio estado en SQLite, mientras R2 + D1 actúan como «sistema de archivos» compartido.

Hay tres motivos para esperar.

Uno: cambios constantes en la API. La orquestación multiagente está en versión preliminar de investigación y exige una solicitud de acceso independiente. BetaManagedAgentsSearchResultBlock acaba de llegar en la 0.102. La superficie de tipos de bloque para resultados multiagente sigue cambiando. Migrar ahora implica reescribir la integración con cada actualización del SDK durante las próximas dos o tres versiones. Los webhooks se estabilizaron en la 0.100; la parte multiagente aún está en movimiento.

Dos: el sistema de archivos compartido dura una sesión y es efímero. Dentro de una sesión de Managed Agents, el sistema de archivos compartido desaparece al terminar la sesión. R2 y D1 persisten entre todas mis rutinas, se pueden consultar desde cualquier Worker y sobreviven a una caída de sesión. Hasta que el sistema de archivos compartido sea persistente —o hasta que pueda montar R2 directamente en el entorno aislado de la sesión—, esto supone una pérdida de funcionalidad para mi carga de trabajo.

Tres: la división entre agente principal y subagentes de Anthropic impone una estructura concreta. El rol del agente principal es fijo. Mi DO Editorial actúa como líder algunos días, cuando se activa una rutina de publicación, y como par otros días, cuando la interfaz de administración envía un brief y Editorial se incorpora a mitad del pipeline. Tendría que eliminar una asimetría útil para encajar en una abstracción alojada.

Cambiaré de opinión cuando el sistema de archivos compartido sea persistente y funcione entre sesiones, o cuando R2 se pueda montar en el entorno aislado. Hoy es un cambio lateral, no una mejora.

Lista exacta para migrar del SDK 0.100 al 0.102

La migración requiere una tarde para Discovery, otra para Writer, y el resto viene después. Fija la versión 0.102.0. Registra el webhook. Elimina Critic DO. Conserva el punto de control.