Screens keep themselves current
A board, a product page or a decision open on your screen updates itself when somebody else changes something. There is no refresh button to remember and no polling loop draining your battery: the server tells your browser that something of a kind changed, and the page re-reads the same way it does after one of your own edits.
What travels is only the KIND of thing that moved - never the change itself. Your browser then asks for it through the ordinary read, with your own permissions, so a live update can never show you something you would not have been allowed to open. It also means a message that goes missing costs nothing but a delayed refresh, and reconnecting catches everything up.
A save can no longer quietly overwrite one you never saw
Two people editing one record used to mean last-write-wins, silently: whoever pressed Save second replaced the other's work with no error and no trace. Now an editor sends the version it was showing you, and a save against a version that has moved is refused rather than applied.
Most of the time you will never see that happen. If the change that landed first touched different fields than yours - somebody dragged the card while you were fixing its description - your save goes through anyway, quietly. You are only interrupted when you and somebody else changed the same thing, which is the only case where a person actually has to decide.
When you are interrupted
The note names which fields moved under you and leaves everything you typed exactly where it is. You have two ways out: cancel, and re-open the record to see what changed; or Save anyway, which applies your version knowing what it replaces. Nothing merges the two - one of you retypes a paragraph. That is the honest floor, and it is a much better floor than finding out a week later that a paragraph is gone.
Over the API and over MCP the same refusal is ENTITY_CHANGED, and it names the fields that moved so a well-written agent can do exactly what the editor does: re-read, and retry when the two writes did not overlap.
Agents work the same way
An agent calling update_task, update_product or update_decision can pass the version it read, and gets the same refusal your browser would. Passing nothing still works and still writes - that is a one-shot call that never read the record, and it is a legitimate thing to do. The guard protects the callers who can say what they saw.
Agents do not get the live stream: an open connection is not something the stateless agent transport can hold. What an agent has instead is list_changes - the same question against a cursor, returning the kind of each change and the record it touched so the agent knows what to re-read. It reads the event log rather than the Mission Log, so it also reports the changes the log does not show at all. Delivery is at-least-once, so an agent dedupes by id and never loses anything between calls. poll_changes is still the one to use for what needs a person: pending approvals and new assignments.