AI agents in collaborative coding sessions: The OCT Agent

Nowadays, we see AI agents integrated everywhere. They help doctors analyze medical data, assist customer service teams in drafting responses, and optimize logistics routes in real time. And of course, software development is no exception — coding agents have become a natural part of many developers’ workflows, helping write, refactor, and review code.

At TypeFox, building custom AI agents for domain-specific use cases is actually part of what we do. Under our Domain AI umbrella, we help teams integrate AI deeply into their existing tools and workflows — including building bespoke agents tailored to their domain.

Working together across machines and IDEs is something we’ve been exploring for a while, too. If you’re interested in the foundations, check out our earlier posts on Eclipse Open Collaboration Tools — the open-source framework that makes cross-platform real-time collaboration possible, across VS Code, Eclipse Theia, IntelliJ, and custom web apps.

Now, we started thinking about how coding agents could also work inside a collaborative session. The questions we wanted to explore were: what happens when you bring a coding agent into a collaborative coding session? How does it behave as a participant? How does it feel for the humans in the session? And what technical challenges come up along the way?

We started experimenting and created a first simple proof of concept.

The idea: an agent as a session participant

The idea behind the OCT Agent is straightforward: it joins an OCT session like any human participant. It can receive messages from everyone in the session, read files, and propose changes to those files.

Of course, one could simply run a coding agent locally without connecting it to an OCT session at all. In that case, the developer who started the agent sends a request, the agent makes changes, the developer reviews and approves them — and only then do the other participants in the session see anything. Without OCT, if the agent runs locally for just one person, only that person sees what’s happening; everyone else is excluded from the process until the result lands in the shared codebase.

The OCT Agent is part of a shared session: The key advantage of integrating this into OCT is the collaboration dimension: it adds transparency and shared decision-making. Everyone can make requests to the agent, see its responses, and discuss the proposed changes as a team before they get accepted.

From a technical standpoint, there is no difference for the Open Collaboration Protocol. The agent uses exactly the same protocol messages as all other client implementations. The protocol is, you could say, client-agnostic.

Not an agent — a bridge to ACP

What we built is a bridge that connects third-party coding agents to an OCT session. We didn’t want to reinvent the wheel by implementing a dedicated agent — instead we integrate any ACP-compatible coding agent.

To do that, we leverage the Agent Client Protocol (ACP). Before landing on ACP, we experimented with the Model Context Protocol (MCP). However, MCP is designed primarily for context enrichment — providing models with additional data sources and tools. It’s also a unidirectional communication channel, and for our use case we needed true bidirectional communication between the OCT session and the coding agent.

ACP is an open protocol developed by Zed. It standardizes bidirectional communication between editors and coding agents using JSON-RPC over standard I/O — similar in spirit to what LSP did for language servers. The OCT Agent works with any agent that implements ACP. There is a growing list of compatible agents — among the most widely used are proprietary CLIs such as Claude Code and Codex CLI, and open-source options such as Goose and OpenCode.

The architecture looks roughly like this:

OCT Session  ←→  OCT Agent (Bridge)  ←→  ACP Agent (e.g. Claude Code)

The OCT Agent — the bridge in the middle — takes on several responsibilities:

• Establishing and authenticating a connection to the OCT session
• Spawning the coding agent in a separate process
• Setting up the ACP session with the coding agent
• Listening for document changes and chat messages in the session and forwarding them to the agent
• Relaying the agent’s responses and proposed changes back into the session

The coding agent itself runs on one of the peers’ machines — and this is precisely what determines how the agent gets access to the workspace context.

Workspace context: two cases

Case 1: Agent runs on the host’s machine. This is the simpler and more robust case. The agent has direct filesystem access, so providing workspace context is not a problem at all. This is the starting point for our experiments, and it works well out of the box with all ACP-compatible agents.

Case 2: Agent runs on another peer’s machine. OCT supports requesting file contents via the protocol, but since the peer only knows the virtual file tree and not the actual contents of all files, you would have to request them one by one. Efficiently providing the agent with the full workspace context in this scenario — without either over-fetching or needing to keep a local copy continuously in sync — is an open challenge that we’re looking forward to tackling with the community.

Talking to the agent: chat

To interact with the agent, we also built a feature that is now already merged into OCT: a simple chat. We enhanced the Open Collaboration Protocol with chat messaging, making it straightforward to implement chat panels wherever needed — in the VS Code extension and in the OCT Playground.

Initially, we were writing prompts directly as comments in the code, preceded by an @ sign and the agent’s name — convenient enough to get started, but not ideal. The chat is a much better interaction channel. All participants share the same channel, so everyone can talk to each other and to the agent. The @name addressing pattern carries over naturally into chat as well. And writing prompts as code comments remains possible, of course.

Displaying agent output

When it comes to displaying the agent’s output, we initially experimented with a live cursor approach — the agent would set a cursor in the shared editor and type changes in real time, creating the feeling of a real participant working alongside you.

However, this turned out to be very challenging in practice. The agent returns complete file contents rather than targeted edits, which makes calculating the correct cursor positions non-trivial. And beyond the technical difficulties: nobody wants unreviewed agent changes landing directly in a shared session. We opted for the diff view instead.

The diff view has a significant advantage that actually aligns well with the collaborative spirit of OCT: all participants can see the proposed changes, discuss them, and decide together whether to accept or reject them before anything touches the shared codebase. The mechanism to open the diff view on every peer is also part of the Open Collaboration Protocol — making it peer-agnostic. Any client implementation, not just the agent, could broadcast a message to open a diff view, which opens up interesting possibilities for future enhancements.

What a session looks like

When the agent is started via a built-in command in the VS Code extension, it goes through the same login procedure as any other participant — it gets a name, requests to join, and appears in the list of users just like a human peer. Once it’s in the session, participants can send it requests via chat. After a moment, the agent responds with an explanation in natural language and, if code changes were requested, opens a diff view that everyone in the session can see and act on.

What’s next

The OCT Agent is in an early state: a proof of concept we are evolving with the community. Agent support is not a curated pick-list — any third-party agent that implements ACP can be wired in via the bridge. Open questions we’re actively exploring include: how to provide full workspace context when the agent runs on a remote peer’s machine, and which UX patterns make collaborative pair programming with AI feel natural for the whole session.

We believe open protocols like OCT and ACP are the right foundation: no vendor lock-in, no proprietary silos, but an ecosystem where editors and agents can be freely combined. The code is available on GitHub and we’d love to hear feedback, ideas, and contributions from the community.