Hay mucha gente escribiendo sobre cómo deberían trabajar los equipos con agentes de IA. Casi nadie lo está haciendo a escala dentro de su propia empresa.
Anthropic sí, y publicó cómo lo hace. Lo interesante no es el stack: es que casi todo lo que recomiendan tiene que ver con hábitos de equipo, no con tecnología. Escribir las cosas. Definir roles. Poner un norte. Repartir autonomía en tramos.
Suena poco espectacular hasta que lo intentas y descubres que tu empresa falla exactamente ahí. Esta guía es ese manual, aterrizado a una operación que no es Anthropic.
El punto de partida
El manual arranca de una idea sencilla: un agente es un miembro del equipo con memoria mala y acceso limitado. Todo lo que un compañero nuevo aprendería en el pasillo, un agente no lo aprende nunca. Solo sabe lo que está escrito y lo que puede alcanzar.
De ahí sale todo lo demás. Los equipos que trabajan bien con agentes no son los que tienen mejores modelos. Son los que ya tenían el hábito de dejar constancia de las cosas, y los agentes solo volvieron ese hábito obligatorio.
Los cuatro principios
1. Si no está escrito, no existe
Es la frase más útil del manual entero. Un agente no puede usar lo que se decidió en una llamada, ni lo que vive en el chat privado de dos personas, ni lo que "todos sabemos". Su mundo es lo que está escrito y accesible.
La recomendación de Anthropic es fuerte: que la información sea pública por defecto dentro de la empresa, en vez de decidir caso por caso quién ve qué. No por transparencia ideológica, sino porque decidir permisos pieza por pieza es un impuesto diario que nadie paga bien, y el resultado es un agente ciego.
Cómo se ve esto en la práctica: los canales de trabajo abiertos en vez de mensajes directos, las decisiones escritas en un documento y no en el hilo de una junta, y las notas de junta guardadas donde el agente pueda leerlas. La conversación deja de ser el registro; el documento lo es.
Empieza por: el proceso que más veces has explicado este mes. Escríbelo una vez, en un archivo, y manda ese archivo la próxima vez que te pregunten.
2. Cada quien tiene un rol, y las herramientas de ese rol
El manual insiste en tener un padrón: quién hace qué, humanos y agentes en la misma lista. Sin eso pasa algo que ya vi en varias empresas: cada persona termina corriendo su propia flotilla de agentes en privado, duplicando trabajo y partiendo el contexto en pedazos que nadie junta.
Un rol bien definido para un agente tiene tres partes: qué tareas le tocan, a qué herramientas y datos tiene acceso, y qué NO le toca. La tercera es la que casi siempre falta, y es la que evita que el agente de soporte empiece a mandar correos comerciales.
El acceso importa tanto como la descripción. Un agente con el rol de "analista de campañas" y sin acceso a la cuenta de anuncios no es un analista: es un generador de suposiciones bien escritas.
Empieza por: un documento con una fila por agente: nombre, dueño humano, tareas, herramientas conectadas, y qué está fuera de su alcance.
3. El norte lo pone un humano
Un agente con instrucciones y sin objetivo hace bien lo que le pides y nada más. Un agente que conoce el objetivo del equipo empieza a proponer trabajo que nadie le encargó, y ahí es donde deja de ser una herramienta y empieza a rendir de verdad.
La condición es que el norte lo escribe una persona y está anclado al negocio. No es una frase de misión. Es una meta lo bastante concreta como para decidir con ella: qué vale la pena y qué no.
El ejemplo que dan es de un equipo con un norte del tipo "que el arranque del producto sea más útil para quien lo usa por primera vez", y un agente que a partir de eso propuso cambios de texto que movieron el resultado. Nadie le pidió esos cambios. Se los pidió el norte.
Empieza por: escribe el norte de tu área en una sola frase, y pégala en las instrucciones de cada agente que corras. Si no puedes escribirla, ese es el problema, no el agente.
4. La confianza se reparte en tramos, no de golpe
El principio operativo del manual: la autonomía se otorga en proporción a la confiabilidad demostrada, y se amplía a propósito, no por cansancio.
El mecanismo concreto que usan es el par ejecutor-verificador: un agente hace el trabajo y otro lo revisa antes de que llegue a un humano. Funciona por la misma razón por la que un revisor externo encuentra cosas que el autor no ve. El que revisa no tiene el razonamiento que produjo el error.
Encima de eso, dos hábitos que valen oro y que casi nadie copia: meter el método de verificación dentro de la tarea —una prueba, una rúbrica, una guía de estilo contra la que cotejar— y pedir un reporte periódico de lecciones y tropiezos, para que los errores se conviertan en instrucciones nuevas en vez de repetirse.
Empieza por: escoge una tarea que hoy revisas al 100%. Define qué tendría que pasar tres veces seguidas para que la revises al 20%. Escríbelo antes de empezar.
El paso que todo mundo se salta: definir cómo se ve "bien" antes de soltar la tarea. Si tu criterio de aceptación es "que se vea bien", el agente no tiene contra qué medirse y tú te vuelves el único verificador del sistema. Una rúbrica de cinco líneas escrita antes de arrancar convierte una revisión de veinte minutos en una de dos.
El reporte de lecciones y tropiezos
De los cuatro principios, este es el que más rápido se puede copiar y el que más gente ignora. La idea: cada semana, el agente revisa su propio trabajo del periodo y produce las instrucciones nuevas que deberían existir para no repetir lo que salió mal.
Revisa todo el trabajo que hiciste esta semana en este proyecto.
Quiero un reporte corto de lecciones y tropiezos, en este formato:
1. CORRECCIONES QUE RECIBÍ
Cada vez que un humano me corrigió, cambió mi entregable o me pidió
rehacer algo. Cita la corrección textual si la tienes.
2. LA CAUSA, NO EL SÍNTOMA
Para cada corrección: ¿me faltó información, me faltó criterio, o entendí
mal la instrucción? Sé honesto; si fue una instrucción ambigua, dilo.
3. INSTRUCCIONES NUEVAS
Redacta las reglas que deberían quedar escritas para que eso no vuelva a
pasar. Escríbelas listas para pegar en el archivo de instrucciones del
proyecto: específicas, verificables, en una línea cada una.
4. LO QUE NO SE ARREGLA CON UNA REGLA
Qué de esto era un problema de acceso, de datos faltantes o de una
decisión que un humano no ha tomado. No inventes una regla para eso;
nómbralo y ya.
Máximo una página. Si esta semana no hubo tropiezos que valgan la pena,
dilo en una línea.Lo que sale de ahí se pega en el archivo de instrucciones del proyecto y se vuelve permanente. Es la diferencia entre un agente que empieza de cero cada lunes y uno que acumula oficio.
Cómo se ve en una empresa que no es Anthropic
Tomemos una operación de contenido con tres marcas, que es un caso que veo seguido. El manual se traduce así:
- Escrito: el criterio editorial de cada marca vive en un archivo, no en la cabeza del que lleva más tiempo. Incluye lo que la marca no dice, que suele ser más definitorio que lo que sí dice.
- Roles: un agente que arma el reporte semanal de métricas, con acceso de solo lectura a la herramienta de analítica y prohibición explícita de publicar. Un agente distinto que redacta borradores. No el mismo.
- Norte: "que cada marca reporte lo suyo sin doble conteo entre plataformas" es un norte útil. "Crecer en redes" no lo es, porque no te ayuda a decidir nada.
- Confianza por tramos: el reporte se revisa completo el primer mes. Cuando dos meses seguidos no tiene correcciones, se revisa por muestreo. Los borradores de publicación nunca dejan de revisarse, porque el costo de un error ahí es público.
Fíjate en el último punto. El manual no dice "confía en todo eventualmente". Dice que la autonomía sube donde el error es barato y reversible, y se queda quieta donde el error se ve desde afuera.
El error que comete todo el mundo
Casi todos empiezan por el lado equivocado: montan el agente y luego se preguntan por qué entrega genérico. La secuencia del manual es al revés. Primero el material escrito, luego el rol y el acceso, luego el norte, y hasta el final la autonomía.
Si tuvieras que quedarte con un solo movimiento de los cuatro, quédate con el primero. Un equipo con las decisiones escritas y accesibles funciona mejor incluso sin agentes. Un equipo con agentes y sin nada escrito solo produce material promedio más rápido.
Y antes de montar cualquier cosa, revisa si de verdad necesitas un agente. Muchas de las tareas que la gente quiere agentificar son un flujo fijo con dos pasos, y ahí un agente solo agrega variabilidad. Esa decisión está en agente o workflow, y los límites que le tienes que poner desde el día uno, en la plantilla de guardrails.