# Anthropic y su guía para automatizar una empresa con agentes: lo que dice de verdad el PDF

Me descargué el PDF esperando un folleto comercial. Treinta páginas después, la frase que más veces había subrayado era una que dice, con todas sus letras, que no me monte nada complicado: «*Don't over-engineer*». Viniendo de un documento que circula estos días bajo el titular de «la guía de Anthropic para automatizar tu empresa entera», el contraste tiene su gracia.

Eso es lo que pasa cuando lees la fuente en vez del hilo que la resume: el titular vende autonomía total; el documento, capítulo tras capítulo, vende contención.

Llevo veinticinco años en esto y dirijo un equipo que mantiene un ERP de facturación de telecomunicaciones, un SaaS de control horario y una plataforma de bots conversacionales con RAG. Cuando alguien me dice «automatiza tu empresa entera», mi primer pensamiento no es la productividad: es qué pasa la noche que el agente decida que el ciclo de facturación de marzo necesita un ajuste creativo. Así que me la he leído entera, con el artículo de ingeniería original al lado.

## Dos documentos con el mismo nombre

Lo primero, porque genera una confusión tremenda: hay **dos textos distintos** de Anthropic que se llaman casi igual, y la gente los cita indistintamente.

El primero es [**Building effective agents**](https://www.anthropic.com/engineering/building-effective-agents), el artículo del blog de ingeniería publicado el **19 de diciembre de 2024** y firmado por **Erik S. y Barry Zhang**. Es el que ha marcado el vocabulario de toda la industria: de ahí salen los seis patrones que todo el mundo dibuja en diapositivas. Detalle que casi nadie menciona: hoy arranca con un aviso del propio fabricante diciendo que buena parte del panorama de herramientas que describe **ha cambiado desde diciembre de 2024**. El texto canónico lleva puesta su etiqueta de caducidad. Los patrones aguantan; el andamiaje de alrededor, no.

El segundo es el que ha desatado el revuelo: **«Building Effective AI Agents: Architecture Patterns and Implementation Frameworks»**, un eBook de 30 páginas maquetado en InDesign, con fecha de creación del PDF del **2 de diciembre de 2025**. Se descarga aquí:

**[→ Página de descarga de la guía (resources.anthropic.com)](https://resources.anthropic.com/building-effective-ai-agents)**

La landing lo etiqueta como «eBook» y pide un formulario. Digo «pide» y no «exige» porque el PDF vive en una URL pública de su CDN y responde 200 a un `curl` sin cookies; me lo bajé así antes de rellenar nada. Ahí está [el PDF directo](https://resources.anthropic.com/hubfs/Building%20Effective%20AI%20Agents-%20Architecture%20Patterns%20and%20Implementation%20Frameworks.pdf). Y un apunte, porque he leído por ahí que viene con vídeo: **no he encontrado ninguno**, ni en la landing ni en la página posterior a la descarga. Lo único audiovisual es un enlace del último capítulo a una charla, «Building the future of agents with Claude», de la que no he podido confirmar duración ni ponentes desde las páginas oficiales.

Está escrito para otro lector: no para quien va a teclear el bucle, sino para quien aprueba el presupuesto. No lo invalida; de hecho es sorprendentemente contenido para el género. Aunque mi copia **tiene un párrafo roto**: en la página 5, la frase «*A European equipment manufacturer with over €10 billion in revenue mapped out their agentic AI strategy and found*» se corta en seco y salta a una lista cuya primera viñeta empieza a media frase. Lo comprobé renderizando la página, por si era cosa del extractor: no, está así. Texto desbordado en la maqueta. En una guía sobre construir sistemas fiables, da para una sonrisa.

Su capítulo 2 es un desfile de clientes con números que hay que leer sabiendo lo que son: cifras del proveedor sobre sus propios clientes, sin metodología ni línea base. **Coinbase** es el caso estrella, con soporte agéntico que maneja miles de mensajes por hora al **99,99% de disponibilidad** y entre **35 y 50 aplicaciones internas**. **Tines** declara **100x de mejora en time-to-value**; **Gradient Labs**, **80-90% de resolución** en servicios financieros; **Intercom** hasta un **86%** con Fin, y un **51% recién instalado, sin personalizar**; **Inscribe** baja la revisión de fraude de 30 minutos a **90 segundos**. Y **Augment Code** cuenta un proyecto terminado en dos semanas que su CTO estimaba en cuatro a ocho meses, que resume el género: puede ser cierto y no decirte nada, porque la estimación de un CTO no es una unidad de medida. Los leo como señal de que esto se despliega en serio, y como recordatorio de algo que la guía no subraya: **todos los casos con métrica limpia son casos donde el resultado se verifica solo**.

## La línea que lo sostiene todo: workflow o agente

Si de todo esto solo te llevas una idea, que sea esta. Es la columna vertebral de los dos documentos y la que casi todo el mundo se salta.

Anthropic mete todo bajo el paraguas de *sistemas agénticos*, pero traza dentro una distinción que no es cosmética:

- Los **workflows** son «*systems where LLMs and tools are orchestrated through predefined code paths*»: los LLM y las herramientas se orquestan mediante **rutas de código predefinidas**. El camino lo pusiste tú; el modelo rellena huecos.
- Los **agentes** son «*systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks*»: el modelo **dirige dinámicamente su propio proceso** y su uso de herramientas.

La diferencia no está en si hay IA, ni en cuántas llamadas haces, ni en si le has puesto una cara y un nombre bonito. Está en **quién decide el siguiente paso**. Si lo decide tu `switch`, es un workflow. Si lo decide el modelo, es un agente. Y esa frontera es exactamente la frontera de tu capacidad de predecir el sistema, presupuestarlo y explicárselo a un auditor.

Va mi primera queja. El eBook mantiene la línea en la teoría —dice que los flujos de trabajo, «*unlike the dynamic behavior of individual agents*», son **predefinidos y estáticos**— pero la difumina en la nomenclatura: los mismos pipelines deterministas pasan a titularse «flujo secuencial multiagente», «flujo paralelo multiagente», «flujo evaluador multiagente». Misma arquitectura, sustantivos inflados. Un encadenamiento de tres llamadas con un `if` en medio no se convierte en un sistema multiagente porque le llames agente a cada llamada. Y la distinción importa: **un workflow lo depuras leyendo tu código; un agente lo depuras leyendo transcripciones**. No es el mismo oficio ni cuesta el mismo dinero.

## Los seis patrones, uno a uno

El artículo de ingeniería los presenta en complejidad creciente, partiendo del **LLM aumentado**: un modelo con recuperación, herramientas y memoria. Ese es el ladrillo; todo lo demás son formas de apilarlo. El eBook se salta ese ladrillo y arranca en el agente único, que es empezar la casa por el primer piso.

### 1. Encadenamiento de prompts

Descompone una tarea en pasos secuenciales donde cada llamada procesa la salida de la anterior. La pieza clave, la que todo el mundo omite al dibujarlo, es el **gate**: una comprobación programática entre pasos que verifica que el proceso sigue por buen camino. Código de verdad, no otra llamada al modelo.

Cuándo usarlo: cuando la tarea se descompone limpiamente en subtareas fijas, y el objetivo es **cambiar latencia por precisión** haciendo que cada llamada sea más fácil. Sus ejemplos: generar un texto de marketing y luego traducirlo; escribir un esquema de documento, validar que cumple criterios, y solo entonces escribir el documento.

El eBook lo rebautiza **flujos secuenciales** y añade cuándo evitarlo: si el proceso tiene tan pocas etapas que un solo agente lo resuelve, si los pasos necesitan colaborar en vez de pasarse el testigo, o si el flujo **requiere retroceder o iterar**. Esa última es la buena: un pipeline secuencial que necesita volver atrás no es un pipeline, es un bucle mal disfrazado.

En mi mundo esto es el alta de un cliente: extraer los datos del contrato firmado (PDF escaneado, que en telecomunicaciones el papel es eterno), **validar contra el ERP** —el CIF existe y no está duplicado, el IBAN pasa el dígito de control, la tarifa está vigente— y solo si el gate da verde, generar la orden de provisión. El LLM hace lo que hace bien; la validación la hace código aburrido que puedo testear. Si el gate falla, a la cola de un humano, y ahí se acaba la magia.

### 2. Enrutado

Clasifica la entrada y la dirige a una tarea especializada. Permite separar responsabilidades y escribir prompts específicos; sin él, optimizar para un tipo de entrada degrada el rendimiento en los demás.

Cuándo usarlo: categorías bien diferenciadas, **y donde la clasificación se pueda hacer con precisión**. Con un matiz que agradezco: dicen explícitamente que el clasificador puede ser un LLM «*or a more traditional classification model/algorithm*». La parte de enrutar tiene permiso oficial para no llevar IA dentro, y en mi experiencia la mitad larga del enrutado real de una empresa es una tabla de correspondencias y cuatro expresiones regulares: determinista, cuesta cero y no alucina. El otro uso que citan es económico: lo fácil y frecuente a un modelo pequeño y barato, lo difícil e inusual a uno más capaz. La optimización más obvia y la que más gente se deja sin hacer.

Mi caso es la entrada de incidencias. «No me entran llamadas» no es lo mismo que «quiero la factura de julio» ni que «quiero portabilidad»: cada una vive en un sistema distinto, con un prompt, unas herramientas y un riesgo distintos. Meterlo todo en un agente omnisciente con veinte herramientas es la receta para que un día te conteste sobre portabilidades leyendo el manual de la centralita.

### 3. Paralelización: seccionado y votación

Dos variantes, distintas de verdad: **seccionado** (*sectioning*) parte la tarea en subtareas independientes que corren a la vez; **votación** (*voting*) corre **la misma** tarea varias veces para obtener salidas diversas.

Cuándo usarlo: cuando las subtareas se pueden paralelizar por velocidad, o cuando necesitas varias perspectivas para tener más confianza. Y una observación de las más aprovechables: en tareas con múltiples consideraciones, los modelos **rinden mejor cuando cada consideración se trata en una llamada separada**. Ejemplo de seccionado: guardarraíles, donde un modelo atiende la consulta mientras otro la examina en busca de contenido inapropiado —y señalan que funciona mejor que pedirle a la misma llamada las dos cosas—. De votación: revisar código con varios prompts distintos, y evaluar contenido con **umbrales de voto** para equilibrar falsos positivos y negativos.

El eBook aporta aquí su mejor lista de contraindicaciones: no paralelices cuando los agentes necesiten construir sobre el trabajo del otro, cuando el orden importe, cuando no haya estrategia clara de resolución de conflictos, o —esta es la mía— cuando los agentes **no puedan coordinar de forma fiable cambios sobre estado compartido o sistemas externos** ejecutándose a la vez.

Traducido: paraleliza lo que quieras mientras sea de lectura. En cuanto dos ramas escriben en la misma base de datos de facturación, has reinventado las condiciones de carrera, pero con actores no deterministas y sin transacciones. Eso no es un patrón de arquitectura, es una noche en vela. El seccionado sí me convence para el bot: una llamada responde al cliente y otra, en paralelo, comprueba que no le promete un descuento que nadie ha autorizado.

### 4. Orquestador-trabajadores

Un LLM central descompone la tarea dinámicamente, la delega en LLM trabajadores y sintetiza los resultados. La distinción con la paralelización es sutil y crucial: es topográficamente parecido, pero aquí **las subtareas no están predefinidas**, las determina el orquestador según la entrada concreta. Por eso el ejemplo canónico es el código: no sabes de antemano cuántos ficheros hay que tocar ni qué cambiar en cada uno.

El eBook lo desarrolla como **sistemas jerárquicos o supervisores** y añade el detalle que más me sirve: los subagentes **se tratan como herramientas**, y el supervisor usa el mecanismo normal de llamada a herramientas para decidir a cuál invoca. Los subagentes pueden tener a su vez subagentes, y el supervisor ni se entera: solo habla con el jefe de equipo de ese grupo. Es el modelo que uso a diario en Claude Code y del que ya [escribí en su momento](/post/subagentes-en-claude-code); funciona por la misma razón que en una empresa: **quien coordina no necesita saber cómo se hace el trabajo, solo a quién dárselo y cómo se ve un buen resultado**.

Dónde lo pondría: en el diagnóstico de una incidencia VoIP compleja. «Al cliente X se le cortan las llamadas por la tarde» es una pregunta cuya profundidad no sabes hasta que rascas: igual hay que mirar trazas SIP, o el estado del troncal, o los CDR de esa franja, o todo a la vez, o nada porque cambiaron el router. No puedes predeterminar los pasos, y es donde el patrón se paga solo: ese trabajo hoy se lo come un ingeniero senior abriendo siete pestañas.

### 5. Evaluador-optimizador

Una llamada genera la respuesta y otra evalúa y da feedback, en bucle, hasta que se cumple el criterio.

Cuándo usarlo: cuando hay **criterios de evaluación claros** y el refinamiento iterativo aporta valor medible. Dan dos señales de buen encaje: que las respuestas mejoren demostrablemente cuando un humano articula su crítica, y que **el modelo sea capaz de producir esa misma crítica**. Si la segunda no se cumple, tienes un bucle caro que gira sin mejorar nada. Sus ejemplos: traducción literaria y búsquedas complejas donde el evaluador decide si hacen falta más rondas.

El eBook añade una métrica —en su ejemplo de documentación de API el proceso corre típicamente **entre 2 y 4 ciclos**— y una lista larga de cuándo evitarlo: cuando la calidad a la primera ya cumple, cuando los criterios son subjetivos, en **aplicaciones en tiempo real**, en tareas rutinarias simples, con presupuesto de tokens ajustado, o cuando existe una solución determinista. Esa última merece enmarcarse: «*Avoid when deterministic solutions exist*». Si el problema tiene solución determinista, no le pongas dos modelos discutiendo delante.

En mi caso el veto es la latencia: mi plataforma de bots responde en una conversación viva, y dos a cuatro ciclos con dos modelos es una eternidad para quien mira los tres puntitos. Donde sí lo usaría es en lo asíncrono, como el comunicado de un incidente, donde el criterio *sí* es claro —no prometas plazos, no atribuyas culpas, di qué está afectado y qué no— y nadie espera en tiempo real.

### 6. El agente autónomo

El que da los titulares. La descripción de Anthropic es deliberadamente antiheroica: son «*typically just LLMs using tools based on environmental feedback in a loop*». Típicamente, solo modelos usando herramientas a partir del feedback del entorno, en bucle.

El agente arranca con una orden del humano; una vez clara la tarea, planifica y opera de forma independiente. Durante la ejecución es **crucial que obtenga «ground truth» del entorno en cada paso** —el resultado de una herramienta, la salida de ejecutar código— para valorar su progreso. Y contemplan condiciones de parada, como un máximo de iteraciones, «*to maintain control*».

Cuándo usarlo: problemas abiertos donde es difícil o imposible predecir cuántos pasos harán falta y no puedes fijar el camino. Con una condición escrita sin adornos: **tienes que tener cierto nivel de confianza en su toma de decisiones**, y son ideales para escalar tareas *en entornos de confianza*. Y el aviso: la autonomía significa **costes más altos y potencial de errores que se componen**. El eBook añade la contraindicación más rotunda del documento: evítalo «*when you need to get the perfect answer on the first try, 100% of the time*».

Y aquí está la idea que más me llevo. Fíjate en qué tienen en común los dos ejemplos que Anthropic pone de agentes propios: resolver tareas de SWE-bench y el uso del ordenador. En su apéndice sobre agentes de código lo dicen sin rodeos: funcionan porque **las soluciones de código son verificables mediante tests automáticos** y el agente puede iterar usando los resultados como feedback.

Ahí está todo. **El agente autónomo funciona donde existe una verdad de referencia barata, rápida y automática.** El código la tiene: ejecutas los tests y sabes. Por eso los agentes de programación son el caso de éxito, y por eso [llevo tiempo trabajando así](/post/claude-code-max-20x-vs-codex).

Mi ERP de facturación no la tiene. Si un agente «corrige» una tarificación mal aplicada, no hay ninguna suite que se ponga roja: la verdad llega treinta días después en forma de reclamación, o no llega nunca, porque el error va a favor de la casa y nadie lo mira. Un bucle de agente sin ground truth no es un agente autónomo: es un generador de cambios plausibles con permisos de escritura. Y esa frase, en un sistema de facturación, es la definición de incidente.

## Lo que el eBook añade por su cuenta

**Sistemas colaborativos.** Frente a lo jerárquico, agentes que se comunican entre pares y negocian roles dinámicamente; a veces llamados *swarm* o federados, con variantes de chat grupal, coordinación por eventos y **arquitecturas de pizarra** (un repositorio compartido que hace de memoria colectiva). Y acto seguido, para su crédito, listan el problema: la comunicación constante dispara coste y complejidad, y estos sistemas tienen **comportamientos emergentes que surgen sin haberlos programado**, donde cambios pequeños alteran el resultado de forma impredecible. Pienso en lo que ya conté sobre [las arquitecturas de muchas personalidades](/post/agency-agents-273-personalidades): fascinante de ver, infierno de depurar, y quien te venda lo primero sin lo segundo no lo ha llevado a producción.

**Skills.** Paquetes modulares de capacidad —conocimiento de dominio, flujos, integraciones— que el agente invoca cuando los necesita, en vez de meter toda la experticia en el prompt. De ahí sale una de las recomendaciones más sensatas del documento: **antes de escalar a multiagente, plantéate si añadir skills especializadas a tu agente único te da la precisión que buscas de forma más eficiente**. Es el instinto que me llevó a estandarizar [mis ficheros de contexto](/post/guia-completa-claude-md): la mayoría de los problemas que la gente resuelve añadiendo agentes se resuelven mejor añadiendo contexto bien organizado.

**Gestión de contexto**, que es carne operativa que el artículo de 2024 no tiene. Reconocen que el contexto del orquestador crece más de lo que un agente puede manejar, con desbordamiento de ventana, razonamiento degradado y fallos de coordinación. Sus mitigaciones: *context editing* para limpiar automáticamente llamadas y resultados obsoletos al acercarse a los límites, memoria en ficheros que persiste entre sesiones, y —lo más práctico— que **tus herramientas incluyan paginación, filtrado y truncado con valores por defecto sensatos**, limitando las respuestas a «*something like 25,000 tokens*». Si tu herramienta `consultar_cdr` puede devolver cuatro millones de registros, tu agente no tiene un problema de inteligencia: tiene un problema de fontanería que le has creado tú.

**Patrones emergentes**, marcados como experimentales con una honestidad que agradezco: de la **generación dinámica de agentes** escriben que «*no production systems currently implement true dynamic creation*», y de las **arquitecturas de red**, que el enjambre supera «*slightly*» al supervisor. Ligeramente. Esa palabra hace mucho trabajo.

## Cuándo Anthropic dice que no

Si tuviera que quedarme con veinte líneas de los dos documentos, serían estas, y no son las que se citan en LinkedIn.

El artículo de ingeniería lo dice al principio: recomiendan encontrar la solución más simple posible e incrementar complejidad solo cuando haga falta, y añaden que **eso puede significar no construir un sistema agéntico en absoluto**. Y rematan: para muchas aplicaciones, optimizar una única llamada al LLM con recuperación y ejemplos en contexto **suele ser suficiente**. Léelo otra vez. Es una empresa que vende tokens diciéndote que a lo mejor con una llamada bien hecha lo tienes.

Sobre frameworks es igual de directo: ayudan a empezar, pero **añaden capas de abstracción que ocultan los prompts y las respuestas reales, dificultando la depuración**. Su consejo es empezar usando las APIs directamente, y si usas un framework, **entender el código que hay debajo**. Me sonó a casa: es la misma razón por la que [este blog no va en Docker](/post/por-que-mi-blog-no-va-en-docker).

Y las contraindicaciones que he ido citando patrón por patrón comparten forma: **casi todas se reducen a que el problema tenía estructura y la has tirado a la basura**. La complejidad agéntica es lo que pagas por no saber la forma del problema; si la sabes, no la pagues.

El eBook lo sistematiza en un marco que anuncia «tres dimensiones clave» y «las tres preguntas críticas»... y a continuación enumera cuatro. Lo dejo ahí, junto al párrafo desbordado de la página cinco. Las cuatro son mejores de lo que su envoltorio sugiere:

- **Cuánto control necesitas.** Requisitos altos —cumplimiento regulatorio, transacciones financieras, operaciones críticas— llevan a agente único o flujos secuenciales; moderados, a lo jerárquico; bajos —investigación, brainstorming— hacen viable lo colaborativo, porque ahí «*the unpredictability of collaborative agents becomes a feature, not a bug*».
- **Cómo de complejo es tu dominio.** Uno, agente único. Varios pero predecibles, flujos secuenciales o paralelos. Complejos y abiertos, multiagente. Con el detalle de que, según su investigación, los agentes individuales **caen en picado cuando hay dos o más dominios distractores**.
- **Qué restricciones de recursos tienes.** Aquí el número que debería abrir el documento en vez de cerrarlo: los sistemas multiagente consumen **entre 10 y 15 veces más tokens** que un agente único. Y otro igual de terrenal: un agente único se despliega en **semanas**; un multiagente **tarda meses**.
- **Si necesitas experticia profunda de dominio.** Con flujos ya establecidos, agente único con skills; varios dominios que deban coordinarse, multiagente con skills repartidas.

La primera gobierna mi trabajo, y su argumento es el que llevo años intentando explicar en reuniones sin conseguirlo tan bien: si necesitas explicar exactamente por qué el sistema tomó una decisión ante auditores, reguladores o dirección, quieres comportamiento predecible y trazable. Y lo aterrizan: un agente único aprobando préstamos con criterios claros **es mucho más fácil de auditar que un sistema multiagente donde tres modelos distintos colaboraron en la recomendación**. Cambia «préstamos» por «abono en factura» y tienes mi vida. Cuando un cliente reclama y acabas explicando por qué se le cobró lo que se le cobró, «los tres modelos lo consensuaron» no es una respuesta: es un problema nuevo.

Cierran con los **patrones híbridos**, y el que más me gusta es **agente simple con escalado a multiagente**: lo rutinario lo resuelve lo barato y solo los casos raros disparan la maquinaria cara.

## Implementación: las herramientas son la parte difícil

El apéndice 2 del artículo de 2024 es la mejor página que ha escrito Anthropic sobre esto, y no aparece en el eBook. Va de que **las definiciones de herramientas merecen tanta ingeniería de prompt como el prompt principal**.

El argumento: hay varias formas de especificar la misma acción —un cambio en un fichero puede ser un diff o una reescritura completa— y aunque en ingeniería esas diferencias son cosméticas, **algunos formatos son mucho más difíciles de escribir para un modelo**: un diff exige saber cuántas líneas cambian *antes* de escribir el código nuevo, y el código dentro de JSON obliga a escapar saltos de línea y comillas. De ahí que recomienden mantener el formato **cerca de lo que el modelo ha visto de forma natural en internet** y eliminar la sobrecarga de llevar cuentas exactas o escapar todo lo que escribe.

Y la analogía que da nombre a la cosa: piensa cuánto esfuerzo se invierte en interfaces persona-ordenador (HCI) y planea invertir otro tanto en la **interfaz agente-ordenador (ACI)**. Una buena definición incluye ejemplos de uso, casos límite, requisitos de formato y **límites claros respecto a otras herramientas**; escribe las descripciones de parámetros como escribirías «*a great docstring for a junior developer on your team*». Y aplica **poka-yoke**: cambia los argumentos para que sea más difícil equivocarse.

Cierran con la anécdota que lo resume: construyendo su agente para SWE-bench dedicaron **más tiempo a optimizar las herramientas que al prompt general**. El modelo fallaba con rutas relativas cuando el agente se había movido fuera del directorio raíz, así que cambiaron la herramienta para **exigir siempre rutas absolutas**, y a partir de ahí el uso fue impecable. Eso no es una anécdota de IA: es diseño de API de toda la vida. Si tu interfaz permite un estado ambiguo, alguien lo va a alcanzar. Antes ese alguien era un becario a las siete de la tarde; ahora es un modelo, a mil llamadas por hora.

## Diseñar herramientas es diseñar permisos

Aquí es donde los dos documentos se quedan cortos y donde está el trabajo de verdad para quien responde de sistemas en producción. Anthropic habla de herramientas como capacidad: qué puede hacer el agente. Lo que casi no se dice es que **el catálogo de herramientas es el perímetro de permisos, y no hay otro**. Un agente no tiene los permisos que tú creas: tiene la unión de lo que sus herramientas pueden ejecutar, combinada de todas las formas que se le ocurran, que serán más de las que se te ocurran a ti.

Un agente con una herramienta `ejecutar_sql` tiene todos los permisos del usuario de esa conexión. Todos. Da igual lo que ponga en el prompt del sistema; el prompt es una sugerencia educada, no un control de acceso. Un agente con `emitir_abono(cliente, importe, motivo)` con tope duro validado en el servidor, registro de auditoría previo a la ejecución y lista blanca de motivos tiene un permiso, uno, acotado y contable. Es el poka-yoke que ellos aplican a la ergonomía, llevado al radio de explosión: **no diseñes la herramienta solo para que sea difícil equivocarse, diséñala para que equivocarse sea barato**.

Corolario después de bastantes años: un agente sin restricción de herramientas es un incidente esperando fecha. Y las restricciones que valen no viven en el prompt: viven en el servidor, en el usuario de base de datos, en el tope de importe, en el `dry-run` por defecto y en el registro que se escribe *antes* de actuar. Es la razón por la que me interesó [el modelo de gateway de Openbot](/post/openbot-ai-coworkers-open-source): el sitio correcto para decidir si una acción se ejecuta no es dentro del agente.

Y encima está la asimetría económica, que nadie mete en el business case. Todas las cifras del capítulo 2 miden lo que se ahorra cuando el agente acierta; ninguna mide **lo que cuesta el peor error**. Un agente que resuelve bien el 95% de las incidencias de nivel 1 y una vez al mes cancela la línea equivocada de un cliente empresarial no ha ahorrado nada: ha convertido coste operativo predecible en riesgo comercial impredecible, que es mucho más caro porque no aparece en ninguna hoja de cálculo hasta que aparece en un correo del director general.

## Dónde pongo yo la línea

El reparto en mi propia casa. Adelante con el triaje VoIP en solo lectura, los agentes de código —Anthropic recuerda que, aunque los tests verifiquen la funcionalidad, **la revisión humana sigue siendo crucial**— y el alta de clientes como workflow con gate, que ni siquiera lleva un agente dentro.

Ni de broma el **cierre de facturación**: mensual, acumulativo, sin verdad de referencia inmediata y con los errores descubriéndose tarde y en casa del cliente. Ahí quiero código determinista, tests y un informe de diferencias contra el mes anterior que mire una persona. Tampoco las **portabilidades y la provisión de líneas**, con contrapartes externas y ventanas regulatorias que si se pasan, se pasan: un error no es un reintento, es una portabilidad perdida y, según el caso, una reclamación ante el regulador.

Y sobre todo, **nada que escriba en el control horario**. Esta merece párrafo aparte porque no es una decisión técnica. En España el registro de jornada es un documento con valor legal: tiene que ser fiable, no manipulable, y conservarse a disposición de la Inspección de Trabajo. Un agente «corrigiendo» fichajes no es una automatización con riesgo de bug: es alteración de un registro con efectos jurídicos, con nosotros como responsables. Puedo poner IA a **detectar anomalías** y avisar a una persona; jamás a modificar el asiento.

Mi reparto no sigue el eje «qué tarea es más compleja» sino otro: **quién paga el error y cuándo se entera**. Donde el error es barato, reversible y visible al momento, adelante. Donde es caro, irreversible o silencioso, código aburrido y una persona firmando.

## Lo que la guía no cuenta

Es un buen documento y por eso se le puede pedir más. Cuatro huecos, en orden de gravedad para quien firma el proyecto.

**El coste real, en euros.** El 10-15x es un multiplicador sobre una cifra que nadie da. Falta lo que de verdad pregunta un director técnico: cuánto cuesta una tarea resuelta, cómo se presupuesta la varianza —un agente puede tardar tres pasos o cuarenta— y qué pasa con la tarifa cuando el modelo que integraste se deprecia. Todo esto vive sobre una API de terceros con precios que no controlas, y sobre eso [ya he escrito lo que pienso](/post/alquilado-cuando-tu-herramienta-es-una-suscripcion): construir tu operación sobre una capacidad alquilada es una decisión estratégica, no una línea de gasto.

**La responsabilidad.** La guía menciona *compliance frameworks* en una viñeta —una de las del párrafo roto, mira tú— y la auditoría como propiedad deseable. Pero no toca la pregunta que sale el primer día en cualquier empresa regulada: cuando el agente emite un abono de tres mil euros que no tocaba, ¿quién responde? La respuesta real es «tú», y eso debería cambiar el diseño, no solo el seguro.

**El efecto sobre el equipo humano.** El que menos se dice y el que más me preocupa como director. Si automatizas el 85% del nivel 1, has eliminado el terreno donde se forman los que llegan a nivel 2: el soporte de primera línea es aburrido y es también donde se aprende cómo funciona el sistema de verdad. Y hay un segundo efecto, documentado en aviación mucho antes de que existiera esto: el humano que revisa salidas correctas todo el día deja de revisar de verdad hacia la tercera semana. Poner «con supervisión humana» en una diapositiva es gratis; que siga siendo real a los seis meses ninguna guía de arquitectura lo resuelve.

**La observabilidad concreta.** Describen bien el problema —cuando un agente falla no hay stack trace que mirar— y ahí se paran. Ni una herramienta, ni un formato de traza, ni cómo reproduces una ejecución de hace tres semanas cuando el modelo ya no es el mismo modelo. Esa última es la incómoda: **tu sistema depende de un artefacto que el proveedor puede cambiar bajo tus pies**. Es la versión operativa de lo que vengo contando sobre [el capital en la nube](/post/tecnofeudalismo-iii-capital-en-la-nube): la infraestructura crítica es de otro, y las condiciones también.

## Qué me llevo

La guía no te enseña a automatizar tu empresa entera. Te explica, con paciencia y con más datos de los que esperaba, **por qué probablemente no deberías intentarlo todavía**. Y por eso merece la pena leerla.

Su mejor frase es la menos agéntica de todas: «*The best architecture is the simplest one meeting today's requirements while providing a path to tomorrow's capabilities*». La mejor arquitectura es la más simple que cumple los requisitos de hoy dejando camino a los de mañana. Eso no lo ha escrito la moda de los agentes; lleva escrito en el oficio desde antes de que yo empezara.

Si vas a dedicarle tiempo: **léete el artículo de 2024 entero, apéndices incluidos**; y del eBook, salta a las secciones de *when to avoid* y al marco de decisión. Luego ordena tus procesos, no por lo impresionante que quedaría automatizarlos, sino por dónde tienes verdad de referencia barata y rápida y por lo que cuesta tu peor error.

Sigo pensando que el titular es exagerado. Pero el documento que hay debajo no lo es en absoluto: es prudente, es concreto en las contraindicaciones y contiene, escrita por quien vende la tecnología, la advertencia que más falta hace ahora mismo. Que a lo mejor con una llamada bien hecha lo tienes.