Objetivos y equipos

Equipos

Un equipo son varios agentes con un rol cada uno —CEO, CTO, CPO, CMO, Dev… o ventas y soporte— que trabajan juntos: se mandan mensajes, se reparten el trabajo en un tablero compartido y le reportan a su jefe. Les das un objetivo y lo sacan entre todos.

Lo que Lampson garantiza, no el prompt:

Quién le habla a quién. Cada uno puede escribirle a su jefe, a quienes le reportan y a los pares que vos digas. Cualquier otro mensaje se rechaza.
Nadie se pisa. Una tarea tiene un solo dueño (tomarla es atómico: si dos van a la vez, gana uno) y no se puede tomar hasta que sus dependencias estén hechas. En un proyecto con git, cada agente trabaja en su propia copia, en su rama y con su nombre de autor.
Nada llega a main sin vos. Trabajar en tu copia del proyecto (integrar a main, correr algo ahí) pide tu aprobación una vez por objetivo, mostrando lo que entra —o «Solo esta vez», si querés que el próximo vuelva a preguntar—, y cada push la pide siempre —en cualquier modo de permisos— con el nombre de quién lo pide. Adentro de su propia copia, en cambio, cada agente trabaja sin preguntar: ver Cuánta autonomía tienen.
Todo queda escrito. Un registro de cada cosa que pasa (quién tomó qué, quién le escribió a quién, qué se aprobó). Cada turno de un agente empieza con lo que cambió desde el anterior.
Presupuesto. Un tope diario por agente y uno por objetivo.

Dónde se crean§

Todo empieza en http://127.0.0.1:8080/equipos (o el enlace equipos del inicio de Lampson): los equipos y objetivos de todos tus proyectos. Lo que te espera, de todos juntos, está en la bandeja ⚑ de la cabecera. Ahí, + equipo pregunta dónde vive:

en un proyecto que ya tenés — los agentes trabajan sobre esa carpeta (y, con git, cada uno en su rama);
en una carpeta nueva para un equipo que no programa (ventas, soporte, investigación): Lampson la crea en equipos/<nombre> dentro de su instalación.

Y te deja en la pantalla de ese proyecto con el editor abierto. Cada proyecto tiene la suya en /w/<proyecto>/equipos — con el nombre de la carpeta alcanza (/w/empresa-demo/equipos); el código que a veces sigue al nombre (empresa-demo-f0bfe45d) solo distingue dos carpetas que se llaman igual. En el inicio, cada proyecto muestra sus equipos, cuántos objetivos están trabajando y cuánto te espera.

Armar un equipo§

En la pantalla del proyecto → pestaña Equipos → + equipo (o editar uno). El equipo se ve como un grafo: tocás un nodo y le ponés:

rol y a quién reporta (el que no reporta a nadie lidera);
con quién más habla (además de su jefe y sus reportes);
personalidad y cómo trabaja: el prompt del agente;
permiso: strict, ask o yolo. En un equipo con git, adentro de su copia no pregunta nada; strict igual no hace lo peligroso.

Y del equipo: cada cuántos minutos hace rondas cada agente con trabajo pendiente, el tope diario por agente, y si cada uno trabaja en su copia de git.

Por debajo es un archivo, .lampson/teams/<id>.team.json, y un archivo por agente en .lampson/agents/:

{
  "id": "empresa",
  "description": "La empresa detrás de empresa-demo",
  "members": [
    {"agent": "ceo", "role": "CEO"},
    {"agent": "cto", "role": "CTO", "reports_to": "ceo"},
    {"agent": "cpo", "role": "CPO", "reports_to": "ceo"},
    {"agent": "cmo", "role": "CMO", "reports_to": "ceo"},
    {"agent": "dev", "role": "Dev", "reports_to": "cto"}
  ],
  "talks": [["cpo", "cto"], ["cmo", "cpo"], ["cmo", "cto"]],
  "round_minutes": 2,
  "budget_daily_tokens": 600000,
  "worktrees": true
}

lampson team list lo muestra en la terminal.

Cómo trabajan§

Cada miembro tiene todas las herramientas de Lampson —leer, escribir, editar, bash, procesos, LSP, fetch, memoria, skills, y los plugins y servidores MCP del proyecto—, igual que cuando lo usás solo. Su rol dice de qué responde, no qué puede hacer: si algo de otro está mal y es chico, lo arregla quien lo ve. La única que no tiene es delegate: para repartir, tiene a sus compañeros.

Además recibe, sin configurar nada, dos herramientas de equipo:

herramienta
`send`	un mensaje a un compañero (solo a los que el grafo permite); llega a su conversación y lo despierta
`board`	el tablero: listar, agregar tareas (con dueño y dependencias), tomarlas, moverlas, ver el registro

y en su prompt, su rol, a quién reporta, a quién le puede escribir y cómo se usa el tablero. Su respuesta final de cada turno no la ve nadie más: es su nota para el turno siguiente. Para hablar, send; para avanzar, el tablero.

Cada vez que se despierta, un agente arranca con la conversación limpia: el objetivo, lo que cambió en el equipo, el tablero, lo que lo despertó y la nota que se dejó. No reenvía todos sus turnos anteriores en cada paso, que es lo que más gastaba. Antes, Lampson pone su copia al día con main (si tiene trabajo propio pendiente, le avisa cuánto quedó atrás). Los mensajes van numerados y dicen si se cruzaron con uno tuyo («escrito antes de recibir tu #13»), así nadie rehace lo que ya mandó; si llegan varios seguidos para alguien libre, se le entregan juntos en un solo turno. Cuando el objetivo termina, lo que se manden después no despierta a nadie.

Cada cambio se verifica una sola vez, y lo hace una sola persona: quien tiene ese rol (un CTO o QA que revisa) o, si no hay, quien hizo la tarea. Nadie repite pruebas que otro ya corrió sobre el mismo commit, y quien integra no vuelve a revisar lo aprobado: hace el merge y corre las pruebas una vez. Sale más barato corregir de vez en cuando algo que se escapó que verificar todo varias veces en cada pasada.

Un agente trabaja cuando le llega un mensaje, cuando le toca una ronda y tiene algo suyo (una tarea abierta, algo que le asignaron, un mensaje), cuando otro le asigna una tarea (aunque las rondas estén en 0), o —si lidera— cuando avanza su objetivo. Sin nada para él, no gasta.

Git. En un proyecto con git, cada uno trabaja en .lampson/worktrees/<agente>, en la rama team/<equipo>/<agente>. Para el agente esa copia es la raíz del proyecto: las de los otros son ../<agente> y tu copia es ../../... Commitea ahí y avisa qué rama entregó; quien revisa (el CTO, por ejemplo) la integra a main con git -C ../../.. merge …. Hasta entonces tu copia del proyecto no se toca: .lampson/ queda fuera de git sin cambiar tu .gitignore.

Cuánta autonomía tienen§

Pensalo como una empresa: vos sos el directorio. Le das un objetivo y el equipo lo saca sin consultarte cada paso; a vos solo te llega lo que cruza el borde de la empresa.

En su puesto, todo. En un proyecto con git, cada agente trabaja en su copia: instalar, compilar, correr tests, borrar, resetear, cambiar de rama y commitear no le pregunta a nadie. Todo queda en su rama y tu copia no se toca.
Los jefes gestionan. Quien tiene gente a cargo (el CTO con su Dev, por ejemplo) también trabaja en las copias de los suyos: revisa, corrige, corre sus tests. El líder, en las de todos. Leer, cualquiera puede leer todo el proyecto.
A vos te llega el borde:

- trabajar en tu copia —integrar a main y lo que haga falta ahí: un conflicto, los tests, un tag—: una sola aprobación por objetivo, la primera vez, mostrando lo que entra (ramas, commits, archivos). Después, ese objetivo no vuelve a preguntar; - cada push, que solo hace el líder; - lo que sale del proyecto (publicar, desplegar, mandar, comprar): el líder te lo pide; - más presupuesto cuando se acaba el tope.

Lo que no es de su puesto no corre. Cambiar la copia de alguien que no depende de él, tocar tu copia sin tener gente a cargo, salir de la carpeta del proyecto o hacer push sin ser el líder. El agente recibe un mensaje que le dice que es una regla del equipo —no un error de su comando— y qué hacer en cambio.
Las aprobaciones no pasan de jefe en jefe. Ningún agente puede aprobar por vos: lo que necesita tu aprobación va directo a tu cola, con el nombre de quién lo pide.

bash no lo encierra el sistema operativo: Lampson lee cada comando y frena lo que nombra algo fuera de su copia. Para un proyecto delicado, corré Lampson en un contenedor.

Sin git (un equipo de ventas o de soporte en su carpeta) no hay copias separadas: cada agente trabaja según su permiso, y lo que pide aprobación también te llega directo a vos.

Un objetivo real para un equipo§

La empresa de arriba (todos con glm-5.3-flash) sobre una API de tareas en Node, con este objetivo:

Lanzar la versión 0.2: cada tarea tiene prioridad (alta, media o baja; si no viene, media), se puede crear con prioridad y GET /tasks?sort=priority las devuelve ordenadas de alta a baja (combinable con ?done=). Una prioridad inválida es 400. Requisitos claros del CPO, implementación con tests del Dev, revisión y merge a main del CTO (con mi aprobación), y del CMO un CHANGELOG.md y un anuncio corto. Terminá cuando todo esté en main y npm test pase en main.

Así quedó el registro (resumido):

21:37  persona   nuevo objetivo O-2 → equipo empresa (lo lidera ceo)
21:38  ceo       agregó #11 «revisión y merge a main» → cto · #12 «CHANGELOG y anuncio» → cmo
21:39  ceo       escribió → cpo: «Necesito criterios claros y verificables: campo priority…»
21:39  cto       escribió → dev: «Tarea tuya: #8, trabajá en team/empresa/dev. Cambios concretos: 1. src/store.js…»
21:39  cpo       movió #6 → en revisión: docs/requisitos-prioridad.md commiteado en team/empresa/cpo
21:40  cto       pide aprobación: git -C ../../.. merge --no-ff team/empresa/cpo   ← aprobado
21:42  dev       movió #8 → en revisión: «implementado en team/empresa/dev, npm test 10/10»
21:43  cto       escribió → ceo: «revisión completada contra los 12 requisitos, listos para mergear»
21:44  cto       pide aprobación: git -C ../../.. merge --no-ff team/empresa/dev   ← aprobado
21:44  cmo       movió #12 → en revisión: CHANGELOG.md y docs/anuncio-v0.2.md en team/empresa/cmo
21:45  cto       pide aprobación: git -C ../../.. merge --no-ff team/empresa/cmo   ← aprobado
21:46  ceo       terminó O-2: «v0.2 lanzada y verificada en main…»

Ocho minutos. El CPO escribió 12 requisitos con criterios de aceptación; el CTO le pasó al Dev qué hacer y cómo; el Dev implementó con 5 tests nuevos; el CTO revisó contra los requisitos y pidió los tres merges —cada uno esperó la aprobación, que dimos después de mirar la rama y correr los tests; desde la 0.5.3 es una sola aprobación por objetivo—; el CMO escribió el changelog y el anuncio; el CEO verificó main y cerró. El historial de git dice quién hizo qué:

*   765832d  v0.2: CHANGELOG y anuncio (docs del CMO)
| * 1f1e55d  CMO · cmo (Lampson)   Docs v0.2: CHANGELOG y anuncio de prioridades
*   143bba8  v0.2: prioridad por tarea — implementación del Dev
| * 3c8d5e1  Dev · dev (Lampson)   v0.2: prioridad por tarea (alta/media/baja) y sort=priority
*   8e0d002  Requisitos v0.2: prioridad de tareas (docs del CPO)
| * 2304f7f  CPO · cpo (Lampson)   Requisitos v0.2: prioridad de tareas

Los merges a main llevan el autor de tu copia: los aprobaste vos. En total, unos 368.000 tokens entre los cinco.

Un detalle de esa corrida: el CEO le escribió al CTO «aprobado el merge». No alcanzó —la aprobación de un merge a main es tuya y Lampson la pidió igual—. Esa es la idea: lo importante no depende de que los agentes se porten bien.

Cuándo usar un equipo§

Trabajo con roles distintos que se revisan entre sí (definir → hacer → revisar → contar).
Cosas que pueden ir en paralelo (requisitos y changelog mientras se implementa).
Algo chico también sirve: un agente de ventas y uno de stock que se pasan los pedidos.

Para una tarea de un solo rol, un objetivo a un agente alcanza y gasta menos.

Ver como Markdown