Customizing an AI agent that speaks in a shared room

Facilitator is documented as an agent that keeps meetings focused by surfacing agendas, tracking progress, and capturing highlights in real time. That description undersells the one property that makes it architecturally unusual.

Microsoft's admin documentation states it plainly: a user's prompts to Copilot in Teams and Copilot's responses are private to that individual user, whereas Facilitator acts like an assistant sitting in the meeting — if a user prompts it, all users can view that communication, and its response appears in the meeting conversation for everyone to see.

So it is not an assistant. It is a participant. And the participation is asymmetric in a way that matters: a Microsoft 365 Copilot licence is required to turn it on or prompt it, unlicensed participants can read everything it says but cannot direct it, and external participants cannot interact with it at all. Only organizers and presenters can switch it on or off mid-meeting.

That is a room where several people are affected by a configuration none of them made.

Most AI configuration design assumes a private loop. You set a preference, you see the result, you adjust. Being slightly wrong is cheap because you are the only one who experiences it, and the correction is immediate.

Remove the privacy and that loop breaks in both directions. The person who set the preference is not necessarily the person reading the output, the reader has no way to tell which behaviour was configured and which is default, and there is no quiet correction — the artifact is already in the conversation and, per the documentation, retained as meeting transcript data under the same governance as a transcript.

That reframes what a good customization is. It is not the one that gives organizers the most control. It is the one whose effect stays legible to people who did not choose it, and whose failure mode a room can recognise as a setting.

The product's existing behaviour already reflects this posture. It declines to read the organizer's copy of an invite until a non-organizer has joined, for privacy reasons, and it will not extract an agenda from sensitivity-labelled content. Those are refusals, published as documented behaviour. They are the right precedent: in a shared room, the constraints are part of the product, not gaps in it.

I run this work close to fully agent-driven, and my job has mostly become deciding what agents are not allowed to decide.

What agents are good at is not surprising: the wide, shallow work — reading unfamiliar code, proposing implementations, keeping changes consistent across layers of a system that spans several. What they are bad at is knowing when a plausible answer is the wrong one, and on a shared-output AI surface that is precisely the expensive failure.

So the standards live in the repository. Instructions, skills, and agent definitions are checked in, which means the rules apply to every change instead of to whichever ones I happened to look at closely. Behaviour changes are judged against rubrics. A demo that went well is not evidence. And the gates are non-negotiable in a way that is deliberately annoying, because the entire value of moving fast this way is that the speed does not come out of the review.

This site is the second place I have applied that method, and you can read the whole of it, since none of it is confidential.

I did not start here. The four years before this were spent on the scheduling and meeting-configuration surfaces underneath it — Virtual Appointments, then Meeting Options and Meeting Templates, then porting both into the unified Teams calendar. That history is on the Microsoft record.

What carries over is narrower. I spent those four years on the question of what happens when meeting settings are wrong, usually finding out because someone paged me about it. Arriving at an AI agent whose configuration is visible to a whole room, it turns out to be the same question with higher stakes.