Objectives and teams

Teams

A team is several agents with a role each — CEO, CTO, CPO, CMO, Dev… or sales and support — working together: they message each other, split the work on a shared board and report to their manager. You give them an objective and they get it done together.

What Lampson guarantees, not the prompt:

Who talks to whom. Each can message their manager, the people who report to them and the peers you choose. Any other message is rejected.
Nobody steps on anyone. A task has a single owner (taking it is atomic: if two try at once, one wins) and can't be taken until its dependencies are done. In a git project, each agent works in its own copy, on its branch and under its own author name.
Nothing reaches main without you. Working in your copy of the project (integrating into main, running something there) asks for your approval once per objective, showing what goes in — or «Just this once», if you want the next one to ask again — and every push always asks — in any permission mode — with the name of who asks. Inside its own copy, on the other hand, each agent works without asking: see How much autonomy they have.
Everything is written down. A record of everything that happens (who took what, who messaged whom, what was approved). Each agent's turn starts with what changed since its last one.
Budget. A daily cap per agent and one per objective.

Where you create them§

It all starts at http://127.0.0.1:8080/equipos (or the equipos link on Lampson's home): the teams and objectives of all your projects. Everything waiting for you, from all of them, is in the ⚑ inbox in the header. There, + equipo asks where it lives:

in a project you already have — the agents work on that folder (and, with git, each on its own branch);
in a new folder for a team that doesn't code (sales, support, research): Lampson creates it in equipos/<name> inside its installation.

And it drops you in that project's screen with the editor open. Each project has its own at /w/<project>/equipos — the folder's name is enough (/w/empresa-demo/equipos); the code that sometimes follows the name (empresa-demo-f0bfe45d) only tells apart two folders with the same name. On the home page, each project shows its teams, how many objectives are working and how much is waiting for you.

Build a team§

In the project's screen → Equipos tab → + equipo (or editar an existing one). The team shows as a graph: tap a node and set:

role and who it reports to (whoever reports to nobody leads);
who else it talks to (besides its manager and reports);
personality and how it works: the agent's prompt;
permission: strict, ask or yolo. In a git team, nothing asks inside its own copy; strict still doesn't do the dangerous things.

And for the team: every how many minutes each agent with pending work takes a round, the daily cap per agent, and whether each one works in its own git copy.

Underneath it's a file, .lampson/teams/<id>.team.json, plus one file per agent in .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 shows it in the terminal.

How they work§

Each member has all of Lampson's tools — read, write, edit, bash, processes, LSP, fetch, memory, skills, and the project's plugins and MCP servers — just like when you use it alone. Its role says what it is responsible for, not what it can do: if something of someone else's is wrong and small, whoever sees it fixes it. The only one it lacks is delegate: to hand work out, it has its teammates.

On top of that it gets two team tools, with nothing to configure:

tool
`send`	a message to a teammate (only those the graph allows); it lands in their conversation and wakes them up
`board`	the board: list, add tasks (with owner and dependencies), take them, move them, read the record

and, in its prompt, its role, who it reports to, who it can message and how the board works. Its final reply in each turn is seen by nobody else: it is its note for the next turn. To talk, send; to move forward, the board.

Every time it wakes up, an agent starts with a clean conversation: the objective, what changed in the team, the board, what woke it and the note it left itself. It doesn't resend all its previous turns at every step, which is what cost the most. Before that, Lampson brings its copy up to date with main (if it has pending work of its own, it is told how far behind it is). Messages are numbered and say whether they crossed with one of yours ("written before getting your #13"), so nobody redoes what they already sent; several in a row for someone idle are delivered together in one turn. When the objective is done, whatever they send afterwards wakes nobody.

Each change is checked once, by one person: whoever has that role (a CTO or QA who reviews) or, if nobody does, whoever did the task. Nobody re-runs tests someone already ran on the same commit, and whoever integrates doesn't re-review what was approved: they merge and run the tests once. Fixing something that slipped through now and then costs less than checking everything several times on every pass.

An agent works when a message arrives, when a round comes and it has something of its own (an open task, something assigned to it, a message), when someone assigns it a task (even with rounds at 0), or — if it leads — when its objective moves. With nothing for it, it spends nothing.

Git. In a git project, each one works in .lampson/worktrees/<agent>, on the branch team/<team>/<agent>. For the agent that copy is the project's root: the others' are ../<agent> and your copy is ../../... It commits there and says which branch it delivered; whoever reviews (the CTO, say) integrates it into main with git -C ../../.. merge …. Until then your copy of the project isn't touched: .lampson/ stays out of git without changing your .gitignore.

How much autonomy they have§

Think of it as a company: you are the board. You give the team an objective and it delivers without consulting you at every step; only what crosses the company's border reaches you.

In their own job, everything. In a git project, each agent works in its own copy: installing, building, running tests, deleting, resetting, switching branches and committing asks nobody. It all stays on its branch and your copy isn't touched.
Managers manage. Whoever has people under them (the CTO with its Dev, say) also works in their copies: reviews, fixes, runs their tests. The lead, in everyone's. Reading, anyone can read the whole project.
The border reaches you:

- working in your copy — integrating into main and whatever that needs there: a conflict, the tests, a tag —: a single approval per objective, the first time, showing what goes in (branches, commits, files). After that, the objective doesn't ask again; - every push, which only the lead does; - whatever leaves the project (publishing, deploying, sending, buying): the lead asks you; - more budget when the cap runs out.

What isn't their job doesn't run. Changing the copy of someone who doesn't work under them, touching your copy without having people under them, leaving the project folder, or pushing without being the lead. The agent gets a message saying it is a team rule — not an error in its command — and what to do instead.
Approvals don't travel from boss to boss. No agent can approve for you: what needs your approval goes straight to your queue, with the name of who asks.

bash isn't confined by the operating system: Lampson reads each command and stops what names something outside the agent's copy. For a sensitive project, run Lampson in a container.

Without git (a sales or support team in its folder) there are no separate copies: each agent works by its permission, and what needs approval also reaches you directly.

A real objective for a team§

The company above (all on glm-5.3-flash) on a small Node task API, with this objective:

Ship version 0.2: each task has a priority (high, medium or low; medium if missing), it can be created with a priority, and GET /tasks?sort=priority returns them sorted high to low (combinable with ?done=). An invalid priority is 400. Clear requirements from the CPO, implementation with tests from the Dev, review and merge into main from the CTO (with my approval), and from the CMO a CHANGELOG.md and a short announcement. Finish when everything is on main and npm test passes on main.

This is the record (abridged, translated from Spanish):

21:37  person   new objective O-2 → team empresa (led by ceo)
21:38  ceo      added #11 "review and merge into main" → cto · #12 "CHANGELOG and announcement" → cmo
21:39  ceo      messaged → cpo: "I need clear, testable criteria: a priority field…"
21:39  cto      messaged → dev: "Your task: #8, work on team/empresa/dev. Concrete changes: 1. src/store.js…"
21:39  cpo      moved #6 → review: docs/requisitos-prioridad.md committed on team/empresa/cpo
21:40  cto      asks approval: git -C ../../.. merge --no-ff team/empresa/cpo   ← approved
21:42  dev      moved #8 → review: "implemented on team/empresa/dev, npm test 10/10"
21:43  cto      messaged → ceo: "review done against the 12 requirements, ready to merge"
21:44  cto      asks approval: git -C ../../.. merge --no-ff team/empresa/dev   ← approved
21:44  cmo      moved #12 → review: CHANGELOG.md and docs/anuncio-v0.2.md on team/empresa/cmo
21:45  cto      asks approval: git -C ../../.. merge --no-ff team/empresa/cmo   ← approved
21:46  ceo      finished O-2: "v0.2 shipped and verified on main…"

Eight minutes. The CPO wrote 12 requirements with acceptance criteria; the CTO told the Dev what to do and how; the Dev implemented it with 5 new tests; the CTO reviewed it against the requirements and asked for the three merges — each one waited for the approval, which we gave after looking at the branch and running the tests; since 0.5.3 it is a single approval per objective; the CMO wrote the changelog and the announcement; the CEO checked main and closed it. Git's history says who did what:

*   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

The merges into main carry your copy's author: you approved them. About 368,000 tokens in total across the five.

One detail from that run: the CEO told the CTO "merge approved". That wasn't enough — approving a merge into main is yours, and Lampson asked anyway. That's the point: what matters doesn't depend on the agents behaving.

When to use a team§

Work with different roles that review each other (define → build → review → tell).
Things that can go in parallel (requirements and changelog while it's being built).
Small things too: a sales agent and a stock agent passing orders to each other.

For a single-role task, an objective for one agent is enough and costs less.

View as Markdown