Two talks on the same evening, from opposite directions, arrived at the same place.
I spoke at the PowerUp! Meetup (Finland) Live Meetup on 2 September 2026, hosted by Microsoft in Keilaniemi, Espoo, about governing what a Copilot Studio agent is allowed to use. The speaker after me, Anniina Rousu of Context&, spoke about designing the human experience of an agent: agency, trust and responsibility. I went at it as a platform problem. She went at it as a design problem. We ended up saying the same thing in different vocabulary, and hers is the sentence I have been repeating since.
A good agent does not know a lot. It knows what, out of all of it, is relevant right now.
This post is my recap of her session. Any clumsiness in it is mine, not hers.
Where she is coming from
Anniina is a theologian by training, with psychology and theoretical philosophy alongside it, and she now designs agents with customers. That is an unusual route into Copilot Studio and it shows in the questions she asks. She describes herself as a bridge between people and the technology.
Her framing is that building agents keeps getting easier. Anyone who has watched Copilot Studio over the past two years has seen the barrier drop, release after release. Her question follows directly from that: when the technical part stops being the hard part, what is left, and what of it belongs to a human?
The answer is that the difficult questions move. They stop being about how to make the agent answer and become: what should this agent do at all, where is its boundary, how does it work with people, and what kind of experience does it produce.
She organises that into four dimensions, taken from an agent experience framework she pointed the audience to. I am deliberately not attributing the framework here because I could not make out the name from my recording, and a wrong credit is worse than none. Ask her.
01 Specificity: eligibility is not the same as relevance
Her observation from customer work is one I recognise exactly. The customer wants the agent to know as much as possible. So knowledge sources get piled on. When that is not enough, child agents get added, each with more sources of their own.
Her position is that this is the wrong axis. The same question should not produce the same answer for everyone. Context is the user’s role, their team, their permissions, where they are in a process, what they have already done, and what is actually in front of them right now.
Her example is onboarding, which is the first thing most organisations want to automate because nobody enjoys doing it. But a new junior and a newly hired senior specialist do not need the same onboarding, and a generic checklist serves neither. If the agent knows who the user is and what they have already done, it can give the part that is relevant to that person.
So the technical question is not whether we can get the agent to answer. It is whether we can get it to use the right information in the right context.
She also said something in passing that I suspect a lot of the room agreed with. She likes Topics, and she is worried about what happens to them in the newer Copilot Studio. Instructions plus knowledge sources will carry a lot of situations, but a topic is where you can say what should happen in this specific case, and that is a different kind of control.
02 Attention: what the agent surfaces starts to look like what matters
This is the dimension I had not thought about at all, and it is the one I have kept thinking about since.
An agent never just delivers information. It decides what to surface, what to prioritise, what to leave in the background, what to ask, and in what order to bring things up. Those are design decisions, and none of them are neutral.
Her line: what it surfaces starts to look essential to the user.
She then made it personal, which is what made it land. Two years ago her use of AI was task-shaped: hand it a task, take the output. Now she has built what she calls a thinking sparring partner. Her own writing starts as thinking out loud with it. When it proposes something, she pushes back and interrogates it rather than accepting it, and out of that a dialogue has formed where her instructions and her sources keep sharpening as her own thinking changes.
Sometimes the model raises a concept she had not put on the table, and the conversation goes somewhere deeper than she had planned. Her point is not that the machine was right. It is that attention got directed, and she still had to judge the direction and correct it.
The most interesting part of working with AI, she said, is not the finished answers. It is how the interaction helps you think better.
Bring that back to Copilot Studio and it stops being philosophy. When you design an agent you are deciding what it raises to the user, what it asks, what it prioritises, and what it leaves unsaid.
03 Trust: not confidence, evaluability
Trust does not come from the AI sounding confident. It comes from the person being able to work out who or what is acting, what the system knows, what it does not know, where the limits are, and how much weight this particular answer will bear.
Her first example is a customer service chat where the line between human and AI was blurred enough that she had to stop and work out which she was talking to. Nothing announced it. The bot had an ordinary first name, so she addressed it like a person and carried on.
That matters because people evaluate an answer differently depending on who gave it, and they should. Somebody with less exposure to these systems may not even ask the question. If you cannot tell what you are dealing with, you cannot calibrate your trust, and transparency stops being a nicety.
Her second example is about herself, and she told it on herself in front of the room, which I thought was the strongest thing in the talk.
She was ill, genuinely feverish, and busy. She let AI translate material for a customer meeting. A couple of translation howlers got through. People laughed, and in the moment it was funny. What she noticed afterwards was that in some of the room it had shifted something: a small sense that her credibility had slipped, that this said something about how she works.
The blunder was tiny. The effect was not proportional to it. A small visible AI mistake can colour the assessment of a much larger body of work that had nothing wrong with it, because it is recognisable and it is the kind of thing people remember.
Her conclusion is the sentence I wrote down: AI does not compensate for weakened judgement.
And she put the design consequence next to it, which I think is the harder half. Trust in AI-assisted work can build slowly and turn over quickly. Plenty of successes go unremarked and one identifiable AI slip sets the tone. So we cannot design systems whose trustworthiness depends on a human being perfectly sharp at every moment. We need to build in enough room that people get some grace too.
04 Agency: an approve button is not control
The last dimension is the one that turns all of this into requirements you can actually write down.
Who is really acting here? Who decides? Does the person keep the ability to influence what happens? Can the user interrupt, correct, change direction, ask for an explanation, or reach a human being?
Then the part worth pinning above the desk: control is not the same as an approve button. If the person does not understand what they are approving, an approval step does not make them a decision-maker. It makes them a signature. And smoothness is not the goal either: a good user experience does not mean involving as little human as possible.
Her failed-escalation example is ordinary enough that everyone has lived it. A customer service bot could not answer her question, and simply went quiet. She asked explicitly to speak to a human. She still did not get through. She was able to work around it, and her question was what happens to a user who cannot.
Escalation must not be left to the user’s ingenuity.
The exits have to be designed.
She mentioned a client case from that same week. The instructions said the agent should hand over to a human when needed, and the view was that no separate escalation topic was necessary. They questioned that and built the escalation topic anyway. Leaving the handover to instructions alone does not reliably hold, which is a very concrete Copilot Studio design conclusion and not a philosophical one.
Her summary of the dimension: a good agent also knows how to stop and hand agency back.
Why this sat so well next to my own session
My talk was about scope: what the agent is allowed to use, how the lifecycle of that knowledge is governed, and how you prove the behaviour with evaluations instead of intuition. Hers was about experience: specificity, attention, trust, agency.
The overlap is not a coincidence. Both talks are a reaction to the same change. When building becomes cheap, the expensive mistakes move upstream into decisions nobody was forced to make before. I answer that with a governance boundary. She answers it with a design boundary. An agent that may only use approved, current, owned content and an agent that surfaces only what is relevant to this person right now are the same agent described from two sides.
Where hers goes further than mine is the last question of the evening, and I do not have a platform mechanism for it:
Does the person still feel that they are acting, rather than watching a system act on their behalf?
When we build agents, we are also building the relationship that forms between the person and the AI. That part is not in the YAML.
The four questions worth stealing
Anniina closed with questions rather than answers, which suited the material. These are the ones I would put into a design review tomorrow.
- What must this agent not do by itself?
- At which point must it ask, and at which point must it stop?
- Can the user tell whether they are dealing with a person or a system, and does anything tell them?
- If the agent cannot help, does the exit exist by design, or does the user have to invent it?
My own session from the same evening is written up separately: Defensible beats impressive.