How do you connect multiple AI assistants so they work on the same thing?

Claude, ChatGPT and a local model can’t talk to each other or read each other’s memory. The practical way to connect them isn’t to pass answers from one to the next, but to have all of them read and write in the same place, each with a clear role and a few shared rules. This guide is about that split; if what you need is to pick up where a single AI left off, see How to continue AI work in a new session.

Why your AIs don’t talk to each other

Here’s an example. You use ChatGPT to think things through and plan, Claude to write the code, and a local model to review documents you’d rather keep on your own machine. Each is good at its job, and each works in its own conversation.

On Monday, talking to ChatGPT, you rule out a library because its license doesn’t allow you to ship it in your product. On Wednesday Claude, which never heard about that, suggests it as the cleanest fix and wires it in. On Friday the local model reviews a client contract and flags nothing, because nobody told it which libraries the project uses. Three AIs, three different versions of the same project.

In the middle is you, acting as the cable: copying a summary from one chat to another, pasting in the key decision, explaining the background yet again. It works as long as you remember to do it, and something gets lost at every hop. The reason behind a decision is the first thing to go, because it rarely fits in a summary.

Three ways to connect them

Anyone who works with several AIs ends up trying one of these:

1. You as the go-between. Copy and paste between chats. Fine for a one-off, but it depends on your memory and patience, and each AI only sees what you chose to hand over.
2. Chaining them. A script or automation that feeds one AI’s answer into the next one’s prompt. It removes the manual work and suits a fixed process (one drafts, another reviews), but context tends to travel hop by hop: each AI gets what the script passes along, not the full history.
3. A shared place. They all read and write in the same spot. None of them depends on what the previous one remembered to pass along, and adding another AI changes nothing for the rest.

When work runs for weeks, switches AIs or passes between people, the third holds up best: the other two connect conversations, this one connects the work. What to keep in that shared place (what’s left, what happened and how things work) is covered in the guide on handoffs between sessions; here the point is what changes when several AIs work at once. And don’t put passwords or keys there in plain text: if an AI needs to use one, there are ways for it to do so without seeing it.

A special case: two AIs reviewing each other

So far the AIs don’t converse; they just share the place. There’s one case where you do want them to talk: an important solution that deserves an independent second opinion, or a task that has been stuck for days. One AI proposes a solution, another reviews it without seeing the first one’s conversation and replies by accepting it or with a complete solution of its own, taking turns until they agree or close without agreement. That’s what md-doc’s VS mode does.

Ground rules for several AIs on one project

A shared place isn’t enough if each AI uses it differently. A few rules, stated at the start of each conversation or saved as project instructions, make the difference:

• Read before acting. The first thing each AI does is read the task, the project notes and the latest history. If what it reads doesn’t match what you’re asking, it should say so before touching anything.
• Write things down when each piece is done, not at the end of the day. Whatever stayed in the chat doesn’t exist for the others.
• One place for each thing. One version of the plan and of each decision. Three copies that contradict each other are worse than none.
• Every AI signs what it writes. Knowing that a review came from a small local model, or that a change was made by an unsupervised agent, helps you decide how far to trust it.
• No AI signs off on another’s work without checking it. A task finished by an AI moves to “testing” until someone, person or AI, confirms it works.
• Split by role, not by conversation. “ChatGPT plans, Claude builds, the local model reviews” is easier to sustain than “I discussed this with one and that with another”.

None of this depends on a particular tool: it’s a habit. What matters is that the shared place is reachable by all of your AIs, not just one.

A day with three AIs

This is how it looks in practice, with prompts you can adapt.

In the morning, to the AI that plans:

Read the note “Project X: decisions” and the open tasks. Propose this week’s plan and create one task per step, saying what needs doing and how it will be checked. If you decide anything new, add it to the note with the reason.

Then, to the one that builds:

Find the open tasks for project X and take the highest-priority one. Before you start, read the decisions note and the latest lines of the history. Mark it in progress. When you’re done, move it to testing and add a line to the history with what you did and anything you couldn’t solve.

Finally, to the one that reviews:

Read the tasks that are in testing and what the history says about each. Review the change and leave your conclusion on the task. Don’t mark it as done: that’s my call.

None of the three needed you to paste anything. Each one found what the previous one left behind.

How md-doc does it

md-doc is that shared place, with an MCP server all your AIs connect to. You can do all of the above with other tools as long as all your AIs can reach them; md-doc makes it easier, not mandatory. What matters when there are several of them:

• One server for all of them. All your AIs connect to the same MCP address: Claude, ChatGPT and local models running on Ollama with Goose.
• One key per AI. In Settings you can create an MCP-type API key for each one, with its own name. Every line in a log records which key wrote it plus the model and tool the AI declared, and the AI can only append lines: it can’t edit or delete earlier ones.
• Linked tasks, notes and logs. Issues with their status, notes with the project’s current state and logs with its history are what each AI reads and writes to.
• Secrets kept out of the chat. The MCP key gives no access to environment values: an AI with terminal access uses them through the mddoc CLI, which injects the values into the command and masks the output.

If someone else works on the project with their own AI, you can share your note, issue, log and recurring-task folders with them once they accept your friend invitation.

Each one at what it does best

Each AI will keep working in its own chat, and that’s fine: each is good at something different. What shouldn’t be scattered across chats is the project. With a shared place and a role for each one, it doesn’t matter which one you talk to today: they’re all working on the same thing.