Agent Context Is Not Consent
2026-06-04 · 4 min read · Janaina Maia
The next enterprise AI race is not only about smarter models. It is about who owns the context layer around work.
Microsoft announced that its Work IQ APIs will become generally available on June 16, 2026. In simple terms, Work IQ is Microsoft’s attempt to turn the signals inside Microsoft 365 — email, calendar, meetings, chats, files, people, collaboration patterns, and business systems — into a context layer that AI agents can use. The promise is that agents will stop working from raw documents and start working from a live model of how the organisation actually operates.
That is powerful. It is also exactly where design leaders need to be more careful.
Context makes agents useful.
Most AI agents are weak when they do not understand the work around the task. They can summarise a document, but miss the politics behind it. They can draft an email, but ignore the meeting that changed the decision. They can search a file, but fail to understand who owns the work, which version matters, or what the team already tried.
A shared work intelligence layer is meant to solve that. Instead of asking an agent to operate with a tiny window of information, the system gives it richer organisational memory. That can make outputs more relevant, reduce repetitive explanation, and help agents move across workflows with less friction.
For enterprise AI, this is a real product shift. The agent is no longer just a chat interface. It becomes a participant inside the organisation’s living context.
But context is not consent.
This is the line I would not let teams blur. Just because a system can infer context does not mean the agent should automatically use it. A meeting, email thread, org chart, file history, or collaboration pattern may be technically available but still sensitive, stale, politically loaded, or irrelevant to the user’s intent.
There is a difference between “the agent can see enough to help” and “the agent is entitled to use everything it can see.” Product teams need to design that difference clearly.
Users should understand when an agent is using broad organisational context, when it is using only the current artefact, and when it needs permission to bring in more. Otherwise the experience may feel clever at first, then quietly invasive.
The design surface is scope.
In many enterprise products, scope is treated as a backend permission model. With agents, scope becomes part of the user experience. It should be visible at the moment of delegation.
If I ask an agent to prepare for a performance review, draft an account plan, summarise a project risk, or recommend the next step in a workflow, I should be able to see what context it used. Did it look at my files only? Team conversations? Calendar history? CRM records? Prior decisions? Was anything excluded? Did it infer relationships I did not explicitly provide?
That does not mean overwhelming users with technical logs. It means translating access and context into plain-language boundaries humans can reason about.
Design implications.
- Show the context boundary: make it clear whether the agent is using this document, this workspace, this team, or broader organisational memory.
- Let people narrow the scope: users should be able to say “use only these sources” without fighting the system.
- Separate relevance from permission: something may be relevant and still require approval before the agent can use it.
- Expose source categories: show whether the answer came from meetings, files, chats, business systems, or inferred collaboration patterns.
- Design graceful refusal: when context is restricted, the agent should explain the boundary instead of pretending certainty.
My take.
Work IQ points to a future where enterprise agents become much more useful because they understand the texture of work, not just the contents of a prompt. I think that direction is right. But the more contextual the agent becomes, the more visible its boundaries need to be.
The trust question is shifting from “Can the model answer?” to “What did the agent know, how did it know it, and was it allowed to use that knowledge here?”
Context will be a competitive advantage. Consent, scope, and review will be the design work that makes it safe enough to use.