Fusion - the Fusion 360 Bridge

AD 1.9.180 gives your bridge the CALLER, for free. No bridge change is required to receive it; reading it is opt-in but strongly encouraged, and this is becoming the standard across the AD ecosystem.

The problem it solves. A user runs ~20 AI threads against one desktop. Until now AD relayed every command indistinguishably: your bridge received NO caller identity, so it could not arbitrate concurrent agents, no log line could be attributed to the thread that caused it, and any agent's bridge_kill destroyed every other agent's work. (Filed by AdityaAngajala as adom/adom-desktop#34.)

What you now receive. AD stamps three headers on EVERY relayed request to your bridge (all four dispatch paths, including third-party):

X-Adom-Caller-Thread      the AI conversation/tab name
X-Adom-Caller-Container   the container it runs in
X-Adom-Caller-Reason      the per-call justification, when given

Trust rule, please respect it: these are SELF-ASSERTED, exactly like reason. Use them for attribution, logging, UX and arbitration hints. NEVER for authorization or as a security boundary. AD's security remains transport-based.

What we would like every bridge to do:

1. Log it. Put the thread in your per-verb log line: [verb] your_verb session=x caller="chip-fetcher tab 3". This alone makes concurrent-agent interference reconstructable after the fact.
2. Arbitrate, if you own resources an agent can hold. Record the owning thread when a session/resource is created; warn when a different thread grabs it, refuse only for destructive operations, and always name the current owner so the second agent can coordinate.
3. Label your UI. If you drive a visible window, put the owning thread in its title, taskbar tooltip or jump-list name via desktop_set_window_identity, so the USER can see which of their tabs owns which window. This is the payoff John specifically wants: a glance at the taskbar tells you which conversation owns which window.
4. Report it back. Include the owning thread in your status/list verbs so an agent can discover it is not alone.

Where it comes from: the AI exports ADOM_AI_THREAD once per session and the adom-desktop CLI attaches it to every call; a relay call with no thread is refused by AD with caller_identity_required before it ever reaches you. Loopback callers (HD, another bridge, the local CLI) are trusted by transport and exempt.

Full contract with node + python snippets and a self-audit checklist: the Bridge SDK, section "Caller provenance: WHO asked" (https://wiki.adom.inc/adom/adom-desktop-bridges). Consumer-side skill: adom-desktop-caller-identity.