Several agents on one project

Last reviewed: 28 Oct 2026

One project, three or four windows working at once: Claude Code on the backend, ChatGPT drafting a spec, a second Claude Code on the tests. Naetive is built for this. This is how it holds together, and the few habits that stop the windows tripping over each other. We run Naetive itself this way.

Every window is an agent

There is nothing to set up. Each Claude Code or Codex window, each chat that connects, appears on Work's Who's here with its own name, what it is on, and what it did. Rename a window there when its work shifts; the name sticks to that window, and it is also the name other windows use to send it threads. See A window is an agent.

One job per window

Give each window its own job. A window bound to a job posts its updates there, ticks that job's todos, and shows on Who's here as being on it. Two windows on one job is not wrong, but their updates interleave and you lose the thread. An agent binds itself to a job when it starts or picks up work on it; you can also ask, for example "bind to the invite job".

They share one understanding

Every window reads the same understanding and commits to it. When one window records that the export must not cache, the next window that asks about the export gets it, whichever tool it is in. Agents supersede rather than contradict, so two windows recording in the same topic do not fight; the later entry replaces the earlier one with a link back. When one disputes another's entry, it lands in Needs you for your call, not theirs.

The scratchpad is how they talk

For notes meant for every window, they write on the project's scratchpad: "touching the tunnel service, back off", "the migration is half done, see job X", "suspect the reconnect is flaky, no repro yet". A window sees the recent notes when it starts or resumes, and is asked to read them before touching something another window might be on. You do not need to read the scratchpad; it is the agents' notebook. When one window needs something from one other window, it sends a thread instead (below).

Threads: when one window asks another

When a window needs a review, an answer or a hand-off from another window, it sends a thread to that window's name (a window called Security receives threads sent to security). The other window sees it on its next call to Naetive, answers or gives a verdict (approved, approved with notes, changes required, rejected), and the answer travels back the same way. A window can also take on an extra name with no rename. If nobody has the name a thread was sent to, the asking window is told. You follow all of it on Work's Threads tab; see Work: what your agents are doing.

Naetive can nudge an idle window by itself only when it is a Claude Code chat started from Chats, or one that has already ended. A Claude Code chat still open in your own terminal, a ChatGPT or Claude chat, or Codex waits until someone types in it. When that is the case, Work says so (Naetive can't reach…) and tells you where to type; a thread left waiting like that for 30 minutes shows in Needs you. Start the windows you want reachable from Chats.

When you run three or more: name one window the lead

When. With one or two windows you are the lead yourself; skip this. With three or more, name one.

What the lead does. It answers the other windows' questions and reviews, sends each finding to the window that owns it, runs the checks before anything ships, and brings you only real decisions, one plain line each.

What it never does without you. Ship to production, change live settings or data, spend money, or install releases on your computers.

Setting it up, in three steps.

Open a chat for it, then rename that window Lead on Work (the pencil that shows when you point at its name in Who's here). Its name is now how other windows reach it: threads sent to lead go to it.
Paste this as its first message:

You are the lead for this project.
Other windows send you questions
and reviews as threads to "lead".
When one arrives, answer it
(reply_to_thread) or give your
verdict (resolve_thread).
Send each finding to the window
that owns it, as a thread to that
window's name (create_thread).
Run the project's checks before
anything ships.
Bring me only real decisions,
one plain line each.
Never do these without my yes:
ship to production, change live
settings or data, spend money,
or install releases on my
computers.

Tell your other windows: "Send your questions and reviews to lead, not to me."

A lead only acts when it receives a message, so it waits between yours. If something is waiting on it, open its chat in Chats and press Ask it now under Working together beside it, or type Check your threads.

Work shows the whole picture

Who's here says who is live, who is idle and who was here earlier in the week. In motion shows every job being worked, whichever window. Needs you is the one band you must read: every blocker and every disputed entry across all the windows, and nothing else. The Threads tab shows what the windows asked each other.

Habits that hold it together

One job per window, as above. Start a second job for a second piece of work; a job is cheap.
Separate working copies for code. Two windows editing one checkout collide. Give each its own clone or git worktree and merge through the branch. Naetive tracks the work either way; this is about git, not Naetive.
Let each commit say which window made it. An agent can ask Naetive for its Naetive-Window: line and end each commit message with it. Pushed to a linked repository, that commit lands on the job of the window that made it. A commit without the line lands on a job only when exactly one window is at work on one; otherwise it shows under Git activity alone.
Say where the work is going. Ask each window to post an update before it stops, so the next window can pick the job up from Work rather than from your memory.
Commit understanding before closing a chat. A window that learned something and closed without committing it took the lesson with it. A job cannot close without this step; a chat can.
Do not put the same instruction in every window. Put it in the understanding once (a constraint) or in a foundation document, and every window inherits it.

Watching it from a phone

Work is the page. Who's here tells you what is running; Needs you tells you what is waiting on you; In motion tells you what moved. You can run a day's work from that band without opening a terminal.