How should a connected agent represent a referral separately from a conversation?

Represent the referral as an object with its own identifier, rather than embedding its entire meaning in a conversation note. A generated schema can include referral_id, customer_id, source_conversation_id, originating_team_id, destination_queue_id, status and current_owner_id.

The conversation link explains where the request began. The referral status explains what has happened operationally. Useful states can include draft, submitted, acknowledged, returned and closed, with allowed transitions defined by the scoped workflow. A submitted object should not imply that the receiving team has accepted responsibility.

Tool actions could include create_referral, submit_referral and get_referral_status. Each response should expose the persisted identifier and current state so the agent can inspect the result instead of relying on its intended action.

MirrorFirm could supply generated JSONL records with a schema describing these links, alongside tasks that begin after the original conversation has ended. An evaluation hook can then ask whether the agent identifies the current owner from persisted state. This tests continuity across sessions and discourages treating a polished customer message as proof that a business transfer occurred.