As coding agents continue to improve, I've noticed that the hardest problems are no longer about generating code. Claude Code, Codex, Gemini CLI, Cursor, and other agents are already capable of implementing features, refactoring applications, writing tests, and navigating large repositories with very little guidance.
The real challenge begins when multiple autonomous workers need to collaborate on the same project.
Most development tooling was designed around humans. Git records history, GitHub manages collaboration, CI systems automate builds, and editors provide an interface for writing code. Those tools work extremely well because humans naturally communicate outside the system. We discuss implementation details in Slack, leave comments on pull requests, create tickets, and coordinate work through meetings.
AI agents don't have those implicit communication channels.
Every agent starts from its own context window. It doesn't know whether another worker is already implementing the same feature, whether a file is currently being modified, which decisions have already been made, or what work remains after another agent terminates unexpectedly. As more autonomous workers participate in software development, coordination becomes a systems problem rather than a prompting problem.
That observation led me to build ACP.
Unlike existing agent protocols that focus on communication between clients and models or interoperability between agents, ACP focuses on something different: shared operational state inside a software project. The goal is to provide a durable coordination layer that allows autonomous workers to safely collaborate on the same repository.
Instead of treating conversations as the source of truth, ACP models the state of collaborative software engineering itself.
A workspace becomes the boundary where work happens. Workers represent autonomous actors, whether they're AI agents, humans, CI pipelines, or automation. Work is represented through explicit work units with predictable lifecycle transitions instead of loosely defined tasks. Shared resources can be coordinated using advisory leases, allowing workers to understand ownership without relying on operating-system locks. Long-running execution can be resumed through checkpoints, while durable memory records preserve the information another worker actually needs to continue the job. Reviews, artifacts, and event history complete the lifecycle so every important action becomes part of the operational history of the workspace.
One design decision that significantly influenced ACP is the idea that coordination should be event-driven.
Rather than simply mutating database records, important operations generate immutable events describing what happened. A worker claims a work unit. A lease is acquired. Progress is checkpointed. A review is requested. An artifact is attached. Work is approved and eventually completed.
This event history becomes far more valuable than a chat transcript because it allows any worker to reconstruct the current state of the workspace without needing access to the original conversation. If an agent crashes, a CI job restarts, or another model takes over the task, recovery is based on durable state rather than reconstructed prompts.
Another important architectural goal was separating coordination semantics from infrastructure.
Whether clients communicate through REST, JSON-RPC, Server-Sent Events, or native Effect RPC should not change the underlying behavior of the platform. Likewise, whether persistence is backed by in-memory storage during development, SQLite on a workstation, or PostgreSQL in production should not affect how work units, leases, checkpoints, or reviews behave. Infrastructure can evolve independently while the coordination model remains consistent.
The implementation reflects that philosophy throughout the repository.
ACP is built with TypeScript and the Effect ecosystem, using Effect's dependency graph, typed errors, schema validation, configuration system, and runtime abstractions to keep each subsystem isolated and composable. The project separates protocol definitions, domain logic, infrastructure adapters, transports, storage implementations, and application entry points into independent layers, making it possible to evolve individual components without affecting the rest of the platform.
One aspect I'm particularly happy with is that ACP is not tied to a single execution environment. The same coordination model can support local repositories, Git worktrees, development containers, cloud sandboxes, or CI pipelines. Workers don't need to know where they're running—they only need to understand the shared coordination state exposed by the platform.
ACP is intentionally not another AI framework.
It doesn't generate code.
It doesn't orchestrate prompts.
It doesn't replace Git.
It doesn't compete with MCP or other agent communication protocols.
Instead, ACP sits one layer below autonomous software engineering, providing the durable operational primitives that allow independent workers to collaborate safely over long-running tasks.
Building ACP has reinforced something I've been thinking about for a while.
The first generation of AI developer tools focused on making individual developers more productive. The next generation will focus on enabling entire teams of autonomous workers to collaborate effectively. Once that happens, the difficult engineering problems won't be language models—they'll be ownership, recovery, synchronization, review workflows, auditability, and distributed coordination.
That's the problem ACP is exploring.
The project is still evolving, and many ideas will undoubtedly change over time. But I believe the underlying premise is sound: autonomous software engineering needs the same kind of operational infrastructure that distributed systems required years ago. As agents become more capable, coordination becomes infrastructure—not an implementation detail.
If you'd like to explore the architecture or contribute ideas, the repository is open source:
Top comments (0)