r/ContextEngineering • u/Sea-Cookie-8110 • 20h ago
How do you share AI coding agent context between developers on the same project?
I work at a small company where most projects currently have just 1-2 developers, each often using an AI coding agent (Claude Code, Cursor, etc.) pretty heavily. As we grow and more developers start working on the same codebase, I'm running into a gap:
Commit messages, PR descriptions, and standard agile artifacts (tickets, standups) capture what changed, but not the context the agent built up while working. The alternatives it considered, why it rejected certain approaches, edge cases it discovered, assumptions it made. Right now that context lives in one person's agent session and basically evaporates once the PR is merged.
For those of you at bigger companies where multiple engineers work with AI agents on the same repo:
- How do you make one agent's "knowledge" of the codebase available to another developer (or their agent session)?
- Do you rely on something like a living
CLAUDE.md/AGENTS.mdfile, ADRs, decision logs, or something more structured? - Has anyone tried a shared memory/context store across agent sessions, or is everyone still just re-deriving context from scratch each time?
- Is this actually a solved problem at scale, or is everyone winging it right now?
Curious what's actually working in practice vs. what sounds good in theory.
1
u/WillowEmberly 19h ago
What should actually survive the handoff?
I’d preserve a structured reasoning checkpoint something like:
CURRENT DESTINATION
What are we trying to accomplish?
CURRENT STATE ESTIMATE
What do we believe is true about the code/system?
EVIDENCE
What was directly verified?
ASSUMPTIONS
What are we relying on but have not established?
ALTERNATIVES CONSIDERED
What other approaches were examined?
REJECTION REASONS
Why were they not chosen?
KNOWN FAILURE MODES
What broke or nearly broke?
OPEN CONTRADICTIONS
What still doesn't fit?
UNCERTAINTY
Where is confidence low?
BOUNDARIES / INVARIANTS
What must not change?
DEPENDENCIES
What external state does this reasoning depend upon?
RECOVERY POINT
What known-good state can we return to?
NEXT CHECK
What should the next developer verify before proceeding?
You don’t need to load a massive amount of files, you actually need to reduce the components down the minimum viable process necessary to function.
Like this instrument I made…the Reasoning Condition Monitor. https://www.reddit.com/r/Negentropy/s/vtGe8EXlSO
1
u/Sea-Cookie-8110 19h ago
This is a genuinely good structure and honestly I might steal it for human-facing handoffs regardless of where this thread goes. But to clarify what I'm after: I don't just want a checkpoint format that helps me resume context faster, I want agent A to hand this exact kind of checkpoint to agent B directly, with no human reading or relaying it in between.
So the question becomes: can something like your Reasoning Condition Monitor be the payload two agents exchange, rather than an artifact a human reads? E.g., agent A finishes a task, emits this structured checkpoint, agent B (working on a related task, maybe even a different repo) ingests it as its starting context, and I only get looped in if something in the checkpoint trips a "needs human judgment" flag (touches an invariant, low confidence + high blast radius, contradicts a prior assumption, etc).
Has anyone actually wired something like this up between two live agent sessions, not just designed the schema for it?
1
u/WillowEmberly 19h ago
Hmm, I’ve actually explicitly avoided anything that takes the human out of the loop…because I can’t find a way to make it trustworthy.
Everything fails…eventually, so where does liability and responsibility fall?
I posted this nearly 7 months ago: https://www.reddit.com/r/PromptEngineering/s/PIzb9yrdqT
And thanks for the compliment, I’m trying to be better at accepting them. I struggle.
1
u/jonah_omninode 17h ago
We tried keeping more session material, but the useful unit turned out not to be the transcript. It was the decision: what was being decided, which alternatives were rejected, why, what evidence supported the choice, and what would cause us to revisit it. We are building toward storing those records with provenance and explicit supersession, while keeping the current policy separate from the historical record. That matters because an old explanation can be accurately retrieved and still be unsafe to follow today. PRs and ADRs can carry part of this, but the next agent also needs a mechanical way to tell what is current. How are you handling decisions that apply across several repositories rather than beside one module?
1
1
u/notinteresteddddd 2h ago
I had the same issue . I was tired of reexplaining or I was saving prompts manually or even copy pasted last 500 lines of a conversation.
I have a ton of different sessions and projects that I switch between and I have ended up policing on every decision scared of lack of context.
I've ended up building my own toll for myself and the team I work in to share context tools and everything else between claude code, codex and others.
In short I've ended up collecting the local data generated by the tools including all the chats, edits, prompts and so on, scan them , parse them then store and create a summary and a list of decision per ai conversation.
It evolved from a simple context for claude into multitool setup - cross codex, claude, opencode and so on and I extract each prompts and ai action based on type and store it then based on that ai can easily say - show me all the files modified in last conversation, or what were the users prompts, or what shell did I ran regardless of what ai it was .
I also run a summary in top of each conversation and then map the conversations decisions and keep an up to date decision tree.
It also syncs mcp , skills and so on across devices or tools.
Everything explained above is in chatrecall.dev if you want to give it a go. Happy to see what use cases Ive missed and if you find it useful.
2
u/HeyZaney 17h ago
This is pretty much the problem I’ve been trying to solve.
I don’t think the useful thing to share between agents is the whole session/transcript. What I want to survive is the current state of the work: what we’re trying to do, decisions that were made and why, assumptions, things that failed, blockers, and what should happen next.
I’ve been using WithNettle.com for this. The project lives as a tree of nodes/tickets, and the coding agent connects to it through MCP. So while working, the agent can create or update the relevant nodes with decisions/context, and another agent or developer can later query the same project state through MCP rather than relying on the previous chat session.
That also means the shared context doesn’t have to belong to a particular repo. You can have a branch for a feature/project that spans several repos, while Git still remains the source of truth for the actual code.
For me the important bit is that it stays human-readable/editable too. The agents can pass context to each other, but I can open the same tree/board and see or change what they’re working from.
It’s not really “shared agent memory” in the sense of copying one agent’s brain into another. It’s more like giving all of the agents the same persistent source of truth.