Copilot Contextual Resources - How Copilot Knows What You Are Looking At

There is a moment in almost every Copilot project where a client asks the question that sounds simple and is not: "why doesn't it know what I'm working on?" They have a document open, a chat thread in front of them, a report they are staring at, and they expect Copilot to understand that context the way a colleague sitting next to them would. When it doesn't, the whole thing feels dumber than it is.

Contextual resources are the part of the Microsoft 365 Copilot extensibility model that closes that gap. They are how an agent gets told what the user is currently looking at, so its answers can be about the thing in front of the person rather than some generic best guess. If you are building agents on Copilot and you want them to feel less like a search box and more like something that actually pays attention, this is a concept worth understanding properly. Microsoft's contextual resources documentation in the Work IQ API is the reference. Here is the consultant's read on where it fits.

What a contextual resource actually is

Strip away the terminology and a contextual resource is a pointer to the thing the user has in front of them at the moment they ask a question. An open Word document. A Teams message. A file in SharePoint. An email. The specific object the person is currently engaged with, expressed in a form your agent can pick up and reason about.

The reason this exists as its own concept is that "what the user is working on" is genuinely different from "what the user typed". When someone types "summarise this" while looking at a 40-page contract, the word "this" carries almost no information on its own. The contract is the information. The contextual resource is what carries that pointer through to your agent so "this" can resolve to the actual document rather than a shrug.

In the Work IQ API model, these resources travel alongside the conversation. Your agent can look at them, understand what kind of object each one is, and decide whether and how to use it. That last part matters more than it sounds, and I will come back to it.

Why this is the difference between useful and forgettable

I have seen a lot of Copilot agents that technically work and are still useless, and contextual awareness is usually the reason. An agent that answers general questions competently is fine, but people already have that, it is the base Copilot experience. The agents that earn their place are the ones that help with the specific piece of work the person is doing right now.

Think about the practical difference. A procurement officer has a supplier contract open and asks "does this have an early termination clause?" Without contextual resources, your agent either has to ask them which document they mean, or it goes hunting across the tenant and hopes. With contextual resources, the answer is right there: the document they are looking at is handed to the agent, and it can go straight to answering the actual question. One of those experiences feels like magic. The other feels like being made to fill in a form.

This is exactly the sort of thing that separates a demo that impresses in a meeting from a tool people keep using in week six. When we build custom AI agents for clients, the contextual layer is often where the real usefulness lives, because it is what lets the agent participate in the work rather than sit beside it asking to be told everything twice.

Where it fits in a real build

Here is how contextual resources tend to show up when we are building something for a client.

Early on, the interesting design question is not "can the agent read the open document", it is "what should the agent do differently depending on what is open". An agent that helps with contracts should behave differently when the user is looking at a contract versus a spreadsheet versus an email thread. Contextual resources give you the raw signal, but the value comes from what your agent decides to do with each type. That is design work, and it is worth doing deliberately rather than treating every resource the same way.

Then there is the handling itself. Your agent receives the contextual resources as part of the interaction and has to decide which ones are relevant to the current question. Not every open thing is relevant to every question. A good agent is selective, it uses the context that helps and ignores the noise. Getting that judgement right is part of what makes an agent feel sharp rather than easily confused.

And there is the honest limit: contextual resources tell your agent what the user is looking at, they do not do the thinking. The agent still has to read the document, understand the question, and produce something useful. The context is the ingredient, not the meal. Teams that expect the context alone to make the agent smart tend to be disappointed, because the reasoning is still the hard part and still your responsibility.

The honest bits, what to watch out for

Now the part the documentation will not put front and centre.

First, permissions. The single most important thing to get right with any contextual data is that the agent only ever sees what the user is genuinely allowed to see. A contextual resource is a pointer to a real object with real access controls, and your agent has to respect those controls end to end. This is not a nice-to-have. In a tenant full of HR files, legal documents and financial data, a permissions slip is not a bug, it is an incident. Treat the boundary as sacred, test it hard, and assume someone will eventually open something sensitive and ask your agent about it.

Second, be careful about assuming the context is complete. The resources you get describe what the user is currently looking at, which is often exactly what you want, but it is not the whole picture of what might be relevant. A question about a contract might genuinely need a related document that is not currently open. Do not let contextual awareness turn into tunnel vision where the agent only ever considers the one thing in front of the person and misses the obvious neighbour. Sometimes the right move is to use the context as a starting point and reach a little further.

Third, the extensibility surface here is still maturing. The Work IQ API and its resource models are evolving, and the shape of what you get and how you get it will keep shifting as Microsoft develops the platform. Build with that in mind. Do not hard-code assumptions about resource types or fields that you would be sad to unwind in six months. Keep the part of your agent that handles context loosely coupled enough that you can adapt when the platform moves, because it will.

Fourth, and this is the subtle one, more context is not automatically better. It is tempting to feed every scrap of available context into the agent's reasoning on the theory that more information helps. In practice, irrelevant context is a distraction that can make answers worse, not better. The skill is in selecting the context that matters for the specific question and leaving the rest out. An agent that uses two relevant resources well beats one that dumps ten into the prompt and hopes.

Who should care about this

If you are an Australian organisation building your own agents on Microsoft 365 Copilot, and you want those agents to help with real work rather than answer trivia, contextual resources are core to the experience you are trying to create. This is the mechanism that lets your agent be about the user's actual task. Skipping it is how you end up with an agent that is technically clever and practically ignored.

If you are still at the stage of turning Copilot on and getting people comfortable with the base experience, this is not where your attention needs to be yet. Get the rollout, the governance and the licensing sorted, let people build the habit, and come back to custom agents once you know what specific jobs are worth building for. The extensibility work pays off most when it is aimed at a real, understood need rather than built speculatively.

Most of the businesses we talk to are somewhere in the middle: Copilot is in use, and there is a growing list of "it would be brilliant if it could help with this specific thing while I'm doing it". That list is exactly where contextual awareness earns its keep. If you want a partner who will build agents with the engineering discipline and the permissions rigour this deserves, that is what we do. Have a look at how we work as Microsoft AI consultants, or get in touch and we will give you a straight read on where to start.

For the technical detail and the current state of the resource model, Microsoft's contextual resources documentation is the reference to keep bookmarked.