Objetivos e equipes

Equipes

Uma equipe são vários agentes com um papel cada — CEO, CTO, CPO, CMO, Dev… ou vendas e suporte — trabalhando juntos: trocam mensagens, dividem o trabalho num quadro compartilhado e se reportam ao chefe. Você dá um objetivo e eles resolvem entre todos.

O que o Lampson garante, não o prompt:

Quem fala com quem. Cada um pode escrever ao chefe, a quem se reporta a ele e aos pares que você escolher. Qualquer outra mensagem é rejeitada.
Ninguém atropela ninguém. Uma tarefa tem um único dono (pegá-la é atômico: se dois tentam ao mesmo tempo, um ganha) e não pode ser pega até as dependências estarem feitas. Num projeto com git, cada agente trabalha na sua própria cópia, na sua branch e com o seu nome de autor.
Nada chega à main sem você. Trabalhar na sua cópia do projeto (integrar na main, rodar algo lá) pede sua aprovação uma vez por objetivo, mostrando o que entra — ou «Só desta vez», se quiser que o próximo pergunte de novo — e cada push sempre pede — em qualquer modo de permissão — com o nome de quem pede. Dentro da própria cópia, por outro lado, cada agente trabalha sem perguntar: veja Quanta autonomia elas têm.
Tudo fica escrito. Um registro de tudo o que acontece (quem pegou o quê, quem escreveu para quem, o que foi aprovado). Cada turno de um agente começa com o que mudou desde o anterior.
Orçamento. Um teto diário por agente e um por objetivo.

Onde se criam§

Tudo começa em http://127.0.0.1:8080/equipos (ou o link equipos do início do Lampson): as equipes e objetivos de todos os seus projetos. Tudo o que espera por você, de todos eles, fica na caixa ⚑ do cabeçalho. Ali, + equipo pergunta onde ela vive:

num projeto que você já tem — os agentes trabalham sobre essa pasta (e, com git, cada um na sua branch);
numa pasta nova para uma equipe que não programa (vendas, suporte, pesquisa): o Lampson a cria em equipos/<nome> dentro da instalação.

E deixa você na tela desse projeto com o editor aberto. Cada projeto tem a sua em /w/<projeto>/equipos — o nome da pasta basta (/w/empresa-demo/equipos); o código que às vezes segue o nome (empresa-demo-f0bfe45d) só distingue duas pastas com o mesmo nome. No início, cada projeto mostra suas equipes, quantos objetivos estão trabalhando e quanto espera por você.

Montar uma equipe§

Na tela do projeto → aba Equipos → + equipo (ou editar uma existente). A equipe aparece como um grafo: toque num nó e defina:

papel e a quem se reporta (quem não se reporta a ninguém lidera);
com quem mais fala (além do chefe e de quem se reporta a ele);
personalidade e como trabalha: o prompt do agente;
permissão: strict, ask ou yolo. Numa equipe com git, dentro da própria cópia nada pergunta; strict continua sem fazer o que é perigoso.

E da equipe: a cada quantos minutos cada agente com trabalho pendente faz uma rodada, o teto diário por agente, e se cada um trabalha na sua cópia do git.

Por baixo é um arquivo, .lampson/teams/<id>.team.json, mais um arquivo por agente em .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 mostra no terminal.

Como trabalham§

Cada membro tem todas as ferramentas do Lampson — ler, escrever, editar, bash, processos, LSP, fetch, memória, skills, e os plugins e servidores MCP do projeto —, igual a quando você o usa sozinho. O papel diz pelo que ele responde, não o que pode fazer: se algo de outro está errado e é pequeno, quem vê conserta. A única que ele não tem é delegate: para repartir, tem os colegas.

Além disso recebe duas ferramentas de equipe, sem configurar nada:

ferramenta
`send`	uma mensagem a um colega (só aos que o grafo permite); chega na conversa dele e o acorda
`board`	o quadro: listar, adicionar tarefas (com dono e dependências), pegar, mover, ver o registro

e, no prompt, o seu papel, a quem se reporta, a quem pode escrever e como o quadro funciona. A resposta final de cada turno ninguém mais vê: é a nota dele para o turno seguinte. Para falar, send; para avançar, o quadro.

Cada vez que acorda, um agente começa com a conversa limpa: o objetivo, o que mudou na equipe, o quadro, o que o acordou e a nota que deixou para si. Ele não reenvia todos os turnos anteriores a cada passo, que era o que mais gastava. Antes, o Lampson atualiza a cópia dele com a main (se ele tem trabalho próprio pendente, avisa quanto ficou para trás). As mensagens são numeradas e dizem se cruzaram com uma sua («escrita antes de receber a sua #13»), assim ninguém refaz o que já mandou; várias seguidas para alguém livre chegam juntas num só turno. Quando o objetivo termina, o que mandarem depois não acorda ninguém.

Cada mudança é verificada uma vez só, por uma pessoa só: quem tem esse papel (um CTO ou QA que revisa) ou, se não houver, quem fez a tarefa. Ninguém repete testes que outro já rodou no mesmo commit, e quem integra não revisa de novo o que foi aprovado: faz o merge e roda os testes uma vez. Sai mais barato corrigir de vez em quando algo que escapou do que verificar tudo várias vezes em cada passada.

Um agente trabalha quando chega uma mensagem, quando vem uma rodada e ele tem algo seu (uma tarefa aberta, algo atribuído a ele, uma mensagem), quando alguém atribui uma tarefa a ele (mesmo com as rodadas em 0), ou — se lidera — quando o objetivo avança. Sem nada para ele, não gasta.

Git. Num projeto com git, cada um trabalha em .lampson/worktrees/<agente>, na branch team/<equipe>/<agente>. Para o agente essa cópia é a raiz do projeto: as dos outros são ../<agente> e a sua cópia é ../../... Faz commit ali e avisa qual branch entregou; quem revisa (o CTO, por exemplo) integra na main com git -C ../../.. merge …. Até lá a sua cópia do projeto não é tocada: .lampson/ fica fora do git sem mudar o seu .gitignore.

Quanta autonomia elas têm§

Pense numa empresa: você é o conselho. Você dá um objetivo e a equipe entrega sem consultar você a cada passo; só chega a você o que cruza a fronteira da empresa.

No seu posto, tudo. Num projeto com git, cada agente trabalha na sua cópia: instalar, compilar, rodar testes, apagar, resetar, trocar de branch e fazer commit não pergunta a ninguém. Tudo fica na branch dele e a sua cópia não é tocada.
Os chefes gerenciam. Quem tem gente a seu cargo (o CTO com o seu Dev, por exemplo) também trabalha nas cópias deles: revisa, corrige, roda os testes. O líder, nas de todos. Ler, qualquer um lê o projeto inteiro.
A fronteira chega a você:

- trabalhar na sua cópia — integrar na main e o que for preciso ali: um conflito, os testes, uma tag —: uma só aprovação por objetivo, na primeira vez, mostrando o que entra (branches, commits, arquivos). Depois, esse objetivo não pergunta de novo; - cada push, que só o líder faz; - o que sai do projeto (publicar, implantar, enviar, comprar): o líder pede a você; - mais orçamento quando o limite acaba.

O que não é do posto dele não roda. Mudar a cópia de quem não depende dele, mexer na sua cópia sem ter gente a seu cargo, sair da pasta do projeto ou fazer push sem ser o líder. O agente recebe uma mensagem dizendo que é uma regra da equipe — não um erro do comando — e o que fazer no lugar.
As aprovações não passam de chefe em chefe. Nenhum agente pode aprovar por você: o que precisa da sua aprovação vai direto para a sua fila, com o nome de quem pede.

O bash não é confinado pelo sistema operacional: o Lampson lê cada comando e barra o que cita algo fora da cópia do agente. Para um projeto delicado, rode o Lampson num contêiner.

Sem git (uma equipe de vendas ou de suporte na sua pasta) não há cópias separadas: cada agente trabalha conforme a sua permissão, e o que pede aprovação também chega direto a você.

Um objetivo real para uma equipe§

A empresa acima (todos com glm-5.3-flash) numa pequena API de tarefas em Node, com este objetivo:

Lançar a versão 0.2: cada tarefa tem prioridade (alta, média ou baixa; se não vier, média), pode ser criada com prioridade e GET /tasks?sort=priority devolve ordenadas de alta a baixa (combinável com ?done=). Uma prioridade inválida é 400. Requisitos claros do CPO, implementação com testes do Dev, revisão e merge na main do CTO (com minha aprovação), e do CMO um CHANGELOG.md e um anúncio curto. Termine quando tudo estiver na main e npm test passar na main.

Assim ficou o registro (resumido, traduzido do espanhol):

21:37  pessoa   novo objetivo O-2 → equipe empresa (liderada por ceo)
21:38  ceo      adicionou #11 "revisão e merge na main" → cto · #12 "CHANGELOG e anúncio" → cmo
21:39  ceo      escreveu → cpo: "Preciso de critérios claros e verificáveis: campo priority…"
21:39  cto      escreveu → dev: "Tarefa sua: #8, trabalhe em team/empresa/dev. Mudanças concretas: 1. src/store.js…"
21:39  cpo      moveu #6 → revisão: docs/requisitos-prioridad.md com commit em team/empresa/cpo
21:40  cto      pede aprovação: git -C ../../.. merge --no-ff team/empresa/cpo   ← aprovado
21:42  dev      moveu #8 → revisão: "implementado em team/empresa/dev, npm test 10/10"
21:43  cto      escreveu → ceo: "revisão feita contra os 12 requisitos, pronto para o merge"
21:44  cto      pede aprovação: git -C ../../.. merge --no-ff team/empresa/dev   ← aprovado
21:44  cmo      moveu #12 → revisão: CHANGELOG.md e docs/anuncio-v0.2.md em team/empresa/cmo
21:45  cto      pede aprovação: git -C ../../.. merge --no-ff team/empresa/cmo   ← aprovado
21:46  ceo      concluiu O-2: "v0.2 lançada e verificada na main…"

Oito minutos. O CPO escreveu 12 requisitos com critérios de aceitação; o CTO passou ao Dev o que fazer e como; o Dev implementou com 5 testes novos; o CTO revisou contra os requisitos e pediu os três merges — cada um esperou a aprovação, que demos depois de olhar a branch e rodar os testes; desde a 0.5.3 é uma só aprovação por objetivo; o CMO escreveu o changelog e o anúncio; o CEO conferiu a main e fechou. O histórico do git diz quem fez o 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

Os merges na main levam o autor da sua cópia: você os aprovou. No total, uns 368.000 tokens entre os cinco.

Um detalhe dessa execução: o CEO escreveu ao CTO "merge aprovado". Não bastou — aprovar um merge na main é com você, e o Lampson pediu de qualquer forma. É essa a ideia: o que importa não depende de os agentes se comportarem bem.

Quando usar uma equipe§

Trabalho com papéis diferentes que se revisam (definir → fazer → revisar → contar).
Coisas que podem ir em paralelo (requisitos e changelog enquanto se implementa).
Coisas pequenas também: um agente de vendas e um de estoque passando pedidos entre si.

Para uma tarefa de um só papel, um objetivo para um agente basta e gasta menos.

Ver como Markdown