Cross desk referral

Cross-desk referral

Every other mechanism here stops at the edge of one conversation. A referral is the one that does not.

The problem it exists for

An agent on the payments desk needs a fact only the platform desk holds. It can mention the platform engineer — but mention_dispatch binds the child turn to the conversation the mention was written in, so that pulls the engineer into payments, away from the transcript that holds the fact and the members who could corroborate it. There is no way to ask a channel a question and get an answer back, which is the ordinary way an organisation of more than one team solves anything.

This is not only ergonomics. A desk is a correlation boundary. Members of one desk read the same transcript, work the same part of the system, and are wrong about the same things. Their errors are correlated, and averaging correlated error does not remove it — so no amount of deliberating inside a channel cancels a mistake every member of it shares. Pooling across channels is the only operation that can.

The benchmark puts a number on it. Three desks, each confidently wrong about a different option: deliberating inside the channels scores 0.2%, and crossing between them scores 77.5%.

What a referral is

referral(policy, input, roster, desks) -> ReferralDecision is a pure fold in tinyhivemind-core, sitting beside mention_dispatch rather than replacing it. It answers one question: does this committed reply owe exactly one turn to somebody, and which conversation does that turn run in?

trigger	conversation of the child turn
an agent on this desk	this conversation, thread root preserved
an agent not on this desk	that agent's home desk, desk channel
@#desk	that desk, run by its one responder, desk channel
a reply under a crossing referral	back to the conversation that asked

A referral that crosses always lands on the target desk's channel, never in a thread. A thread root is a sequence number in the conversation that owns it, so carrying one across would name a message that does not exist.

Still one message, one turn

A desk mention reads like fan-out and is not. @#platform resolves to exactly one agent — that desk's first effective active member other than the author — before the decision leaves the fold. There is no variant of ReferralDecision carrying two, the same way there is none of MentionDispatchDecision or HiveStep.

direct_responder is untouched, so a desk mention still cannot start a turn through the ordinary responder ladder. Referral is a separate, opt-in edge.

The answer comes back

A crossing forward carries a ReferralOrigin — the conversation that asked and who asked. When the host runs that child turn, it passes the origin back in the next ReferralInput. A reply committed with an origin, carrying no mention of its own, yields exactly one ReferralKind::Return: one turn, addressed to the asker, on the conversation that asked.

A return carries no origin of its own, so a round trip is two hops and cannot ring.

A forward that does not cross carries no origin either — the answer is already visible to the asker, because it was appended to the conversation the asker is reading.

Information crosses, votes do not

The library takes no position on what a referral says, and the benchmark's members deposit !evidence, which adds no supporter to any topic. The far desk hears another channel's reading of the options, its members average it into their own, and they still have to spend their own turns before anything is counted.

Letting a supporter on one desk count on another would be the cheap way to make a federation converge. It would also not be pooling information — it would be voting twice.

Turning it on

Every knob is off in ReferralPolicy::DEFAULT.

ReferralPolicy {
    enabled: true,
    max_hops: 2,                     // one round trip
    reach: ReferralReach::Desks,     // Local | Channels | Desks
    returns: true,
}

With only enabled and max_hops set — reach: Local, returns: false — the decision is exactly the one mention_dispatch makes, on the same conversation. That equivalence is asserted by a test over every interesting input, not merely documented.

ReferralReach widens strictly, which is why it is one knob and not two: a desk mention only means anything once a turn is allowed to run somewhere other than here.

What a host still owes

Three things, and the library will not do any of them.

Authorize both conversations. A crossing referral writes into a channel its author is not a member of. A ReferralQueue transaction that authorizes only the source desk has authorized nothing.

Carry the origin back. When the host runs a referred turn, it must pass the ReferralOrigin into the next decision, or the answer has no way home. Nothing in the library remembers it — that would be state, and this crate holds none.

Bound the width. max_hops bounds how deep a chain goes. Nothing bounds how many channels one desk may ask, because only the host knows what a question costs it. The benchmark's host caps it at one question per peer desk.

When not to turn it on

When your desks do not have blind spots of their own. In the benchmark at --bias 0 — desks that are individually unbiased — crossing a channel changes no answer and costs twice the turns. The mechanism is for correlated error across channels; a host without that should leave ReferralPolicy::DEFAULT alone.

Timing is load-bearing

The single largest effect measured is not in the library at all. A desk whose members share a bias reaches quorum inside its own blind opening round, so an answer arriving after that is information the desk has already voted past.

The benchmark's first version had its members ask after proposing — which sounds more natural — and every desk committed to its own decoy with the correction sitting three lines below the decision. Moving the question to before the desk has backed anything is what took it from failing to 77.5%.

That is a host policy question the library cannot decide, and it is worth knowing before you configure one.

Read next

• Benchmarks — the federated arms and what they scored.
• Mentions — the grammar a referral is read out of.
• Hive episodes — what happens inside one channel.
• Host integration — the ports, including ReferralQueue.