How the idea started
Coding agents changed what one developer can start in an afternoon. Running several at once is now ordinary: one fixes a bug, another writes tests, a third tries a refactor. Each is fast on its own. The trouble starts when their work has to come back together—into one codebase, one database, one release and one person’s understanding of the system.
That gap kept showing up in talks, in issue trackers and in the tools people built to work around it. Different teams were inventing locks, queues, sandboxes and shared memories for what looked like the same underlying problem. Concurrent Delivery is our name for that problem, and this site is where we collect what people are learning about it.
From Continuous Delivery to Concurrent Delivery
Continuous Delivery made the path to production one reliable, repeatable pipeline: small batches, every change verified, integrate often, release when the business is ready. Those ideas still hold. What changes is the shape of the work going through the pipeline.
Continuous Delivery assumed a mostly sequential flow of changes, written at human speed and reviewed by people who knew the context. With agents, many changes are in flight at once, produced faster than anyone can read them, often by workers that don’t know what the others are doing. The pipeline becomes the place where all that parallel work meets.
So the questions move upstream and sideways:
- What can safely run at the same time, and what has to wait?
- Where do the boundaries between agents’ work belong: files, services or data?
- How do parallel changes get combined, tested and shipped without one queue becoming the bottleneck?
- Who decides, and on what evidence, when no person wrote the change?
Concurrent Delivery keeps the discipline of Continuous Delivery and asks what it has to become when delivery is concurrent by default.
Agents with agents, agents with humans
There are two coordination problems here, and they pull on each other.
Agents with agents. Concurrent agents share a codebase, environments and data. They need ways to avoid undoing each other’s work—isolation, ownership, locks, contracts—and a way to bring their results back together. This is where most of today’s tools sit.
Agents with humans. People still set direction, decide what matters and answer for what ships. As agents do more of the work, people spend more of their time delegating, reviewing and deciding, and their attention becomes the scarce resource. Review capacity, oversight and remembering why a decision was made turn into delivery problems.
The research follows three relationships, agents with agents, agents with people and people with people, each through the steps where it breaks. Between agents those are the six delivery tensions: planning, isolation, coordination, integration, verification and memory, and the homepage opens each onto what practitioners say.
How this research works
This is independent research, not a product. We collect evidence—tools, talks, articles and what practitioners report—and look for the approaches that recur across them. Field notes work through what that evidence suggests, with their sources and the strongest counterpoint we can find.
The aim is to be clear about the problem and honest about the answers. There are no rankings or endorsements here, and open questions stay open until the evidence closes them. If you’ve seen something worth sharing, send it.
To reach us directly, write to hello@concurrent.cd.