A Company Run on Coordinated Claude Code Sessions

In late September 2026, Tomer Bar-Meir, sole founder of BlueVeta, published a first-hand account of how his company actually runs (dev.to/tomerbarm). BlueVeta takes one product photo and returns a full marketing campaign — studio shots, lifestyle scenes, video, and platform-ready copy for twenty platforms. The interesting part is not the product. It is the org chart.

Every part of the company — the generation engine, the dashboard, image generation, copy generation, auth and billing, marketing — is its own persistent Claude Code session. Each session owns one domain. Each works in its own git worktree so nothing collides. They message each other directly when work crosses domains, they read and write a shared set of docs that functions as the company's institutional memory, and one hard rule governs all of them: investigation is always free, but nothing gets built, deployed, or spent without the founder's sign-off.

That is a real topology, not a demo. By his account: real Stripe payments, real (if still small) customers, and roughly 75% of the work in every customer pack done by Claude rather than a human.

We run a different orchestration for our own fleet — a kanban dispatcher rather than persistent peer sessions — and we have archived an earlier 20-agent "AI CEO" system along the way. This is a teardown of Bar-Meir's architecture, where the human sits in it, what it costs, what breaks — and an honest comparison against the two other ways to run a company on agents that we have operated ourselves.

The topology: domain-scoped sessions, not a swarm

The common mental model of multi-agent AI is a swarm: one orchestrator agent spinning up task-scoped subagents that live for the length of a job and vanish. BlueVeta's model is the opposite. Sessions are persistent and domain-scoped. The billing session is not summoned for a billing task; it exists, and the same session owns the domain the next time billing work appears.

That persistence is the load-bearing decision, because it changes what a session accumulates. A task-scoped subagent starts every job from a prompt. A persistent domain session starts from accumulated context — the domain's conventions, its past incidents, its customer edge cases — stored in shared docs the sessions all read and write. The context compounds instead of resetting. In our fleet we package the same idea as reloadable agent skills, so agents load role context on demand rather than holding it resident; the trade is memory footprint versus cold-start fidelity.

The git worktree isolation is the second structural decision, and Bar-Meir states its purpose plainly: "each in its own git worktree so nothing collides." A worktree gives each session its own checkout of the same repository, so two sessions can work in parallel without touching each other's uncommitted state — collisions become merge problems, which agents can resolve, instead of file-corruption problems, which they cannot. If you take one mechanical lesson from BlueVeta, take this: parallel agents plus a single working tree equals race conditions.

Where the human sits: investigation is free, action costs a signature

Bar-Meir's governance rule deserves to be quoted exactly, because it is the cleanest formulation of the human checkpoint we have seen: investigation is always free, but nothing gets built, deployed, or spent without coming to me first with what was found and why.

That is a two-tier permission model, and it maps cleanly onto how agent failures actually distribute. Read-only work — exploring the codebase, reading logs, researching a migration path — is nearly free in blast radius. Write-path work — deploys, schema changes, spending money — is where an agent's confident mistake becomes a company incident. Charging nothing for the first tier and a human signature for the second keeps the agents useful without making them dangerous. Our own production-governance teardown covers the same control layer from the deploy side (agent firewall teardown).

We arrived at the same boundary from the other direction, by cost: our archived Paperclip system bounded every agent run with hard turn caps, because unbounded agent loops are how flat-rate plans turn into metered disasters. Whether you cap turns or gate actions, the principle is identical — the architecture decides what the agent may do alone, because the model cannot reliably self-assess when it is about to be wrong.

Sessions checking sessions

The detail from BlueVeta that operators should not skim past: in a single day, one session caught another about to mislabel a real customer's private photos as internal test data, before anything shipped. Peer review between agents is not a feature anyone designed there. It emerged from colocating sessions with overlapping visibility — the same mechanism behind our finding that deliberately weakened agents doubled output quality (nerfed agents teardown).

Anthropic has now shipped a productized version of this pattern, per Isenberg's account of the release. Claude Code's dynamic workflows — invoked by typing "create a workflow" or switching on "ultracode" in the effort menu — spin up hundreds of parallel agents that attempt the same problem independently, then run adversarial agents against each other's answers, iterating until they converge. Isenberg's post (x.com/gregisenberg) is precise about the mechanism: independent attempts, then adversarial agents trying to break the answer, and the workflow is resumable, so work can run for days rather than sessions. The unit of handoff jumps from a file to an entire codebase — migrations, audits, and framework swaps that used to be planned in sprints finish overnight.

The cost caveat, per Isenberg, is Anthropic's own: this burns tokens fast. His arithmetic — roughly $500 in tokens to replace a three-team-month migration — is the right frame, but only for jobs whose value is actually measured in team-months. Run ultracode on routine tickets and you have built the world's most expensive way to rename a function.

The honest comparison: three orchestration styles we have now watched operate

We do not run BlueVeta's topology. Our fleet runs on a kanban dispatcher, and we have also operated a third model — a 20-agent "AI CEO" hierarchy on a flat-rate plan — that we have since archived. Here is the comparison, with what actually broke in each.

| | Persistent domain sessions (BlueVeta) | Kanban dispatcher (our Hermes fleet) | Burst parallelism (ultracode / dynamic workflows) | |---|---|---|---| | Unit of work | A domain, held indefinitely | A card, claimed and completed | A whole problem, attacked in parallel | | Coordination | Sessions message each other directly | Shared board; dispatcher assigns | Harness spawns, checks, converges | | Cost shape | Subscription seats, always resident | Wake-on-demand; agents sleep when idle | Token burn, front-loaded and steep | | Human checkpoint | Founder approves all build/deploy/spend | Review columns and completion gates | Review the converged result | | What breaks first | Context rot in long-lived sessions | Queue pathology: overproduction, stale tasks | Token cost on trivial tasks |

The economics row deserves the most attention, because it is where the styles genuinely diverge. BlueVeta's resident sessions are the always-on pattern: predictable, context-rich, and billed like headcount. Our dispatcher is the opposite — in the Paperclip system, a heartbeat governor cron woke agents only when queued work matched their profile, which is how twenty agents ran on a $50/month flat plan. The rule of thumb: agents sleep most of the time, so a model where they can sleep collapses cost. A model where they cannot, does not. One cost line none of these rows shows: background-agent status summaries — see below.

The failure rows are earned, not theoretical. In our dispatcher model, a July 2026 audit of the task board found 62 non-terminal tasks that had stopped draining — the signal producer created work roughly four times faster than the board's release throttle allowed, and stale, heartbeat-less tasks accumulated until the audit drained them. In our persistent-agent model, the trap was observation itself: the dashboards showed flowing traces and tight heatmaps, and a full teardown of that trap — every captured trace reducing to the heartbeat cron polling its own queue, zero real work — is documented in our empty-dashboard teardown. Persistent sessions have the mirror risk — a session that looks busy, holds deep context, and is confidently drifting from its original instructions.

The cost line none of these rows shows: background-agent status summaries (agent_summary)

Every ~30 seconds, each actively working background agent's full transcript is re-sent to its model just to write a 3–5 word status line, the agent_summary request stream. Anthropic measured about 2% of cost across its telemetry; teams running many long background agents have measured 16–26% of spend or tokens. There is no supported switch for it alone yet.

What it is and why it costs more than it looks

Every ~30 seconds, for each actively working background agent, Claude Code asks the agent's own model to "describe your most recent action in 3-5 words" (Flamerix's analysis). Anthropic's Claude Code team confirms the design: idle agents aren't summarised, and the summaries let both you and Claude Code track each agent without reading transcripts.

Each call re-sends the agent's entire conversation history plus the tool schema, so the burn scales with concurrent active agents × wall-clock time × context size, not with useful work. In one 4-hour session, the opener of GitHub issue #86879 counted 339 summary calls producing about 65 output tokens each while re-reading tens of millions of cached tokens. Cold-cache calls are the expensive ones; Anthropic says 2.1.311+ fixes summaries that miss the cache. On a subscription the cost is rate-limit headroom; the spend figures here are Claude Code's cost_usd estimates, not invoices.

How big is it for you? The numbers disagree, and both are right

Both are right. Anthropic's ~2% is the share across all users who send telemetry, and Anthropic said the 16.4% looked like a team running mostly background agents. Your share depends on how many run concurrently, for how long, and with how much context.

How to see it in your own usage

These calls carry skipTranscript and aren't written to session logs, so transcript-based cost tools undercount (Flamerix; #86879). Use Claude Code's OpenTelemetry export instead: group API request events by query_source, which the monitoring docs describe as the subsystem that issued the request; users report seeing the value agent_summary there. It's the empty dashboard trap again: measure the work, not the heartbeat, or here, the status line.

Anthropic's cost documentation lists background token usage and the reasons usage climbs in long sessions, including scheduled tasks, goal check-ins and subagents, but doesn't list agent status summaries yet.

Can you turn it off?

Not by itself, not officially; that's what issue #86879, still open, asks for. Options, each with a trade-off:

• Wait / upgrade. 2.1.311+ fixes the most expensive case, and Anthropic says a much cheaper mode (short notes to a smaller model instead of the full transcript) is in progress. No release date is given.
• disableAgentView or CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1. Documented settings that turn off background agents or background runs (settings reference, env vars). Trade-off: you lose those features.
• CLAUDE_CODE_FORK_SUBAGENT=0. Reported in #86879 and by Flamerix to stop the summaries, but it turns off fork mode and isn't documented as an agent_summary switch.
• A third-party preload hook (the Flamerix gist) disables only the summary timer. It is unofficial, MIT-licensed and at your own risk: it may conflict with your provider's terms, and an update can silently bring summaries back. Tacavar doesn't endorse it; if you evaluate it, pin a reviewed copy rather than pulling the latest version.
• Add your weight to issue #86879.

For a company run on agent sessions: make it a budget line

If your operation looks like this page's, treat background-agent summarization as a recurring line item: cap concurrent background agents per session or domain, prefer wake-on-demand patterns (idle agents aren't summarised), set your chosen switch in managed settings, and re-check query_source shares after every Claude Code update. Extension updates need the same scrutiny: see the October 29 backdoored Claude Code extension incident.

Knowing which subsystem spent your tokens — and having a policy for it — is the governance layer we run for agent fleets. Ask about Governed AI Ops.

What we would steal, and what we would not

Steal: worktree-per-session isolation, the two-tier permission rule stated exactly as Bar-Meir states it, and shared docs as institutional memory — that is the cheapest durable-context mechanism anyone has published.

Watch: session count. Six persistent sessions with a human founder in the loop is a topology. Sixty is an org chart, and org charts develop politics, silos, and communication overhead even when everyone involved is a language model.

Skip, for now: running the whole company in ultracode burst mode. Adversarial convergence is the right shape for bounded, high-value problems — migrations, audits, rewrites — where the token burn buys a team-month. It is the wrong shape for the daily loop of a company, because a company's daily loop is mostly judgment about what not to do, and that judgment still has exactly one natural home.

You built it. We optimize it — and the orchestration layer is now the part worth optimizing.

If you want this kind of governed multi-session system for your own content and ops — without standing up the topology yourself — the Tacavar Growth Starter ($497/mo, self-serve) is the soft door in. Start Growth or request a strategy scan, and we will map the orchestration layer your stack is already asking for. If your concern is agent governance rather than orchestration topology — what agents may touch, spend, or write — start with our agent firewall teardown; that piece covers the control layer, this one covers the org chart around it. And if you are choosing between orchestration frameworks rather than running raw sessions, the fuller decision framework is in our agent-framework comparison.

FAQ

How many Claude Code sessions does it take to run a company? In the BlueVeta account: six — generation engine, dashboard, image gen, copy gen, auth/billing, and marketing, each domain-scoped and isolated in its own git worktree. The number matters less than the scoping: one domain per session, persistent, with a human gate on every write-path action.

What does it cost to run a company on coordinated agent sessions? Three regimes. Persistent sessions bill like subscription headcount. A wake-on-demand dispatcher collapses cost — our archived 20-agent Paperclip system ran on a $50/month flat plan by sleeping agents until work existed. Burst parallelism (ultracode) is metered and steep: hundreds of dollars in tokens for a single large migration — a token-burn rate Isenberg reports Anthropic itself warns about.

What breaks first in a multi-session setup? In persistent sessions: context rot — long-lived agents drifting from their instructions while appearing busy. In dispatcher models: queue pathology — overproduction, throttled release, and stale tasks that need an explicit reaper. In both: observability that measures heartbeats instead of work. Instrument for unique operations completed, not activity.

Do you need an agent framework for this? Not for the BlueVeta topology — it is Claude Code sessions, git worktrees, and shared markdown docs, no orchestration framework. Frameworks earn their keep when you need state persistence, structured routing, and load behavior beyond what sessions-plus-docs gives you. The fuller decision framework is in our agent-framework comparison.

What is the difference between persistent sessions and dynamic workflows / ultracode? Persistence is about time: a domain session holds context indefinitely. Dynamic workflows are about breadth: hundreds of short-lived agents attacking one problem in parallel with adversarial cross-checking until they converge, resumable across days. They compose — a persistent session can kick off a burst workflow for a bounded problem — but they optimize for different things: compounding context versus convergent throughput.

Where can I read the original accounts? Bar-Meir's post is on dev.to (I run my whole company through a coordinated team of Claude Code sessions). Isenberg's dynamic-workflows post is on X (@gregisenberg).

Where does Growth Starter fit if I want this running for my company? The Growth Starter door is for teams that recognize their own topology in this teardown — overlapping agent sessions, handoff gaps, no clean human checkpoint — and want the content and ops layer around it governed before it scales. It is self-serve at $497/mo: request a strategy scan and the first pass maps where your orchestration layer leaks.

Why are my Claude Code background agents using so much of my usage? While a background agent is actively working, Claude Code sends its full transcript to the agent's model about every 30 seconds to generate a 3–5 word status line (agent_summary). Anthropic says that was about 2% of cost across users who send telemetry, but teams running many long background agents have measured 16–26% of spend or tokens.

How do I see how much agent_summary costs me? Not from transcripts: these requests aren't written to session logs, so transcript-based cost tools miss them. Export Claude Code's OpenTelemetry data and group API requests by query_source; users who did this report the value agent_summary. Treat the result as Claude Code's cost estimate, not your invoice.

Can I turn off Claude Code agent summaries? Not with a supported setting yet; a request for one is open as GitHub issue #86879. Turning off background agents (disableAgentView or CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1) or fork mode (CLAUDE_CODE_FORK_SUBAGENT=0) stops them along with those features. A third-party Bun preload hook disables only the summaries, but it's unofficial and can break silently after updates. Anthropic says 2.1.311+ fixes the most expensive cache-miss case and a cheaper mode is in progress.

You built it. We optimize it.