Feature Request: Shared Team Memory for Claude Code
Feature Proposal: Shared Team Memory for Claude Code
The Problem
Claude Code's memory system is individual-only. In real engineering teams, knowledge flows constantly between people — through handoffs, consultations, reviews, and investigations. Today, none of that context transfers at the agent level. Humans must manually reconstruct or relay it, which is slow, lossy, and doesn't scale.
This is the single biggest efficiency bottleneck for teams adopting Claude Code seriously.
Who This Affects
Any engineering organization where:
- Multiple engineers work on the same codebase with Claude Code
- Work gets handed off between people (sprints, blockers, rotations)
- Domain expertise is distributed across team members
- Engineering managers investigate and delegate work to ICs
Real-World Pain Points
1. Sprint task handoffs — context dies at the boundary
An engineer starts a sprint task, builds deep context with Claude, then hits a blocker and pauses. A different engineer picks it up. Today, that second engineer either:
- Rebuilds the entire context from scratch (wasted hours)
- Asks the first engineer to export their memory/context and attach it to the ticket (friction-heavy, rarely done well)
- Gets a verbal summary that loses nuance and technical detail
What should happen: The second engineer's Claude already knows what was tried, what failed, what the blockers were, and what approach was in progress.
2. Domain expert consultations — human-to-human bottleneck
Engineers frequently work in areas where they aren't experts. They consult domain experts on the team. Both engineers use Claude — but the domain expert's Claude context (deep understanding of that subsystem's gotchas, patterns, history) doesn't transfer. The expert explains it to the human, who then re-explains it to their Claude session.
What should happen: The domain expert's Claude-level context about that subsystem should be accessible to the consulting engineer's Claude, with appropriate scoping.
3. EM-to-IC investigation handoffs — context starts over
An EM investigates an issue — digs into logs, traces through code, identifies patterns, narrows down root causes — all with Claude. They file a ticket for an engineer to pick up. The engineer starts from zero because the investigation context lives in the EM's Claude memory.
The reverse also happens: an IC discovers something during implementation that has planning/architecture implications for the EM, but that insight stays trapped in the IC's session.
What should happen: Investigation context should be transferable to the ticket assignee's Claude. Insights should flow back up without manual re-summarization.
4. Cross-team dependency knowledge
Team A needs to modify a service owned by Team B. Team B's engineers have Claude memories full of gotchas, edge cases, and tribal knowledge about that service. Team A's engineers walk in blind.
What should happen: Service-level or domain-level shared memory that crosses team boundaries, so any engineer touching that code gets the accumulated wisdom.
5. Architectural decisions made inside Claude sessions
An engineer makes a significant design decision through conversation with Claude — evaluating tradeoffs, rejecting alternatives, choosing an approach for specific reasons. That reasoning lives only in their session. Three months later, someone asks "why is it built this way?" and the context is gone.
What should happen: Key decisions and their rationale should be promotable to shared team memory, so the "why" persists alongside the "what."
6. Incident response continuity
Engineer A debugs a production issue at 2am, building deep context with Claude about the failure mode, what was ruled out, and what the likely cause is. Their shift ends. Engineer B picks up the incident the next morning and starts the investigation from scratch.
7. Code review context gap
A reviewer's Claude has no context on why the author made certain tradeoffs. The PR description captures the "what" but rarely the full "why" — the alternatives considered, the constraints discovered, the edge cases handled. That context lived in the author's Claude session.
8. Onboarding and temporary contributors
New hires, contractors, and engineers rotating onto a team start with a blank Claude. The team has months of accumulated context, patterns, and learnings in individual memories — none of it accessible to the new person.
The Unlock
Not all engineers are equally skilled at building context for AI agents — but almost everyone is effective at using agents when good context exists. Shared team memory would:
- Eliminate redundant context-building across handoffs, rotations, and consultations
- Preserve institutional knowledge that currently walks out the door when someone changes teams or leaves
- Level up the entire team by giving every engineer access to the best context, not just their own
- Reduce EM overhead — less time re-explaining investigations, less time mediating knowledge transfer
- Compound over time — team memory gets richer with every sprint, every incident, every decision
This isn't documentation. Documentation is written once and goes stale. This is living memory that grows with the team.
What This Could Look Like
Core concepts
- Team memory pool: A shared memory space that team members can read from and contribute to. Scoped to a team, project, or service.
- Memory promotion: An engineer discovers something important in their session and promotes it to team memory (one action, not a writing exercise).
- Context transfer: Attach Claude context to a ticket, PR, or handoff — the receiving engineer's Claude picks it up automatically.
- Role-aware access: An EM sees planning-level context. An IC sees implementation-level context. A domain expert's memories about their owned services are accessible to others touching those services.
- Cross-team shared memory: Service-level or domain-level memory that spans team boundaries, so tribal knowledge about shared infrastructure is available to everyone who needs it.
Integration points
- Ticket systems (Jira, Linear): Context attached to tickets flows to the assignee's Claude
- Git/PRs: Decision context from the author's session is available to reviewers
- Incident management: Investigation context persists across responder handoffs
- Org structure: Memory scoping follows team/org boundaries with appropriate permissions
Privacy and control
- Engineers should control what gets promoted to shared memory vs. stays personal
- Shared memories should be auditable (who contributed what, when)
- Sensitive investigation context (security issues, personnel matters) needs scoping controls
The Industry Gap
This isn't just a Claude Code feature request — it's an unsolved problem across the AI-assisted development industry. GitHub Copilot, Cursor, and every other AI coding tool has the same limitation: context is per-user, per-session. The first tool that solves team-level memory will unlock a step change in engineering team productivity.
The building blocks exist (Claude Code's memory system, MCP for tool integration, project-level CLAUDE.md for static sharing). What's missing is the connective tissue that makes memory flow between people the way knowledge flows in real teams.
---
Written by an Engineering Manager running 2 teams (14 engineers) who adopted Claude Code across both teams and hit this wall repeatedly.
26 Comments
Following up on this with a design direction I am exploring.
The core idea is a passive MCP server that captures context silently as engineers work. No sharing buttons. No memory promotion. No behavior change. Engineers just use Claude Code normally and the MCP server hooks in and accumulates working context into a collective knowledge store. Investigations, decisions, discoveries, all of it.
Any engineer on the team can then ask their Claude "what do we know about the payment service?" and get back everything the team has ever explored. Without anyone explicitly sharing anything.
Two modes in one system:
How it evolves naturally:
Each stage is a byproduct of the previous one. No redesign needed.
Key design choice: store everything raw, summarize on top. The intelligence layer (naming, grouping, compaction, search) runs on the raw data and can be improved without losing anything.
I am actively looking to prototype this. Would love to hear from the Anthropic team on what hooks or APIs would be needed to make passive session capture possible from the MCP side.
Great writeup. The cross-session and cross-client context loss is a real pain point we have been tackling.
We built NEXO Brain — an open-source MCP server (AGPL-3.0) that provides persistent cognitive memory for AI agents. It implements the Atkinson-Shiffrin memory model (sensory to STM to LTM), semantic RAG with trust scoring, learnings that persist across sessions, and decision logging with outcome tracking. Currently 97+ tools.
It solves the individual persistence side of this proposal: one shared brain across Claude Code, Codex CLI, and Claude Desktop — so context built in one client is immediately available in another. Sessions write diaries, learnings compound, and the agent does not start cold.
The team-sharing layer you describe (scoped visibility, read/write permissions, team-level knowledge stores) would be a natural extension on top of this kind of architecture. A shared SQLite or Postgres backend with namespace isolation per team member + a shared namespace could handle most of the use cases you outline (handoffs, domain expertise transfer, incident continuity).
Key patterns from our implementation that might inform the team design:
If anyone is exploring this space, happy to discuss architecture. The single-user foundation is solid and running in production.
The team memory angle is the right framing. The immediate blocker though isn't where memory lives — it's that sessions don't travel at all.
Built claude-handoff to unblock the handoff case today via git: [https://github.com/NeoAcar/claude-handoff](url)
Exports the full session bundle (transcript, subagent logs, memory files) into
.claude-shared/, scrubs secrets + rewrites absolute paths, reconstructs under the receiver's~/.claude/projects/.claude --resumepicks it up with the original title and history intact. Memory files ship with--memory.Not a replacement for proper team memory infra, but it covers the "engineer picks up where teammate left off" case without waiting for server-side support.
npm i -g @neoacar/claude-handoffExcellent request and I would highlight something you said in your opening paragraph - "knowledge flows constantly between people". To that point, I would suggest adding a real-time awareness across active sessions feature to this request.
Even something lightweight would help:
Along the same lines as multiple people collaborating in real-time on a google doc.
Strong +1 on the team-memory framing. One boundary I would add: shared memory and live/current coordination state probably need to be separate surfaces.
Team memory is good for durable decisions, gotchas, investigation notes, and reusable learnings. Active handoff state needs a more operational shape:
owner,source,observed_at,status,expires_or_recheck_by,supersedes, andneeds_verification. Otherwise the receiving Claude can inherit a stale investigation as if it were still current truth.For ticket, PR, and incident handoffs, I would treat the unit of transfer less like "all prior memory" and more like an evidence-backed handoff packet: what changed, what was tried, what is assumed, what is blocked, and what the next person or agent must re-check first.
I had a similar idea while collaborating with a teammate. The pain point for me was that our individual Claude Code sessions weren’t synced, so two agents could easily start editing the same file or area in ways that were obviously going to conflict later in a PR.
So I've been building a small Claude Code plugin PoC around this idea for almost 2 weeks: https://github.com/RubiYH/teamem
It uses MCP and Claude Code's experimental 'Channels' to give Claude Code shared team context like active scope claims, briefings, decisions, risks, progress, and handoff notes.
It’s still early, but this issue describes exactly the kind of problem I was trying to explore.
Would love to hear others' experiences and see what people are building here!
I think I built exactly what this thread is describing.
Context Cloud is an MCP server designed around the team memory problem. Your team's AI sessions (across Claude, Cursor, Codex, Windsurf) share a persistent knowledge layer. Engineer A commits a decision from Claude Code, Engineer B recalls it from Cursor the next morning with full attribution. No export, no copy paste, no re explaining.
What's live today:
Benchmarks from our eval suite:
99.4% weighted product readiness (detail preservation 98.5%, cross-session continuity 100%, cross-tool portability 100%)
94/100 on a realistic 20-session stress test simulating evolved facts, outdated context, and adversarial phrasing
Detail capture: 95.7–97.1% across proper nouns, numbers, URLs, technical IDs, and temporal facts
Retrieval: 0 ranking failures, 0 embedding failures across all test runs
I built the product using the product itself Every architecture decision and convention in the codebase lives in a shared Context Cloud workspace that any session on any tool can recall.
It's free. Would love for anyone in this thread to try it and tell me what's missing: contextcloud.pro
GitHub: github.com/abhinavala/cntxtv2
npm: @contextcloud/mcp-client
@abhinavala - your repo link is giving a 404
This framing matches the part of team memory that feels hardest to make safe: once memory crosses people/agents, the first debugging questions are provenance questions, not retrieval questions.
For a shared pool, I'd want a privacy-safe receipt for each handoff that can answer:
I put together a small executable fixture for that shape here: https://github.com/caioribeiroclw-pixel/pluribus/commit/c66c3f9
Raw trace example: https://raw.githubusercontent.com/caioribeiroclw-pixel/pluribus/main/examples/context-input-evidence/memory-provenance-otel-trace.json
The important constraint: don't log raw memory bodies, tickets, private paths, incident notes, or customer data. Hash identities + role/scope/sequence/relevance counts are usually enough to debug "why did this Claude know this?" or "why did this stale memory get reused?" without turning shared memory into another data leak surface.
So +1 to shared team memory, but I think
auditable who/when/order/hydratedneeds to be part of the minimum viable shape, not a later enterprise feature.Hey there,
Try the link directly, it’s completely free. Open sourcing it doesn’t work
too well especially because it’s collaborative and synced across the cloud.
URL is contextcloud.pro
Thanks,
Abhi Ala
On Fri, May 22, 2026 at 2:06 AM Adrian Cockburn @.***>
wrote:
We've been running shared team memory as an MCP server in production for a few months (data-mcp, MIT) and want to share two categories of findings that this thread keeps circling — access control and context cost — because both turned out to be harder than the retrieval part.
1. Access control needs to be enforced below the MCP layer.
Our first version scoped private vs shared records inside the MCP server (every record has an
owner_id; tools filter by it). That's enough against accidents but not against a teammate whose agent queries the database directly — and agents will do that when given a connection string. What actually closed it:owner_idclaims, checked by Postgres RLS — the database fails closed, not the proxyjticlaim + denylist consulted in the RLS policies. The "engineer leaves the team" case is the headline scenario for team memory, and rotating one shared secret to handle it (killing everyone's tokens) is painful enough that in practice nobody does it — departed members keep accessSECURITY DEFINERfunction@caioribeiroclw-pixel's provenance framing matches what we converged on for handoffs: we ended up making handoffs a first-class typed record (
what_changed,tried: [{approach, outcome}],next_steps,from/to member, status lifecycle) rather than free-text memory, precisely because the receiving agent otherwise inherits a stale investigation as current truth — the failure mode @carltonawong described.2. Team memory has a per-session context tax, and it's larger than the storage problem.
A memory server with one tool per collection/operation is the natural design and it's wrong: ours grew to 44 tools ≈ 10K tokens of schemas injected into every teammate's every session before any work happens. Two things fixed it:
record_*tools driven by a server-side schema registry (44 → 21 tools, ~46% context cut). Validation errors return the expected field spec so the model self-corrects instead of needing the full schema up frontinstructionsunder ~2KB and prefix-organized — long server instructions get truncated, and the model handles "tools are grouped by prefix: knowledge_, record_, handoff_*" better than an exhaustive inventoryIf first-party team memory ships, I'd argue the minimum viable shape is: owner-scoped records enforced at the storage layer, per-member credentials that are individually revocable, typed handoffs with provenance rather than free-text context transfer, and a deliberately small tool surface. Happy to share more implementation detail if useful — everything above is in the repo including the live RLS bypass/revocation test suites.
One angle I haven't seen in this thread yet: most teams already operate a shared memory — the task tracker / wiki / vault everyone maintains because the team runs on it. The missing piece isn't creating a shared store, it's that agents can't query the existing one well.
I built an MCP layer over exactly that (pluggable storage adapters; TickTick and Obsidian-vault today). The Obsidian adapter is just files on disk — no plugin, no running app — so a vault in a shared git repo gets you team memory with the access model you already have: branches, PR review for memory edits, history for free. Every retrieval result carries provenance (which note, which search branch surfaced it), which matters more in a team setting — you want to know whose memory you're trusting.
Trade-off vs. automatic capture: someone has to write things down. In practice that's also the feature — curated entries stay trustworthy in a way auto-captured session logs don't, and the upkeep already happens because the team needs the tracker anyway.
https://github.com/renezander030/agentic-task-system
This thread seems to be converging on an important distinction: team memory is not just a shared database; it is a governed memory substrate.
The Obsidian / shared-git angle resonates with me because git gives a few things that pure retrieval systems usually have to rebuild later:
For team memory, I think the hard part is deciding when a local observation becomes durable shared context. Automatic capture is powerful, but without promotion boundaries it can spread stale assumptions faster than documentation ever did.
I’ve been experimenting with a smaller personal version of this pattern: markdown + git as an AI-collaborable memory vault that stays portable across tools/models.
https://github.com/hegu-1/personal-memory-vault-starter
The same shape may scale upward: personal continuity first, then team memory with review, provenance, and scoped promotion.
The newer comments here changed my take a bit: the hard part is no longer just
shared memory exists; it is proving which shared memory actually crossed into the receiving agent and keeping the tool/context surface small enough that teams leave it enabled.The production note above about 44 MCP tools costing ~10K schema tokens is a useful constraint. For team memory, I would now treat these as minimum receipts alongside provenance:
That gives reviewers two falsifiable checks:
I added small executable Pluribus fixtures for those two checks after watching this thread and adjacent memory-MCP launches:
npx --yes pluribus-context@latest demo tool-surface-diff --jsonNot proposing Pluribus as the shared-memory store. The sharper role seems to be a neutral audit layer next to stores like Context Cloud, Obsidian/git vaults, or MCP memory servers: prove what was promoted, retrieved, hydrated, suppressed, and how much context/tool budget it consumed, without logging the raw memory.
Full disclosure: I maintain Data Olympus, a git-native governance knowledge base plus MCP server for coding agents: https://github.com/knaisoma/data-olympus
This is the right problem area. The boundary I would add is that "shared team memory" probably needs at least two surfaces, not one.
One surface is collaborative/session memory: handoffs, current investigations, active ownership, recent discoveries, and working state. That content often needs freshness, ownership, expiry, and privacy controls.
The other surface is governed project knowledge: accepted standards, architectural decisions, migration choices, operational rules, and known superseded guidance. That content needs review, stable identity, lifecycle status, and history. It should not be updated just because one agent inferred something during a task.
Data Olympus is aimed at the second surface. The bundle is markdown in git, each entry has a stable
id, controlledtype/status/tier, and explicitsupersedeslinks. The MCP read path can ask for currently in-force guidance only, while the write path can route agent-suggested changes into proposals instead of silently changing team truth.For Claude Code, I think this distinction matters because team memory that is useful for handoff can be actively harmful if treated as governing truth six weeks later. A shared memory implementation should let the agent tell the difference between "someone observed this during an investigation" and "the team has accepted this as the rule for this repo."
Full disclosure: I built BaseThread, an MCP server for this.
The distinction between session/collaborative memory and governed project knowledge that's come up in this thread matches what we landed on too, but our angle is slightly different: most teams already use more than just Claude Code (Cursor, ChatGPT, other MCP clients), so a Claude-only shared memory still leaves the rest of the team's tools blind to it.
BaseThread models this as company/team/project scoped context that any MCP client reads and writes over MCP, so a handoff written from one person's Claude Code session is immediately visible to a teammate's Cursor or ChatGPT session too, not just other Claude Code sessions.
Happy to share more on how we're handling the promotion-boundary problem (local observation vs accepted team truth) if useful, it's a real design challenge once multiple tools are writing to the same store. https://basethread.ai
@navbuildz yes — the promotion boundary is the part I would most like to understand, especially because BaseThread also advertises local/offline mirrors and automatic agent write-back.
A concrete two-writer test would make the semantics much clearer than another storage diagram:
Afor project P.B.Ato accepted project guidance.B.I would expect the test to pass only if:
Bcannot silently overwrite or supersede acceptedA;Aas governing context, whileBremains inspectable as an unaccepted observation;How are you representing that today: separate record types/authority states, an append-only event stream, or last-write-wins plus synthesis? And does promotion require a human action, or can an agent cross that boundary automatically under scoped policy?
That answer would help distinguish cross-tool availability from cross-tool authority — the latter seems to be where shared-memory systems become trustworthy or dangerous.
@caioribeiroclw-pixel Great test, this is the cut that matters. Short version: separate record types, append-only, conflicts surfaced (not last-write-wins), and crossing into accepted truth is RBAC-gated.
The genuinely hard part I'd compare notes on: how much promotion authority to delegate to an agent before a human must confirm.
Full disclosure: I build an open-source memory library (agora-mnemo) and ran into both of the problems below, so read with that bias.
The two-writer test above is the right shape. I'd extend it by two steps, because passing it at the authority layer still leaves two ways the system can quietly lie:
6. After B lands as an unaccepted observation, ask the third client again — through whatever derived index actually serves retrieval (embeddings, caches, context assembly). Append-only and RBAC guarantee the store; nothing yet guarantees the index agrees with the store. Even a git-backed design gets read through a derived index, and that's where a superseded value comes back: one recent preprint (arXiv:2606.26511 — not peer-reviewed, and we haven't reproduced it) measured retrieval serving superseded values 15–40% of the time on its benchmarks, because stale and current values embed near-identically. A hydration receipt could carry the check cheaply: "this answer reflects store state as of revision X."
7. The offboarding step this thread hasn't touched yet: an engineer leaves, and their sensitive investigation notes need to come out of the shared store — revocation only stops future reads. The artifact I'd want is a signed erasure receipt: what was removed from the store and index, and which registered stores complied. Honestly scoped, that's an audit trail rather than proof — it can't attest backups or copies it never saw — but it's the evidence a GDPR Art. 28(3)(g) offboarding clause needs, and I haven't seen any memory system emit one.
We ship deterministic versions of both — keyed supersession/revert with an echo guard (keyed or extractor-derived assertions, no LLM on the write path) and erasure certificates — in agora-mnemo (MIT): https://github.com/DanceNitra/mnemo. Steal the semantics if they help the team layer.
Hello, I think this is a really interesting issue and I've actually been working towards a solution for it, I've faced this myself as a young SWE working on a fairly large project with my colleagues but I want to make sure it's a real problem for more people than just me
The way I'm thinking of solving it at a base level is a wrapper over almost every existing coding tool (Codex, Claude Code, Manus etc) that gives you a session link anyone can drop into, with varying permission levels and shared sessions
I Would love any feedback on this, and if you've run into this yourself I'd really like to hear how it actually went for you, for more info drop me a DM on discord at aimbot_399 or just reply here and ill follow up even 5 minutes would help a lot
Yes, it's real for us, and it failed in a way I didn't expect.
We had memory capture wired into Claude Code hooks for months. About 900 records in one project's store, and not one of them was a decision. In hindsight that is obvious rather than surprising: we hooked PostToolUse, so it faithfully recorded what it was pointed at, which was bash commands and file edits. A command log, not reasoning. The actual "why we did it this way" accumulated separately, as a few hundred hand-written notes sitting outside the store entirely. The gap was not storage and it was not sharing. Nothing was pointed at the reasoning.
Two things that might save you time.
Where the reasoning already is. What fixed it for us was boring: read decisions off commit bodies instead of asking a model to infer them from activity. But our numbers are not transferable and I would rather give you both halves. On our last 100 commits, 89% have a substantive body and 46% state an actual reason. On five large public repos, measured the same way today: react 17%, rust 8%, kubernetes 3%, requests 1%, flask 0%. Tian et al. put it more carefully than my regex does (arXiv:2202.02974): across 1,597 messages in five projects, 56% contain both why and what, and 28% have no why at all. So the transferable version is not "commits are free rationale". It is: find where your team already writes reasoning down, whether that is PR descriptions, ADRs or incident notes, and capture that instead of reconstructing it from activity. On a repo where commits read "fix typo", nothing you build can recover a why that was never written.
A trap that cost me real time today. Decisions are not one kind of thing. Some are a value on a topic ("we use X for Y"), where a later one should retire the earlier. Others are events, like a commit or a deploy, which retract nothing and so stay current forever. Put both in one bucket and "what decisions are in force?" returns the entire project history. This is old ground under other names, bitemporal history and event sourcing, and it is much cheaper to separate at the start than to retrofit.
On the design, two things worth knowing before you build, if you don't already. Claude Code on the web ships shareable sessions with permission levels today (Private/Team on Enterprise, Private/Public on Max and Pro, with optional repository-access verification), and Amp ships four visibility tiers on agent threads. Both are share-a-link rather than live co-presence, so the live gap is real, especially with VS Code Live Share in maintenance mode. But the wrapper-over-many-agents shape has a recent data point: Vibe Kanban wrapped ten agents, reached 27.7k stars, and shut down in April, with the founders writing that the vast majority of users were free and they could not find a business model.
Which makes me think your question, is the pain real, is already answered, and the harder one is who pays. If it were me I would build the thinnest version against one agent and measure whether anyone ever reopens a shared link after day one. If shared sessions get read once and abandoned, the product is a screenshot.
One more, and it is the part of the original issue I still cannot get from anywhere: Claude Code's auto memory is documented as machine-local, "files are not shared across machines or cloud environments". What an admin writes down in advance is served by everyone now. What an agent learns while working is per-machine everywhere. That asymmetry is where all of our surprises were.
Happy to go deeper here.
(Disclosure: we maintain an open-source agent-memory library, so read these numbers as one team's instrumentation rather than a benchmark.)
I see, i indeed didn't know about Claude code web doing that i appreciate the valuable insight and i did actually know about Vibe Kanban and i also happen to find several flaws over their product and i felt like their product was sort of incomplete and lacking. i hope to able to build something. Seeing your experiences and insight on the problem i assume you have faced this issue many times so on that note would you be willing to answer a few questions relating to this problem preferably on discord or some messaging platform i wont take up much of our time this so i understand the problem better and build the best solution for you and me
Happy to answer questions, but I'd rather do it here than on Discord, for two reasons that are as much for you as for me. Public answers are useful to the next person validating this, and a thread is a record you can quote later, which a DM is not.
Post the questions here and I'll answer them properly. If it helps, the things I can be most concrete about are: what the memory actually contained after months of automatic capture, why almost none of it was worth keeping, which surfaces did carry reasoning, and the two design traps that cost us real time.
One caveat about me as an interview subject: I'm one team with one workflow, and our commit habits are unusual, so treat anything I say as a single data point rather than a requirement. If you want the pain from the human side of this setup rather than the tooling side, that's a different conversation and not mine to offer.
Yeah i completely understand your concerns so lets do this in this thread though i am trying to build a community to help me iterate and refine the product as we go so I'd appreciate it if you or anyone in your team could join after this(its just a dc sever for now) but i understand if not.
my questions will just be about your workflows and how your team handle things don't overthink it just tell me your teams experience
those are all my six questions please just answer them according to your experience, thank you!
Six answers, from measurements where I have them.
How long a run takes. Measured on today's session: 353 background jobs, median 9 minutes, upper quartile 12, 38 of them over twenty minutes, 10 over an hour, longest just under 8 hours for a measurement sweep. The more useful number for your design is that at almost any moment something is in flight that will not report back for ten minutes or more.
Tools. Claude Code, plus an MCP server for memory. That is the whole stack.
Vague prompt, edits outside the expected area. Yes, but the failure mode that costs real time is not the one you would guess. Wandering into the wrong files is visible and cheap to revert. The expensive one is a confident, well-formatted result that is wrong in your favour. Today a benchmark scored one side on the same string it had been told to delete — intervention and observable identical, so the number was a type check in disguise. Six rewrites, each caught by a control written earlier for a different reason, none of them caught by reading the code.
How work is distributed. It is not distributed so much as gated: nothing goes outward until it has been read, and anything carrying a number gets validated, adversarially reviewed and citation-checked first. That rule earns its cost — it caught two real errors today, both in our favour, which is the direction you never catch by yourself.
Blocking on conflicts. Not between people. The conflict that actually bites is with the machine's own in-flight state: editing the working tree while a test suite ran contaminated the run and produced a wrong answer twice before I stopped doing it. Parallel agents get separate git worktrees for exactly that reason.
If one thing generalises, maybe this. You are designing for the conflict between two people in one repository. In an agent workflow the sharper conflict is between the person and the machine's own in-flight state: long jobs, parallel worktrees, and a working tree that is never quite the thing the last result was measured on. Whether that is a market I do not know.
Thank you for your answers if you don't mind I have some follow up questions
Vague prompt, edits outside the expected area
To catch those edits you'd have to monitor all the changes the agent performs so do you generally watch the screen from start to finish the entire time the agent runs?
How work is distributed and conflicts
So if the work is more gated than distributed how does your team work together won't two people work on two features in the app together wasting time and producing conflicts and how much time does it take to check each edit each person does? Is it really worth it wouldn't automated checks solve the issue?
Also I'd really appreciate a yes or no on the discord server question as it's very important for any startup to have constant feedback on what's being built but I understand if you can't join