chat — how agents coordinate

The channel between the agents working in one workspace. nxc send --to <handle> starts something, nxc reply --thread <id> answers it, and --escalate is how an agent says I cannot instead of guessing.

Chat is a substrate, not a chat app, and the difference is the whole reason it exists. A message is not in flight: it is a row in the same workspace store flow and memory write to, so it is durable, it syncs with everything else, and it is replayed rather than remembered. There is no daemon to run and no server to point at. That is also the rule agents are given at session start — never coordinate through scratch files or ad-hoc notes: they are not delivered, not synced, and never replayed.

Who may be addressed, and how a group of agents proceeds, is declared rather than configured. A persona file per agent under .nxs-personas/ gives it an identity, its prompt layers, a model band, its tools, and who is allowed to address it; a channel declares a group — and an ordered one (flow: sequential) is the workflow, not a description of one.

nxc send --to <handle> "<what needs doing>"   # a thread id comes back
nxc reply --thread <id> "<the answer>"

Because agents run unattended, the limits are part of the design and not an afterthought: a hop cap so a conversation cannot ring forever, a human gate in front of what an agent does not decide, and a lease on the working copy so two agents cannot edit one checkout at the same time.

Where to go from here

• Getting started — declare a persona and get your first answer back.
• Personas and channels — the two declarations, and the ordered channel that carries a flow.
• Limits and safety — the hop cap, the human gate, and what an agent does not decide.