What is the right AI coding agent setup for a team?

The ceiling on in-editor agents

Cursor, Copilot Chat, and similar tools live inside one developer’s editor. Every agent run is a private session: the prompts, the tool calls, the rejected diffs, the cost. When Pat’s agent burns $4.20 chasing the wrong file, Maya the team lead has no record of it until Pat happens to mention it in standup. When two engineers both ask their local agents to fix the same flaky test, you get two PRs and a merge conflict.

The fix is not “a bigger AI”. The fix is moving the unit of agent work out of the editor and onto a surface the whole team can see — the same surface they use to plan and assign work.

The team-first shape

A team-shaped AI coding setup has four properties:

1. One board, one truth. Cards represent units of work. Each card has a thread that contains every agent run it spawned, with full tool_use / tool_result history. You can scroll the thread three weeks later and see what the agent edited.
2. Agents run on the assignee’s machine.No inference resold to the team, no source uploaded to a vendor’s cloud. The developer’s own claude /login or codex binary does the work. Bring your own keys.
3. Decisions are routed, not private.When the agent asks “rebase or merge?”, the question pops on the card. Anyone with answer permission can resolve it; the chosen value is recorded.
4. Cost rolls up.Per run, per card, per project, per sprint. The CFO question (“what did we spend on Claude this month?”) gets a real answer instead of a Slack thread.

How kanbots implements it

kanbots is desktop-first and starts the moment you point it at a folder. The flow:

1. Open kanbots. The workspace picker shows recent folders; pick a folder containing a git repo. kanbots creates .kanbots/ with a SQLite database, a config, and a worktrees/ directory.
2. Either stay in local mode (issues stored in SQLite, no remote) or switch to GitHub modefrom Settings → Workspace. In GitHub mode kanbots populates the board from open issues on the configured repo.
3. Click Dispatch on a card. kanbots creates a per-run worktree at .kanbots/worktrees/issue-N-runId/ on a kanbots/issue-N-runId branch, spawns claude -p (or codex exec) with --output-format stream-json, and streams every line into the run drawer in the UI.
4. In GitHub mode, the column drag for that card emits a PATCH /repos/{owner}/{repo}/issues/{n} that updates the status:in-progress label, and the agent state adds an agent:runninglabel. A teammate looking at the GitHub issue (or the GitHub Projects board) sees the same state, even if they don’t have kanbots installed.

Two-way label sync is what makes kanbots play well with teams who haven’t all adopted it yet. Non-kanbots users see real GitHub issues moving through real columns. kanbots users see live agent threads on the same issues. No fork in the data.

Walkthrough: a four-person team adopts this

1. Maya the lead installs the kanbots desktop on her Mac, opens their acme-web folder, and flips to GitHub mode. The backlog populates from existing open issues.
2. She invites two engineers to install the same build. Each one opens the same folder on their machine and signs in with claude /loginusing their own Anthropic account. No shared API key — each person’s spend appears on their own Anthropic invoice.
3. Pat drags issue #142 (“Safari login redirect”) to In progress. kanbots opens a worktree, spawns Claude. The agent edits two files, hits a decision (“use replaceState or pushState?”), and pauses. Pat answers 1. The run continues.
4. Pat clicks Open draft PR. kanbots pushes the branch and uses the GitHub App (or his gh token, in OSS desktop) to open a draft PR linking back to issue #142.
5. Maya reviews the PR in the normal GitHub flow. Cost for that run ($0.41) is on the card. The agent thread sits on the card for the team’s next retro.

Failure modes and fixes

“The agent edited a file outside the worktree.”

Claude Code with --permission-mode bypassPermissionsis powerful and occasionally over-eager. kanbots’s containmentMode setting (default warn) logs out-of-worktree edits as warnings; set it to pause in .kanbots/config.json and the run blocks with a decision prompt asking you to allow or stop. Use pause on shared repos where a stray write to a sibling project would matter.

“Two engineers picked the same card.”

In OSS desktop this is possible because there’s no shared server — both Pat and Sasha can drag the same issue to In progress. Each gets their own worktree on their own machine, but only one PR is wanted. Fix: in GitHub mode, the agent:running label is visible to everyone; agree on a team norm that whoever sets it first owns the card. For real contention prevention you want kanbots Cloud, which has a single source of truth for assignment.

“The team can’t roll up cost.”

On OSS desktop, cost lives per-person. Each card has the cost of runs on that person’s machine; there’s no aggregation. For per-project / per-sprint rollup across the team, the cloud product writes runs back to a shared org and exposes a cost panel. On OSS you can approximate by exporting .kanbots/db.sqlite from each developer and summingagent_runs.total_cost_usd, but it’s not graceful.

When this is the wrong fit

If you’re a solo developer working on one repo, kanbots is overkill. The board adds friction that pays off only when multiple people need shared visibility. Stay with Cursor or vanilla claude -p in your terminal until you have a second person who needs to see what your agent is doing.

Likewise, if your team uses AI strictly for autocomplete (Copilot ghost text), you don’t have agent work to coordinate. kanbots is for teams who run agenticsessions — long-form tool-using runs that touch many files and ask questions — not line-by-line completion.

Related reading

For the GitHub-issue-specific click path, see how do you assign GitHub issues to AI agents. For the queue mechanics under the hood, see how do you build an AI agent task queue. For the team-wide orchestration story, see how do you orchestrate Claude Code across a team.