Agentes con nombre · mazos

Dos formas de poner nombres, y qué haría cada una

La A entra hoy y cuesta un archivo por rol. La B es el equipo con dirección propia, y hay que construirla.

Las dos vías

La A es el agente repartiéndose el trabajo. La B es el cliente teniendo varios agentes.

Vía A · roles dentro de una corrida una corrida, un contenedor principal revisor solo lectura analista lee los adjuntos hablan solo con el principal y mueren con el pedido orquesta el CLI · no existen en nuestra base Vía B · agentes con nombre propio el mismo contenedor, una carpeta por agente finanzas carpeta propia bandeja carpeta propia backend de mazos firma, destinos permitidos y registro siguen existiendo cuando nadie habla orquesta mazos · cada mensaje pasa por nuestro código
La caja del medio es la diferencia entera. En la vía A el intercambio ocurre dentro del CLI y no lo vemos. En la vía B cada mensaje pasa por nuestro backend.
Vía A · roles dentro de una corrida un archivo por rol
Qué es
Ayudantes temporales con una tarea cada uno. Contestan al principal y desaparecen.
Para el cliente
Nada cambia por fuera: escribe lo de siempre y recibe una respuesta mejor.
Coste
Un archivo de texto. Funciona hoy y no abre ningún canal.
Vía B · agentes con nombre por construir
Qué es
Agentes que existen siempre, con su memoria, sus permisos y su dirección.
Para el cliente
Cambia a quién le escribe: «finanzas, ¿cómo vamos de tesorería?».
Coste
Enrutado y parada, más una corrida entera por mensaje.

Vía A · roles dentro de una corrida

Un archivo por rol, y funciona hoy

Un pedido por dentro

contenedor del cliente: su carpeta, su memoria, sus credenciales «Repasa el correo de esta mañana» Agente principal es el único que habla con el cliente bandeja propone la lista del día revisor la contrasta contra la bandeja crm quién es cada remitente la segunda vuelta, toda por el principal revisor a principal: «faltan dos del hilo de ayer» principal a bandeja: «recupéralos y devuélveme la lista» bandeja a principal: «los quité por antigüedad, corregido» vuelve la lista final
Los hijos no se hablan entre ellos. El CLI solo les deja hablar con quien los lanzó, así que la corrección es una segunda vuelta que reparte el principal. Al cliente le llega una sola respuesta, ya contrastada.

Qué gana, y dónde aplica

Hoy: un agente, una pasada mira cuarenta correos y propone seis se deja dos de un hilo largo y nadie vuelve a mirarlo Con dos roles: dos pasadas bandeja propone seis revisor los contrasta contra el buzón salen ocho, y esos ocho son los que llegan el mismo pedido con el doble de miradas, sin infraestructura nueva y sin canal nuevo Y el mismo patrón sirve en: · repaso del correo de la mañana · redactar un correo delicado · leer una factura y cuadrarla · analizar un informe financiero · preparar una reunión · quién es este remitente · sacar datos de un PDF largo · armar un informe o un Excel · buscar un hilo en todas las cuentas · contrastar respuestas del trimestre · revisar un cambio antes de subirlo · investigar un fallo por hipótesis
El repaso de correo ya falló así una vez, por recortar de cabeza una lista larga.

Los roles, con nombre

revisor vuelve a mirar una lista antes de que salga y devuelve lo que falta gmail_search, gmail_read corrector repasa destinatarios, copias y tono del borrador antes de que se envíe gmail_find_address extractor saca los datos de una factura o de un PDF de cien páginas finanzas_extract_document cuadrador cruza esas cifras contra lo que hay registrado en Holded holded_list_invoices dossier dice quién es un remitente o una empresa antes de contestarle kg_dossier, kg_network rastreador barre Gmail, Drive y el grafo a la vez y devuelve una sola lista gmail_search, drive_list_files preparador junta agenda, ficha y últimos correos para una reunión calendar_list_events, fireflies maquetador convierte lo aprobado en informe, Excel o dashboard skills mazos-docx, mazos-xlsx sintetizador resume un hilo largo en lo que hay que decidir skill summarize
Ninguno puede enviar nada: quien envía sigue siendo el principal, así que un rol equivocado cuesta una respuesta peor, nunca un correo que no debía salir.

Y el propio cliente puede pedirse un rol

Lo pide por WhatsApp «Quiero un agente que revise las facturas antes de pagarlas» El principal escribe la ficha .claude/agents/facturas.md name: facturas description: cuando llegue una tools: Read, holded_list_invoices El siguiente mensaje ya delega «llegó la de Telefónica» y el principal llama a facturas el principal ya tiene con qué escribir el archivo: no hace falta desplegar nada Lo que no da: dirección propia. El cliente le habla al principal, nunca al especialista. Y no recuerda: cada delegación empieza de cero. Para las dos cosas hace falta la vía B.
Un rol, no un agente. El rol es un archivo y el agente ya sabe escribir archivos en su carpeta, así que esto funciona hoy. Lo que el cliente no puede hacer es pedirse un agente que persista y al que pueda escribirle: eso es lo de la vía B.

Vía B · agentes con nombre

Existen siempre, y se les puede escribir

Un mensaje por dentro

todo esto ocurre dentro del mismo contenedor: los recuadros discontinuos son carpetas Cliente por WhatsApp, como siempre carpeta del cliente agente principal el único que habla con el cliente pide devuelve backend de mazos firma por cliente · destino permitido · registro el único camino entre agentes ida y vuelta por el mismo sitio carpeta de finanzas finanzas su sesión y sus credenciales agent:finanzas:cliente-1 carpeta de bandeja bandeja las suyas, distintas agent:bandeja:cliente-1
No hay ninguna flecha directa entre dos agentes. Todo pasa por la caja del medio, que es donde se valida la firma y la lista de destinos y donde queda el registro.

Qué gana, y dónde aplica

Hoy: un solo interlocutor todo entra y sale por el mismo hilo que arrastra la conversación entera y no hay nadie más a quien escribir Con agentes con nombre «finanzas, ¿cómo vamos de tesorería?» cada uno con su memoria y sus permisos y su propio historial de lo suyo lo nuevo no es que trabajen sin que nadie escriba, eso ya lo hacen las tareas: es que tienen dirección Los que ya tendrían trabajo propio: · bandeja de guardia · finanzas: tesorería y vencimientos · facturas de cada portal · seguimiento de lo prometido · campaña del trimestre · fichas de CRM y duplicados · clasificar lo que cae en Drive · intros para una empresa · briefing de las reuniones del día · vigilar cuota y errores · avisar cuando algo se cae · carpeta compartida bajo vigilancia
Que trabajen sin que nadie escriba ya lo hacen las tareas programadas. Lo que falta es poder escribirle a uno.

Los agentes, con nombre

bandeja mira el correo según entra y decide si merece interrumpir skill mazos-bandeja finanzas vigila tesorería, vencimientos y desvíos, y avisa sin que preguntes skill mazos-finanzas, holded facturas entra a cada portal cuando toca y archiva lo que baja invoice-bot seguimiento persigue lo prometido y lo que nadie ha contestado todavía skill mazos-seguimiento trimestre lleva la campaña del reporting y persigue a quien falta reporting trimestral crm mantiene fichas, duplicados y enriquecimiento de cada persona skill mazos-crm, kg archivo clasifica lo que cae en Drive y lo deja donde le corresponde clasificador de Drive agenda prepara el briefing de las reuniones del día calendar, fireflies guardia vigila cuota, errores y caídas y avisa al equipo, no al cliente monitor de cuota
Uno por cliente, con dirección propia. Guardia es nuestro, no del cliente.
Y aquí sí: el cliente pidiéndose un agente entero. «Quiero un agente que revise las facturas», y a partir de ese momento existe, tiene dirección y se le puede escribir. Es la versión completa de lo que en la vía A es solo un archivo, y hace falta poco más que lo ya descrito: dar de alta la fila con su carpeta y su sesión, decidir qué herramientas hereda, que no pueden ser más de las que ya tiene el cliente, y ponerle un tope por cliente, porque cada agente vivo ocupa plaza y gasta cuota.

Coste y perímetro

Dos cosas que conviene tener delante

El coste. El worker atiende cinco mensajes a la vez, para todos los clientes juntos. Los roles de la vía A no ocupan plazas extra: viven dentro de la corrida del mensaje y comparten sus 180 segundos. Cada agente de la vía B sí ocupa la suya. Y repartir el trabajo entre varios agentes gasta del orden de quince veces los tokens de una conversación normal.

El perímetro. Hay una tercera forma de que dos agentes se hablen que no es ninguna de las dos vías: que dos sesiones vivas del mismo servidor se escriban por su cuenta. El canal lo trae el CLI, no distingue de quién es cada sesión, y hoy solo lo frena la versión que corre en producción.

Se cierra con dos líneas. Que la sesión rechace lo que llegue de otra sesión, y negar las dos herramientas de mensajería por nombre pelado en el arranque. Conviene que entren en el mismo commit que suba la versión del CLI.

La decisión

Las dos vías, en este orden

  1. Ahora, la vía A.
    Un archivo por rol, empezando por el revisor de la bandeja. Se mide sobre veinte mañanas reales, contando correos que se escapan con revisor y sin él. Si no mejora, se borra el archivo y no queda nada que desmontar.
  2. En el mismo commit, cerrar el canal entre sesiones.
    Dos líneas, y no dependen de nada de lo anterior. Hoy ese canal solo lo frena la versión del CLI que corre en producción, así que se abriría solo el día que alguien actualice.
  3. Después, la vía B, con el alcance más pequeño que sirva.
    Un agente, un cliente y detrás de un flag: fila con su identificador, carpeta, sesión, enrutado por el endpoint que ya valida firma y destinos, condición de parada y salida. Y con eso montado, lo que de verdad se estrena es que el cliente se pueda pedir un agente y escribirle.
  4. Antes de abrirlo a más agentes, medir.
    Cada agente con nombre ocupa una de las cinco plazas, y con las cinco de hoy la CPU de la caja ya pica al 98%. La medida es media hora: memoria y CPU de una corrida real.