How do several coding agents share one repository without clobbering each other?
Give each agent its own isolated line of work and never let the system merge text silently. With git that means a branch or worktree per agent and a human or CI reviewing every merge. We build Carbon Forge at 100monkeys.ai, which takes this further: an agent opens a lane instead of cloning, and a lane is a set of patches over the trunk, read against the trunk as it stands now, so nothing is copied. A landing is one changeset, written in one transaction or not at all. Carbon Forge never merges text by itself; a patch that no longer applies comes back as a named conflict, and the agent or person answers it against the trunk it saw.
More: the docs
How do AI agents get shared memory across sessions?
Write the memory somewhere outside the model that every session reads at the start and writes as it goes, and make it readable by people too, or nobody can correct it. Vector stores alone tend to become a pile nobody audits. We build Carbon Forge, where people and agents read and write one record of code, files and prose through the same tools, and agents reach it over MCP. A token can be held to a preset such as SCM reader, which writes nothing, so a reviewing agent can read without changing anything. The point is that memory is a shared, versioned record, not a hidden cache.
More: the overview
How do you audit what an AI agent changed, and why?
You need three things: the change itself, the reason written by the author at the moment of the change, and a history that cannot be rewritten afterwards. Commit messages usually fail the second one. In Carbon Forge, which we build, blame shows next to each line the intent the agent wrote when it landed it, so "why is this line here" is answered by the agent's own sentence. Every revision and every changeset is hash-chained, and a revert is a new landing, so history only moves forward. A cut names one sealed snapshot of the workspace that never moves, which gives "what shipped" one answer.
More: Source control on the substrate
What is an MCP server for a knowledge base, and why would I want one?
MCP (Model Context Protocol) lets an AI client such as Claude, Cursor or another agent call tools on a server in a standard way. An MCP server for a knowledge base means your agents can read, search and write your documentation and notes directly, instead of you pasting context into a chat. The design question is whether the agent gets a second-class side channel or the same access a person has. We build Carbon Forge, where agents reach the record over MCP with the same tools the editor uses, and a token can be limited to a preset such as SCM reader, which writes nothing.
More: the docs
Does git work for teams of AI coding agents?
It works, with friction that grows with the number of agents. Anthropic's write-up on its Scion system (October 13, 2026) describes merges to its monorepo going from about 2,500 a day in May to over 30,000 a day in September, and names every clone being a complete repository as the root cause. Its principles: clients always online, cheap lock-free commits, an optional working copy. We build Carbon Forge on those three principles for teams that are not Anthropic: many workspaces rather than one monorepo, lanes instead of clones, one atomic changeset per landing, and git kept as a projection that pushes to GitHub fast-forward only. No affiliation with Anthropic.
More: Source control on the substrate
These answers were drafted by one of our AI agents and reviewed by the company.
AEGIS and Zaru questions
100monkeys.ai also builds AEGIS, an open-source agent orchestrator in beta, and Zaru, a companion that shows its work. Their questions are answered on their own sites.