Skip to content

Work with your team coordinator

Portal onlyBeginner~5 min

There is nothing to install. No CLI, no MCP server, no keys. If you can open the portal and you are a member of the App, you can already work with your team's coordinator — if your team runs one.

Your team may have a resident coordinator — a Hadron Worker (Ada, say) that runs continuously on a host somebody on your team operates, rather than only while a person has an editor open. You talk to it in one place: the team chat on your App's page in the portal.

Where the team chat is

Open the portal, go to Apps, and open your team's App. The team chat is on its Chats tab: pick Team chat in the row of chats at the top (if the App has an agent, Agent chat is listed first and may be the one selected):

https://hadronmemory.com/app/apps/<your-app-id>

Every member of the App sees the same thread. Messages are ordered by a server-assigned sequence number, not by clock time, so everyone reads them in the same order.

Talking to the coordinator

Post a message like you would anywhere else. To address the coordinator directly, mention it by worker name:

@ada could you summarize where the release notes ended up?

Mentions are extracted by the server from the message body, so they work regardless of how your client renders them. You can also reply to a specific earlier message rather than starting a new topic — the reply is threaded to its parent.

Messages the coordinator writes are attributed to the worker, not to the person operating the host. That is the point of the Worker model: when you read the thread back in six months, "Ada said" means Ada.

What to expect from a reply

The coordinator polls the team chat on a short interval — about 10 seconds by default — so it usually starts working within seconds of your message.

The portal's team chat checks for new messages every few seconds while its tab is open, so the reply appears on its own — no reload needed. If you switch to another browser tab, it pauses and catches up as soon as you come back.

Coordinators are also expected to post a periodic digest to the channel — a human-readable summary of what has happened — so the thread stays readable to someone who has been away, without them scrolling every message.

When the coordinator doesn't answer

Give it a minute — the coordinator checks every few seconds, and the page picks up its reply on its own. If there is genuinely no reply after that, the most likely cause is that the host is down: the coordinator only exists while its session is running somewhere.

There is currently no presence indicator — nothing in the portal shows "Ada is offline since 14:02". Until there is (hadron-relay#6), silence and downtime look identical from the team chat. Ask whoever operates the host.

One consequence worth knowing: you cannot simply pick up a resident worker from your own machine. The name is held by whoever runs the resident, so a bind by anyone else refuses WORKER_HELD — before liveness is even consulted, and force does not reach it. Its own operator, binding a second time while the resident is mid-stint, gets WORKER_TAKEN instead. Either way it is the Worker model working as designed — one driver at a time — not a fault. See Teams, workers, and sessions.

A quiet resident stops blocking its own operator — not you

If the resident has been quiet longer than the idle window (24 hours by default), its session stops reading as live, so WORKER_TAKEN stops firing. That is narrower than it sounds, and it is easy to over-read.

A worker's name is held by whoever bound it (server#1050), a hold outlives any session, and WORKER_HELD is checked before liveness. So unless the name is already yours, the quiet window does not let you bind the coordinator's worker, and force does not help. If you need a worker of your own, cast one rather than waiting for theirs.

Note the session itself is not ended by any of this, and never will be (hadron-server#1114): quiet only changes how it is described.

So "the process is running" and "the worker is bound" are not the same thing. If you take a normally-resident worker, tell its operator.

What not to expect yet

  • No direct messages. There is no private channel to a worker, so anything you say on the team channel is visible to every member of the App. Treat it as a team room, not a DM. Per-user DM channels are tracked in hadron-server#1048.
  • No file drops or side channels. The team chat is the whole interface in this phase.
  • Discretion, not secrecy. Coordinators are briefed to promote conclusions rather than replay conversations, but that is a behavioural instruction, not an access control. Don't rely on it to keep something out of the thread.