The state of team AI coding

A day with it

On Monday the PM decides refunds go to store credit. On Tuesday a developer's agent opens the refunds code and is told that decision before it edits. It isn't sure whether expired cards count, so it records its assumption and keeps going; the PM gets a link and answers in a line before the work is finished. When the developer stops half-way, the next person starts from a handoff, and the pull request links the reasons for the change.

The problem it leaves you with

It doesn't run your agents, show a whole session as a replay, run tests or replace your tracker. Feedback from Slack, calls or customers reaches it only when someone brings it in from a link. There are no audit logs yet.

The better choice when

• Several people run agents on one codebase and keep tripping over each other's decisions.
• Product, QA or the founder need to follow the work and answer agents' questions without reading code.
• Code must stay on your machines: Campfyrr keeps decisions and reasons, never code or transcripts.

A day with it

A developer working alone keeps conventions in CLAUDE.md, which is reviewed like code. Auto memory remembers their habits, and cross-session messaging warns their other sessions when one breaks what another builds on. For one person, it all works well. Then a second developer joins: the call the first one made at 10am never reaches the second one's 11am session.

The problem it leaves you with

Everything except CLAUDE.md belongs to one person: auto memory is "machine-local… not shared across machines", and "a project belongs to one user. You can't share a project." CLAUDE.md holds standing rules, not this week's calls or what an agent assumed. Shared team memory is an open feature request.

The better choice when

• You work alone, or each person owns their own repository.
• Your team's decisions rarely change once written into CLAUDE.md.

With Campfyrr

Keep it. Standing rules stay in CLAUDE.md; this week's calls, assumptions and handoffs go in Campfyrr.

A day with it

A developer finishes a session and runs one command; the whole run becomes a page teammates read, comment on and search, and the next agent can start from a summary of it. It's a good way to teach and review. But on the same day, a teammate who never opened that link has their agent build on the opposite of what it decided, and loses an afternoon undoing it.

The problem it leaves you with

Someone has to share, and someone has to open the link: automatic capture was built and then removed in September 2026. It uploads full transcripts, code included, with no secret scrubbing on your machine, and the plugin ships for Apple Silicon Macs only.

The better choice when

• You want to show, review or teach from a whole agent run.
• You want a shared, versioned skills library.

With Campfyrr

Different problems: Lore shows one run; Campfyrr gets the team's calls into every session without anyone sharing.

A day with it

Copilot's agents learn facts about the repository as they work and share them across Copilot's coding agent, review and CLI; Agent HQ lets the lead assign and track Copilot, Claude and Codex agents in one place. Then a developer's own Claude Code session, outside Agent HQ, undoes the call the PM made on Monday, because Copilot's memory only serves Copilot's agents.

The problem it leaves you with

Memories are facts about the code, and they expire after 28 days: not who decided what, or why. Nobody outside engineering is told anything, and an agent's guess never reaches the person who knows.

The better choice when

• Your agent work starts from GitHub issues and ends in Copilot-reviewed pull requests.
• You want one place to steer several vendors' agents.

With Campfyrr

Keep Agent HQ for the agents it runs. Campfyrr covers developers' own Claude Code, Codex and Cursor sessions; it doesn't brief agents started from Agent HQ.

A day with it

Agents find code fast through its index and dependency graph, and get decisions and handoffs from earlier sessions automatically. When a new decision overlaps another session's, it flags it and asks the developer at the keyboard which stands. The PM, though, only hears what the agents assumed when someone tells them.

The problem it leaves you with

"Indexing sends eligible source contents to ContextStream", and it saves transcripts by default. Clashes are settled by whoever is in that session, and nothing is written for people who don't read code. It costs several times more per seat.

The better choice when

• Fast code search and a code graph are what your agents lack most.
• The team is all engineers, and sending source to a hosted index is fine.

With Campfyrr

The overlap is large; if you use both, keep decisions in only one.

A day with it

Two agents start changing the same invoice function; Kawa flags the overlap before either commits and can propose a safe merge. The same afternoon, another agent writes the invoice email on an old pre-tax note against the PM's newer rule. No lines overlap, so nothing flags it.

The problem it leaves you with

It catches clashing lines, not clashing decisions, and it retired its before-edit check on 14 August 2026, so an agent learns past decisions only if it asks. The desktop app must be running, and nothing reaches people outside engineering.

The better choice when

• Agents and teammates keep editing the same lines before commit.
• You want safe merges proposed for you.

With Campfyrr

Complementary: Kawa watches the lines, Campfyrr the calls.

A day with it

Every agent session is saved with the commit it produced, so a reviewer can trace any line back to the conversation behind it. That answers "why?" well, at review time. But the agent that reversed the PM's checkout decision had already built and opened the change before anyone asked.

The problem it leaves you with

It works from what was captured at the commit: the reasons arrive after the change, and its memory plugin briefs an agent only when the agent asks. It keeps full transcripts in git, code included. Its planned coordination layer isn't a documented feature yet.

The better choice when

• You need an audit trail of every agent session behind every commit.
• Reviewers want to trace a line back to the conversation that wrote it.

With Campfyrr

They fit: Entire records what happened; Campfyrr gets the reasons to the next session before it changes something.

A day with it

A developer runs three agents in separate worktrees and reviews their branches in one window; nothing collides. But one agent stores money as whole cents and another as decimal strings. Both merge cleanly, and the next day costs someone an afternoon of rework.

The problem it leaves you with

It keeps agents out of each other's files, not out of each other's way: two agents can still make clashing calls. With Conductor Cloud, code lives in their cloud.

The better choice when

• You're one developer running several agents and reviewing their work.
• File collisions between parallel agents are your main pain.

With Campfyrr

Use both: worktrees keep agents out of each other's files; Campfyrr keeps them on the same decisions.

A day with it

A PM and a developer steer one run together and decide that a paused plan keeps its renewal date; non-engineers can start work from Slack. Meanwhile another developer's separate run on the billing page assumes the opposite, because runs don't hear about each other's calls.

The problem it leaves you with

It aligns the people in one run, not every run on the product. You move your agent runs onto its platform, and an agent's guesses aren't routed to the person who knows.

The better choice when

• You want one hosted place where every role watches, steers and starts runs.
• You have a large team: the flat price is cheaper from about 15 developers.

With Campfyrr

Different bets: Superconductor is where agents run; Campfyrr keeps runs in step wherever they run.

A day with it

The team opens a code channel for a task; the plan, diffs and a preview live there, and a named person approves before commit. The PM approves a refunds preview that looks right. On Friday a customer complains: the agent assumed refunds go to the original card, and nobody saw the assumption.

The problem it leaves you with

One channel per task: what one task decided doesn't carry into the next, and an agent's assumptions aren't put to the person who knows.

The better choice when

• You want to watch, steer and approve one task where everyone already works.

With Campfyrr

They meet in Slack: Campfyrr posts milestones there.

A day with it

Agents start from issues, teammates follow and steer the sessions, and Pulse writes a daily summary for the manager. The summary says the refunds ticket moved. It can't say what the agent assumed about expired cards, because that never lived in a ticket.

The problem it leaves you with

Its context is issues, not what agents decided or assumed while working, and it covers Linear's own sessions, not agents run elsewhere.

The better choice when

• Linear is your tracker and ticket-level progress is what the business asks about.

With Campfyrr

Keep Linear as the tracker; Campfyrr adds what the agents decided and assumed.

A day with it

An engineer's agent remembers their preferences and the facts they taught it, session after session. Then it builds on yesterday's plan, unaware that a teammate decided to move the jobs to a queue. The memory knew the engineer's habits, not the team's call or why it was made.

The problem it leaves you with

Facts, not decisions with owners and reasons, assumptions or half-finished work; mostly built for one person, and nothing for people who don't read code.

The better choice when

• You work alone, or want your agent to remember your own habits.

With Campfyrr

Most engineers on a shared product want both: preferences in a memory server, decisions in the team's record.