Team Collaboration

Shared orchestration on hosted nfltr.xyz: several people run their own hubs against the same joined machines, each with its own hub id, and everyone on the account can watch the work.

API keys

Everything is scoped to the account whose API key a command uses: the nodes it joins, the tasks its agents run, what nfltr orch task list shows. Create keys in the dashboard (Account → API keys). Save one or several in the CLI and switch between them by label:

$ nfltr config add-api-key
$ nfltr config add-api-key --name team
$ nfltr config list-api-keys
$ nfltr config use-api-key team

On shared servers prefer NFLTR_API_KEY in the service's environment. Never put a key on a command line, in a repository, or in an MCP config file. To rotate a key, create a new one in the dashboard, save it under the same label with nfltr config add-api-key --name <label>, then revoke the old key in the dashboard.

Shared nodes

A node joined with the team's key serves every hub on that account: one build server or GPU box can run agents for everyone, up to its --max-agents. When all its slots are busy, a new spawn waits for one to free.

$ nfltr node join --max-agents 4 --allow-all-tools \
    --allow-repo 'github.com/your-org/*' \
    --machine-description "team build server: large disk, docker, staging VPN" \
    --labels team=platform,env=staging

Nodes use the account key. Tools and repository access are the node's own opt-ins, so the person who joins a machine decides what agents may do on it. See Join machines as nodes.

One hub per person and project

A hub is the Claude session that owns its agents. Its id defaults to one per project directory on the machine that runs it, and its state (agents, completions) lives with that hub, so two people never share an inbox by accident. Only one live process may hold a hub id; a second session in the same project needs its own id:

$ nfltr orch --hub-id alice-release "prepare the release notes for v2.3"

In Claude Code, add a second server with its own id, for example claude mcp add nfltr-review -- nfltr mcp --toolset hub --hub-id review.

Labels

--labels key=value on a node tags the agents it launches. A spawn can require labels (every one must match exactly), so a goal like "run it on an env=staging machine" routes there. Keep label names consistent across the team; describe everything else in --machine-description, which the hub reads as plain text.

What teammates see

The same nodes: nfltr orch nodes list.
The same tasks, including each agent's prompt and result: nfltr orch task list, task status, and task result while its hub runs. Treat prompts as visible to the whole account; keep secrets in the machines' environment, not in goals.
Not your hub. Steering and stopping go through the hub that spawned the agent; ask its owner, or reattach it on the machine that runs it with the same --hub-id.