hrishikesh kamath

The question gets sharper once you add time. Two people steering at once is one problem; two people steering an hour apart is another. The first instruction has already shaped the work by the time the second arrives, and “preserve both intentions” means something different when one of them has been partly executed. Does the agent treat the earlier direction as settled context that the later person is implicitly overriding, or as a standing constraint the later person may not have seen? Your history view answers “what happened,” but the agent still needs a rule for “what still binds.” There is also the quieter failure, where the instructions don’t visibly conflict but pull in different directions. One teammate says keep the onboarding under four steps, another adds a consent screen for a new region. Neither contradicts the other on its face, and the agent can satisfy both by compressing something else. The person reviewing the thread sees two reasonable requests and one reasonable result, and nobody notices that the skip link got folded into a footer. Readable history surfaces conflicts people would recognize; it does less for the ones that only show up in the output. Which raises the practical question of what the agent should do at the moment it notices. Pausing and asking is safe but turns every shared session into a queue of blocked questions. Picking one and noting the choice keeps things moving but means the losing instruction was overridden by software rather than by a colleague. Some teams will want role-based precedence, some will want last-writer-wins with a loud annotation, some will want the agent to branch and show both. Is that a setting the session owner configures up front, or something the agent infers from who is in the thread and how they’ve resolved similar collisions before? Suppose it is a setting. Then someone has to own it, and ownership of a session is itself a fuzzy idea once more than one person is typing into it. The person who opened the thread may have left it by the time the conflict arrives. The person who invited the second contributor may not have understood that inviting meant delegating. If the rule is “the creator decides,” the creator becomes a bottleneck for a conversation they are no longer part of. If the rule is “anyone present decides,” then presence has to be defined, and a tab left open in the background counts as present in every way the software can measure. Suppose instead it is inferred. The agent looks at past sessions, sees that when Priya and Dan disagreed, Priya’s instruction usually stood, and leans that way. This is efficient and almost certainly wrong in the way that matters. Priya’s instructions stood because she was closer to the customer on those tickets, not because she outranks Dan in general. The agent has learned a correlation and will apply it to the next conflict, which is about billing, where Dan is the one who knows. Inference from history produces a quiet hierarchy nobody chose and nobody can see. The reminders example makes the stakes concrete. Automatic reminders are a growth lever; a customer group that must never receive them is probably a legal or contractual constraint. These are not symmetric. One is a preference and the other is a prohibition, and a well-behaved agent should treat a prohibition as winning regardless of who said it or when. But the agent only knows it is a prohibition if someone told it so, or if the phrasing happened to carry the weight. “Please don’t send reminders to the enterprise tier” and “the enterprise tier must never receive reminders under the DPA” look similar to a model that is pattern-matching on intent. The second one has a reason attached; the first one may have the same reason and simply didn’t say it. So one answer is that instructions should carry metadata about their own strength. A person could mark something as a hard constraint versus a soft preference, and the agent could weigh accordingly. This is clean and nobody will do it. People do not annotate their messages in a chat thread with priority levels, and asking them to is asking them to do the agent’s job. The more realistic version is that the agent asks, once, when it detects a collision: “Is the no-reminders rule a hard constraint?” And now you are back to the blocked-question queue, just with a narrower question. There is a middle path where the agent proceeds but makes the conflict impossible to miss. It applies the more restrictive instruction, since that is the reversible choice, and it writes a visible note in the thread saying what it did and why. The person who wanted reminders sees that their instruction was shelved, and can escalate if they disagree. This has the virtue of defaulting toward caution and the cost of making the thread noisy. Every collision generates a note. In a session with four active contributors and a long-running task, the notes may outnumber the actual work. Noise is not a trivial objection. The whole case for the multiplayer thread is that the history is readable, that someone arriving late can scroll up and understand what happened. If the agent fills the history with its own commentary about conflicts it resolved, the history becomes a log, and logs are not readable in the sense you mean. They are searchable, which is different. The person who spots a mismatch now has to find it among forty annotations, most of which concern collisions that didn’t matter. Which suggests the agent needs a sense of which collisions matter. The reminders case matters because it touches an external party, a customer, and the consequence of getting it wrong is an email that cannot be unsent. The invite-step case does not matter in that way; if the invite step ends up in the wrong place, someone moves it. One instinct is to grade conflicts by reversibility and only surface the irreversible ones. This is a reasonable heuristic and it has a hole: the agent’s estimate of reversibility is only as good as its model of the world, and it does not know that the “move the invite step” change is going into a release that ships tonight. Maybe the grading should come from the environment rather than the agent. A session connected to a production mail sender is high stakes by construction; a session editing a design file is not. If the platform knows what the session can reach, it can set the default conflict behavior without anyone annotating anything. Sessions with irreversible side effects pause on collision; sessions with reversible ones proceed and note. This moves the decision from the people in the thread to the people who configured the integrations, which is probably where it belongs, since they are the ones who understood what the mail sender could do when they connected it. It also raises the question of whether the two contributors should even have equal authority over the mail sender. Permission to steer the session and permission to trigger its side effects are not the same thing, and most systems collapse them. If I can type into the thread, I can tell the agent to send the email. A more careful model would let the session owner grant steering rights broadly and effect rights narrowly, so that a teammate can redirect the work but cannot, through the agent, do anything they couldn’t do directly. Then the reminders conflict partly resolves itself: the person who asked for automatic reminders may not have the standing to cause them, and the agent can say so. But permissions are a blunt tool for a conversation. Most of what people say in a thread is not a command, it is context, and context from someone without effect rights is still useful. “The enterprise customers hate getting emails” is not an instruction and carries no permission, but the agent should hear it. The system has to distinguish between someone contributing information and someone issuing a directive, and people do not mark the difference when they type. They say “we should probably not email them” and mean either a fact about the world or an instruction, depending on who they are and what they’re thinking about. This is the point at which the problem stops looking like a conflict-resolution problem and starts looking like an interpretation problem. The agent is not adjudicating between two clear instructions; it is reconstructing what two people meant from fragments, and then discovering the reconstructions don’t fit together. The conflict may not even exist at the level of intent. The reminders person may have meant “reminders for trial users,” and the no-reminders person may have meant “the enterprise tier,” and the only reason they look like a collision is that neither of them specified the scope. A good agent would notice that the scope is unspecified and ask about that, rather than treating the collision as given. Asking about scope is cheaper than asking about precedence. “Which users should get reminders?” is a question either contributor can answer, and the answer often dissolves the conflict without anyone having to win. “Who gets to decide?” is a question that forces a hierarchy into the open, and people are reluctant to answer it in a shared thread where the other person can read the answer. If the agent has to interrupt, it should interrupt with the question that is easiest to answer and least likely to make anyone look overridden. There is still the hard case, where the scopes are clear and the instructions really do collide. Reminders to everyone; no reminders to the enterprise tier; the enterprise tier is part of everyone. Here the agent has to pick, pause, or branch. Branching is underrated. The agent could prepare both versions, the one with reminders and the one without, and present them side by side with the difference highlighted. Nobody has decided anything yet; the agent has simply done the work twice so that the decision can be made by looking rather than by arguing. This costs compute and buys clarity, and compute is cheap relative to a meeting.