I’ve been spending time on multi-agent workflows lately, and I keep coming back to the same question:
once multiple agents or tool calls can mutate the same file / DB row / shared state, what is the expected safety model?
The failure mode I’m seeing is pretty mundane, but nasty:
agent A reads shared state
agent B reads the same shared state
both make reasonable updates
one write lands after the other
the final state is syntactically fine, but part of the work is gone
For example, I’ve seen this when two agents are editing the same repo or updating the same task list. Both changes look valid, but one silently wipes part of the other.
So this doesn’t really feel like “the model got confused.” It looks like a plain read-modify-write race.
And I don’t think this stays an edge case for long. The moment multiple agents intentionally collaborate on the same resource, this pattern seems unavoidable.
My current view is that orchestration frameworks help with sequencing, but don’t guarantee correctness once multiple workers can mutate the same resource.
I’ve been working on an early project called Klock around this exact problem, so take that with the right bias. The thing we’re testing is a coordination layer around shared mutable resources so conflicting writes don’t silently overwrite each other. Still early, not posting this as a polished launch. I’m mostly trying to sanity-check the problem first.
A few concrete questions for people here:
Are you seeing this in real multi-agent setups, or mostly in demos?
When you do see it, how are you handling it today?
Do you treat it as an application concern, or do you think the ecosystem should have a standard safety pattern for it?
If useful, I can share a tiny repro that shows two workers silently stepping on each other’s updates, and the same flow with coordination added.
Hello! This class of problems is why State exists in LangGraph - updates are done by returning from a node, and parallelism is handled via a reducer. The underlying executor prevents data races in that way.
If you’re trying to mutate an untracked object, modify an external db, etc., then you’ll have to rely on that external untracked object’s concurrency mechanism (transactions, etc.).
A common pattern at the agent level if you’re going that way is to track the last read time and only commit the write if the agent has read from the particular file/object since the last edit. Depending on your object type, other collaboration primitives exist, of course. For instance, crdts are useful for making a collaborative doc, but they really only guarantee that the different agents have a consistent view of the world rather than ensuring that that is “correct”.
Would love to hear more about what you’re doing, however. We’ve debated adding some more advanced channel types/APIs that would allow other update pattern in the past.
State + reducer makes sense to me for handling concurrency inside the graph.
The cases I keep running into are just outside that though, like two agents editing the same repo, writing to the same table/queue, or touching the same shared file where the resource itself isn’t really part of the graph state.
In those situations it feels like you end up back at whatever the underlying system gives you (transactions, version checks, etc.), or you rebuild some form of that logic at the app layer.
That’s the part I’ve been exploring with klock, not really how to merge state inside the graph, but what the safety model looks like once multiple agents can mutate the same external resource.
Interesting that you’ve thought about more advanced channel types here. Curious how you think about that boundary, should this stay outside LangGraph, or something the ecosystem might eventually handle more directly?