Open source agent teams pay when memory and a record are shared

A team of agents looks like more throughput until the coordination bill arrives. Four agents working in parallel produce four sets of changes, four sets of questions, and a review queue nobody staffed. Whether the team pays depends on two things a demo never shows: whether the agents share memory, and whether each one leaves a record of what it did. Without both, you have expensive subagents with a coordination bill.

What an agent team is

An agent team is one lead agent coordinating several agents that each hold their own context, with a shared task list and messages between them. The lead assigns work and synthesizes the results. The teammates work independently, and they can talk to each other without routing every message through the lead.

Most people searching for the term mean Claude Code agent teams, which Anthropic ships off by default. You turn it on by setting CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in your shell or in settings.json (Anthropic's docs). Each teammate is a full Claude Code session with its own context window, and the team coordinates through a shared task list.

Three patterns get confused here. A subagent is a worker inside one session: it takes an instruction, does the work, reports back to the orchestrator, and its context goes away. A team keeps the workers alive and lets them read each other's output. A single agent with more tools is neither. It has one context window, and every tool result competes for the same space.

When a team pays

A team pays when the work splits into slices that can run at the same time and be checked separately. Anthropic's own list is a usable test. Research and review, where teammates investigate different angles. A new module, where each owns a separate piece. Debugging, where they test competing hypotheses. Changes that span frontend, backend and tests.

Two conditions do most of the work. The slices have to be independent enough that no teammate sits waiting on another. Each slice has to produce something a person can review on its own. The shared task list is what makes that possible. It is where the split is written down, and where a teammate can see which piece is already taken.

When a team costs more than it returns

Anthropic is direct about the cost. Agent teams add coordination overhead and use significantly more tokens than a single session. They work best when teammates can operate independently. For sequential tasks, edits to the same file, or work with many dependencies, a single session or subagents are more effective.

A thread on r/ClaudeCode, "Convince me that agent teams are not pointless", makes the same case from the other side. It collects the objections a buyer runs into: coordination overhead, no background agents, idle notifications flooding the lead, and the suspicion that a team is expensive subagents with better marketing (the thread).

Token math does not settle it either way. MindStudio's comparison finds teams can be three to five times cheaper in tokens on large parallel workloads, because no single agent carries the whole context. Sub-agents are cheaper on short pipelines and sequential steps (MindStudio). The saving comes from the shape of the work.

One sequential task on a team is slower and dearer than the same task on one agent. You pay a lead to decompose it, teammates to re-read context they did not need, and a synthesis step to put the pieces back together.

What a company's team needs beyond a demo

Everything so far describes a session. A company runs a team across weeks and across people, on work that someone who was not there has to review. Five things have to exist outside the model.

• Shared memory. A teammate that starts cold re-derives what the last one learned. Memory has to live somewhere the next session reads, not in a context window that closes when the turn ends.
• Per-agent permissions. The lead should not hold every connector and every secret because it delegates. Each agent gets the grants its job needs, and nothing else.
• A registry of ownership. Which agent owns which surface, written down. Without it, two teammates edit the same file and the lead finds out at review.
• An approval gate before writes. A team that can write anywhere is a team you cannot leave running overnight.
• A record per run. Who did what, on which branch, with which diff. The record is what keeps the review queue finite.

The first and the last are the ones demos skip, and they decide whether the team costs less than doing the work another way.

The git log of a repo run by a team

Kortix's own repository is run this way, and its git log shows it. Count the first-parent commits on the dev branch over a fixed window and group them by author, and the account Kortix's own agents commit under sits at the top of that list, ahead of every person on the team.

$ git log dev --first-parent --since="2026-10-03T00:00:00Z" --until="2026-11-02T00:00:00Z" --format=%an | wc -l
2091

$ git log dev --first-parent --since="2026-10-03T00:00:00Z" --until="2026-11-02T00:00:00Z" --format=%an | sort | uniq -c | sort -rn | head -3
    744 Kortix Agent
    552 Marko Kraemer
    324 Dimitrije Glibic

Those commits sit on branches with diffs, and the work behind them reached the trunk through change requests someone could read. You can filter by author, open the change request, and see what the agent changed and who approved it. A team whose work lands in a chat transcript gives you none of that.

One manifest, one block per agent

The team is defined in a manifest, and in the Kortix starter every agent is one block under agents:, with its own prompt, model and grants.

The base kortix.yaml in the Kortix starter

  worker:
    description: "General-purpose worker: coding, research, writing, ops and data work, done end to end in its own sandbox."
    mode: primary
    permission: allow
    prompt_file: agents/worker.md
    tools: all
    skills: all
    connectors: all
    secrets: all
    kortix_permissions: all
    workspace: { project_repository: true }

The starter ships one worker and grants it everything: tools: all, skills: all, connectors: all, secrets: all. That is the right default for a template and the wrong default for a company. The work of running a team is splitting that block into the agents the company actually has. Then narrow each one's grants to its job. A reviewer agent does not need every connector. A research agent does not need write access to the repository.

Because the block is a file, the split is reviewable. A new agent is a diff, a permission change is a diff, and the history of who widened which grant sits in the same log as the code.

How Kortix runs a team

Kortix is the open-source CompanyOS. Agents, skills, company memory and connectors live as files in one git repo the company owns, and the agents work on real cloud computers.

Four properties carry the team.

• One sandbox per session. One isolated sandbox per session. Each session has its own isolated machine and branch, so two teammates cannot overwrite each other's working tree.
• Permissions per resource. Per-resource permissions for people and agents. Roles, groups, and an audit trail.
• Approval gates. Approval gates you set. Off until you set them, which is worth reading twice before you point a team at a production repository.
• A change request to main. Session work reaches main through a change request. Merge is default-deny for agents.

The last one is what makes a team safe to leave running. A teammate finishes a slice, opens a change request, and the diff becomes the record. Nothing lands on main because a lead decided it should. A person approves it, or an admin grants the merge capability to a specific agent.

The order matters: one agent, then a second when the work splits cleanly, then the grants and the record that let both run without you. A team assembled in the other order is the coordination bill with nothing to show for it.

If you want the mechanics behind the record, an agentic workflow ends at a change request and the audit trail starts with action names go deeper. Open source keeps a company brain in files you own covers the memory side.