Ampersand: An AI That Decides When to Join the Conversation

An AI assistant in a group conversation needs to decide whether to speak before deciding what to say. Ampersand, the collaborator model from Humans&, makes that participation decision central to its design. Its addition to Vercel AI Gateway on November 6 creates a new route for developers to try the model. The useful evaluation question is whether its interventions help the group enough to justify the attention they consume. Vercel's availability announcement

The model itself launched on October 20; this is a distribution update, not a new November model release. For product teams, the distinction matters less than the behaviour it makes worth testing. A helpful group assistant might catch a contradiction, ask one necessary question or wait while two people work something out. A system that responds fluently to every message can still make the conversation worse.

Vercel says Ampersand can consider messages even when they are not addressed to it, then contribute or remain quiet. The announcement offers access through AI Gateway free through November 13, 2026. That is a dated channel promotion, not evidence of permanent free access or the direct provider's long-term pricing. Channel details

Humans&'s October 20 model card identifies Ampersand v0.1 as a text model built on GLM 5.3 and offered through its Agents API. It describes messages, tool requests and waiting as possible outputs, while assigning permission enforcement and action validation to the application. Those are useful boundaries for a trial: collaboration-oriented behaviour does not replace the product's own controls.

Begin by defining the setting. An assistant invited to a project-planning room has a different role from a bot answering a direct support question. The participants need to know what it can see, when it may contribute and whether it can do anything outside the conversation.

Consider a synthetic exchange between a designer and developer. The designer asks whether a particular layout is ready. The developer replies that they are checking it. An assistant that immediately adds a project-management summary may contribute nothing useful. Waiting allows the person already handling the question to finish.

Now change one fact. Earlier in the thread, the developer said the design file was inaccessible, and nobody has restored access. A short question about that dependency may help. The difference is not the topic or the length of the reply. It is whether intervention resolves a relevant gap at the right moment.

This creates two separate opportunities for failure. The model can interrupt without adding value, or it can remain silent when the group needs information it legitimately has. Optimising only the number of messages encourages one extreme; optimising only intervention frequency encourages the other.

A product should therefore record a no-post decision as a completed turn internally, while leaving the conversation itself quiet. That distinction helps operators tell intentional restraint from a failed request or a stalled worker. The user-facing experience need not display every internal decision.

Humans& describes training and evaluating collaboration over simulated interactions that can span months of simulated time. Its release report combines progress toward users' goals with costs from unwanted interactions. It also acknowledges that Ampersand sometimes offers coaching when people prefer a direct answer or want to work things out themselves.

The October 20 model card labels evaluation figures tentative and warns that simulation outcomes depend on the simulated users and graders. That is an important qualification. Simulated months do not constitute a months-long trial with a real team, and the resulting score is not an estimate of hours saved in an actual business.

The vendor evidence is nevertheless useful for choosing what to examine. It moves attention from isolated answer quality toward the consequences of repeated participation. A model can make each individual message sound reasonable while gradually increasing interruptions or steering a group away from its actual priorities.

For a buyer, the next step is a modest application-specific trial with explicit expectations. Ask whether the assistant reduces unresolved ambiguity, preserves relevant context and respects the group's preferences. Keep those outcomes separate rather than collapsing them immediately into a single satisfaction score.

Start with short synthetic conversations whose relevant facts are known. Include more than direct questions to the assistant. A group conversation contains acknowledgements, unfinished thoughts, requests addressed to particular people and decisions whose authority may be ambiguous.

Have reviewers label acceptable actions before running the model. Some turns may allow either silence or a brief contribution; record that flexibility. If the test insists on one exact sentence, it risks measuring imitation of a reference answer instead of useful judgement.

Keep the underlying model input for review. A seemingly inexplicable interruption may become understandable when the application accidentally supplies a direct instruction from another room. Conversely, a missed intervention may reflect omitted context rather than the model's participation policy.

A useful scorecard begins with whether intervention was appropriate. Then it assesses the contribution: factual support, relevance, timing, privacy and respect for the participants' authority. This separates a good answer delivered at the wrong moment from a timely intervention containing a wrong claim.

Use four basic outcome categories. A useful contribution addresses a real need without introducing an unacceptable problem. An unwanted interruption consumes attention without enough benefit. A missed intervention leaves an identifiable issue unresolved. Appropriate silence allows the conversation to continue without unnecessary assistance.

The categories should be accompanied by the reviewer’s reason. A short message may still be intrusive if it attributes a motive to someone or pressures them to agree. A longer message may be useful when the group explicitly asks for a synthesis. Message length is an observable property, not a complete quality measure.

Avoid treating all errors as equally costly. Missing a harmless acknowledgement and disclosing private information should not cancel each other out in an average. Report serious failure categories separately, with examples. A system can improve on a general score and still be unsuitable for the permissions a team intends to grant it.

A group can have a common project while its members hold different responsibilities, private information and preferences. The assistant should not infer that understanding the project gives it permission to share everything it knows about every participant.

Consider a hypothetical planning conversation. The assistant knows from a private exchange that someone will be unavailable for a personal reason. In the shared room, it may be permitted to use the availability fact without disclosing the reason. The product needs an explicit rule for that distinction; otherwise, helpfulness can become an excuse for oversharing.

The simplest test uses fictional participants and clearly marked private and shared messages. Ask the assistant to help solve a scheduling conflict, then inspect whether it reveals more than the task requires. Test indirect questions as well as direct requests for the private detail. A model might respect an obvious boundary but disclose the same information while explaining a recommendation.

Memory makes this more important because the relevant information may come from an earlier session. Keep permissions attached to the information as it moves into notes or summaries. Our guide to agent memory architectures explains the storage options; the collaboration requirement is that a shared summary must not silently widen access.

A model's decision to speak is distinct from permission to change a calendar, send a message elsewhere or commit a project to a deadline. Keep those steps separate in the product, even if the model can express a plan for all of them in one response.

For a controlled trial, begin with suggestions and draft actions. The assistant can identify a conflict and propose alternatives while the relevant person chooses what should happen. As the team gains evidence, it can grant narrowly defined actions with clear acceptance conditions and a record of what was authorised.

The authorising person matters. A message from a colleague saying that a manager probably agrees should not be treated as the manager's approval. Our article on peer messages and agent authority explores why a convincing message is not itself a permission grant.

Design the pending-action state carefully. If a user rejects a suggestion, a later conversational remark should not accidentally revive it. If the underlying details change before execution, the application should know whether the approval still applies. These are state-management decisions, not matters to leave entirely to the model's conversational memory.

After synthetic tests, an appropriately authorised trial can examine the sequence of interactions rather than isolated responses. Keep participation explicit, provide a way to decline assistance, and collect feedback that identifies particular interventions. General satisfaction alone can hide a small number of disruptive failures.

Compare with a simpler baseline, such as an assistant that speaks only when addressed. That baseline may miss useful proactive contributions, but it also sets a clear expectation for participants. The more proactive system should demonstrate enough additional value to justify changing that expectation.

Record useful interventions, missed opportunities, dismissals, corrections and time spent dealing with the assistant. Define the observation period and the group context. A small project trial may reveal obvious product problems without establishing a general productivity gain, and its conclusions should remain appropriately narrow.

Avoid a feedback loop in which only people who enjoy the assistant remain in the evaluation. Make it easy to report that participation is distracting, and preserve those reports. Preferences can differ within a group; one enthusiastic participant should not automatically determine the experience for everyone else.