An agent can choose the correct tab internally while leaving a person unsure why it is the target. Multiple accounts and reference tabs make that uncertainty more consequential. Northstar separates destination, account and reference in visible context that can be read before execution.
Separate preview time from recorded execution time
Before execution, TaskContext uses planTaskTabs to preview routing from the current goal, tabs, workspace and accounts. While running, saved routing takes precedence when present; record mode also reads stored context. A newly calculated preview must not impersonate the historical target.
Otherwise a person changing tabs after execution could think the earlier job used that new tab. Preview and record may share a card shape while reading different data. Retain what was selected then and separately show what would be chosen now. The interface needs that temporal distinction as well as the destination name.
Give destination and references different places
The destination gets its own row. References are summarized by count and first tab inside details, with an explicit none state. Additional destinations receive another note. Many readable tabs should not all resemble write targets.
A tab button checks whether its ID still exists and disables when absent. Clicking a historical record should not invent a new same-title tab. An address in a button title also does not grant execution ownership; host contracts do that separately. Explaining the target and authorizing its manipulation are different responsibilities even when shown in one compact card.
Selection is not proof of authentication
The account row shows accountLabel and accountStatus together. Historical workbench guidance says a check means current selection; login confirmation requires an observed site header. A saved name alone and a login-required screen remain different states.
AccountStatus reads the selected tab's profile and the corresponding platform status, with separate unassigned-empty and private states. A logo or saved name cannot establish server authentication. A readable account display needs evidence-aware wording more than an attractive label. Actual identities remain outside the public maker account and synthetic examples.
Make ambiguity an inspectable result
When routing.reason is ambiguous, the destination becomes Needs confirmation with its note. Emphasizing a plausible account as though chosen can make an unresolved decision look settled. The visual treatment should preserve the unresolved fact.
This card does not solve every routing error. Incorrect current material, stale tabs and changing site accounts require execution-boundary checks. Preview reduces confusion while the host validates ownership. Visible context is a convenience, not a replacement for verification. Retaining that limit helps a confirmation-needed label lead to the right next action.
Retain context that another conversation can continue reading
Advanced forms also display current project, login profile and feature-specific defaults. Knowing a program ID does not decide which workspace and current inputs to use. Readable names and states let a person inspect context without memorizing internal identifiers.
I read presentation code and existing records without switching accounts or creating tabs. The shared status-copy module operates on declared synthetic states only. The useful lesson is not merely an internally correct destination choice but a presentation another person can review. Delegation becomes easier when the person and executing agent can establish that they are referring to the same destination and its current evidence. A missing historical tab should remain visibly missing; opening a plausible replacement would change the question from reading a record to authoring a new destination.