The number of AI agents running inside a company is increasing by multiple orders of magnitude. These agents need the same, live understanding of the company, its processes, and the status of projects and tasks. They need to work together and collaborate.
This already fails today, characterized by LLM responses such as “Whoops, it seems like a different agent already did the same changes before I did!”.
At Qontext, we are building a self-maintaining context repository. It gives a company’s agents a shared source of truth they can use and improve together. This means that every agent in a business reads from our context repository, and writes back to it. The impact:
Qontext is especially prone to concurrency issues: the writes of every agent in a company land in the same place.
When we solve concurrency at Qontext, we do not solve it only for us, but for every agent that uses Qontext.
What goes wrong when agents act concurrently
Concurrency problems at this scale fall into three groups.
Lost updates. Agent A and agent B both read /customers/acme.md. Agent A adds a new contact. Agent B updates the deal stage and writes back the full file, based on the version it read. The new contact is gone. Neither agent notices.
Partial changes. An agent moves a customer from “trial” to “active”. This touches five files: the customer file, the pipeline overview, two project files, and the account owner’s notes. The third write fails. Two files say “active”, three say “trial”. Every agent that reads them now gets a different answer.
Unchecked changes to key context. In one sales call, a prospect exaggerates a competitor’s discount. An agent takes the claim as fact and rewrites the pricing policy. Nobody checks the change. From now on, every agent that quotes a price follows the wrong policy.
The first two are classic database problems. The third also happens with people, but it becomes significantly more frequent and harder to control as agents outnumber people in a company.
Why existing tools break
Today, companies give agents context in two ways: as .md files in GitHub repositories, or through the tools their teams already use, such as Notion.
The engineering angle: GitHub
Git was designed for people who work offline and merge a few times per day. Agents are always online and write many small changes. At that scale, Git shows its limits:
One copy of the repository per agent. Git lets only one process change a working copy at a time. Agents that share one copy fail on each other’s lock, so each agent needs its own worktree.
Every push races every other push. Git refuses a push when main has moved, even when the other agent changed a different file. The agent must fetch, rebase, and push again. The more agents, the more pushes fail. On a real conflict, the agent must resolve it alone.
History grows with every small edit. Clones and fetches become slow.
Review is all or nothing. Either every change waits for a pull request review, or agents push to main unchecked.
Read access is all or nothing. Whoever can clone the repository can read every file.
Anthropic hit these limits with its own code and built a new system instead of Git.
The business angle: Notion
Through Notion’s MCP server, agents read and write the same pages as the business team. Each write applies immediately, to one page, with no check against the version the agent read. One agent can overwrite another agent’s change from seconds before, and neither notices. Agents also cannot group writes: if an update to five pages fails on the third, the context is half old, half new.
Verification does not protect key pages. It is only a label: agents can still change a verified page, and can verify pages themselves.
The same applies to Linear, HubSpot and most other tools agents reach through an MCP server.
How Qontext handles concurrent changes
We designed our context repositories from scratch with scale in mind. The core idea: treat every write like a database transaction, not like a file save.
Three building blocks carry the design:
Per-file versions. Every file has its own version history. When an agent reads a file, it gets the file’s current version id. When it writes, it sends that id back. This tells Qontext which version the change is based on.
Grouped changes. A change groups the updates to one or more files. It lands completely or not at all. Changes and their outcomes are append-only: we never rewrite history.
Central, ordered changes. Qontext applies changes centrally and in order, so a file is never held while an agent is still reasoning.
The next three sections explain the design decisions behind this.
Allowing many small changes to coexist
Agents make many small changes, often at the same time. In Qontext, agents never wait for each other’s changes.
First, versions are per file. Qontext checks a change only against the files it touches. A change to /customers/acme.md never causes a change to /customers/globex.md to fail. A change that touches both files is checked as a whole, and lands on both or neither. No change is refused because an unrelated file changed, so agents never fetch, rebase, and retry.
Second, a write returns immediately. Qontext accepts the change, queues it, and returns a receipt. The agent does not wait for the change to land, and it does not retry. It does not have to wait for one change to land before making the next. Qontext keeps a sequence of related changes consistent with one another.
The trade-off: a receipt means “accepted”, not “done”. A pending change can still be held for review or rejected.
Per-file history grows with every change. Qontext keeps years of history fast to read without slowing access to current versions.
Automatically reconciling concurrent edits
Many concurrent changes do not really conflict. Qontext tries to resolve as much as possible automatically, and only escalates in the worst case. For each change, Qontext takes the first step that works:
Fast-forward. Nobody changed the file since the agent read it. The change lands as is.
Three-way merge. Somebody did change the file. Qontext compares three versions: the one the agent read, the current one, and the agent’s proposal. If the two changes touch different lines, both are kept. Two agents can add facts to different sections of the same customer file, and both facts survive.
Escalation. The two changes touch the same lines. The change waits in Change reviews. A person sees it next to the current file and decides. Nothing is lost, and nothing is overwritten.
Git uses the same three-way merge. The difference is where it runs, and who deals with a conflict. In Git, each agent merges on its own copy, and a conflict stops the agent until it resolves the conflict itself. In Qontext, the merge runs on the server. The agent never sees it, and a real conflict goes to a person, not back to the agent.
Not every case needs a merge. A rename by one agent and a content edit by another both apply, without a conflict.
We are continuing to reduce how often a person needs to step in.
Reviewing only what matters
Running Qontext with customers taught us that not all changes are equal. Most changes record the status quo, such as a deal that moved to the next stage or a ticket that was closed. They happen constantly and must move through without a person. Few changes alter how agents work, such as the sales process or the pricing policy. One wrong change there affects every agent that reads the file.
Code has tests that catch a bad change after the merge. Company context has no such tests, so a wrong fact spreads quietly to every agent that reads it. That is why Qontext checks a change before it lands, not after.
Qontext allows users to protect files and folders. A change to a protected file always requires a human review, even if it does not conflict with other changes. Later changes to the same file wait behind it.
The result: /customers changes at agent speed. /sales-process changes only after a person agrees.
What we did not build
Before we built our own design, we looked at simpler options. Each one fails on one of the problems above.
Git as the storage layer. All agents write to one branch, and every push must build on its latest state. Writes to unrelated files still collide and retry. History lives in packfiles that grow with every small edit.
Locks. An agent locks a file, reasons, writes, and unlocks. But an agent can reason for minutes, and every other agent waits that long. In Qontext, a file is never held while an agent is still reasoning.
Last write wins. The simplest option, and the one most tools use. It loses updates by design.
Review for everything. Safe, but it does not scale. A person who reviews hundreds of changes per day stops reading them.
Outlook
Today, people write most of a company’s context, and agents read it. This is changing fast. Soon, agents will write most of it, and every new agent adds a writer, not only a reader. The context layer must then work like a database: every write is checked, nothing gets lost, and people step in only where they matter.
We would love to show you how Qontext handles this for your agents: book a demo.
Or, if you want to build Qontext with us, we are hiring.