Copilot Chat vs agents: when to use which
The most common question I get in Copilot workshops right now is not “how do I write a better prompt”. It is “should I be using an agent for this?” And the honest answer, probably of the time, is no. Copilot Chat vs agents is a decision about repeatability, not about which one looks more impressive in a demo.
Here is the short version. Copilot Chat is for the work you do once. An agent is for the work you, or your team, do the same way every week. If you cannot describe the task well enough to write instructions for someone else, it is not ready to be an agent.
What Copilot Chat actually is
Microsoft’s own definition is useful here. Copilot Chat is an AI prompt and response experience grounded in the web and included with a Microsoft 365 subscription at no extra cost. The licensed Microsoft 365 Copilot adds grounding in your work data (files, meetings, emails, Teams chats) and puts Copilot inside Word, Excel, Outlook and the rest.
Either way, the interaction model is the same. You open a chat, you give it context, you ask for something, and you judge the result. It is general purpose by design. Upload a file, paste a document, ask it to summarise, rewrite, compare, draft or analyse. Then close the tab and move on.
That generality is the point. It is also the limitation. Every time you open a new chat you start from zero. Your instructions, your tone, your reference documents and your preferred structure all have to be supplied again. For a one-off task that is fine. For the fifth time this month, it is waste.
What an agent actually is
Microsoft Learn describes agents as AI that automates and executes business processes, working alongside or on behalf of a person, team or organisation, ranging from simple prompt-and-response agents to fully autonomous ones. Strip the marketing off and an agent is a saved configuration: fixed instructions, fixed knowledge sources, and optionally fixed actions it can take.
There are two families of agents you need to know about so lets flush out what they are here
Declarative agents
These run on Copilot’s own orchestrator and models. You supply instructions, knowledge (SharePoint sites, public websites, uploaded files) and optionally some actions. No hosting, no model choice, no custom orchestration. Microsoft is explicit that this is where you should start. They are designed for individual use, they are user-initiated, and they inherit Microsoft 365 security and compliance out of the box. Agent Builder inside Copilot and Copilot Studio are the tools.
Custom engine agents
These let you bring your own models, your own orchestration logic, proactive triggers, group collaboration in Teams channels, and publishing outside Microsoft 365. They also require you to host them, secure them, and own the responsible AI story yourself. Microsoft’s own guidance reserves these for complex workflows, multi-system integrations and autonomy. If your first agent is a custom engine agent, something has gone wrong in the scoping.
The decision framework I use with clients
I run this as a five question test in enablement sessions. It works because it forces people to think about the task, not the technology.
1. Will you do this task again, the same way?
One-off analysis, an ad hoc email, a quick summary of a document you will never see again: Copilot Chat. A weekly client report in a fixed format, a first-line answer to the same HR policy questions, a triage step every ticket goes through: agent territory.
2. Does it need a fixed body of knowledge?
If the answer depends on a specific set of documents (your policies, your product catalogue, your project SharePoint site), an agent lets you point at that knowledge once rather than uploading it every session. If the knowledge is whatever you have open right now, chat is quicker.
3. Does someone else need to use it?
A chat prompt lives in your head or a Notepad file. An agent can be shared, governed and improved centrally. The moment a task moves from “I do this” to “the team does this”, the case for an agent gets much stronger, because consistency is now worth money.
4. Does it need to take action, not just answer?
Retrieving an order status, raising a ticket, updating a record. Chat can advise on these. An agent with actions can do them. That is the line between assistance and automation, and it is where the productivity numbers in the business case actually come from.
5. Does it need to run without a human starting it?
Proactive triggers, agent-to-agent handoffs, workflows that kick off on an event rather than a prompt. Declarative agents do not do this. Custom engine agents do. If you genuinely need it, budget for hosting, engineering and governance accordingly.
Score it simply. Zero or one yes: stay in Copilot Chat and get better at prompting. Two to four: build a declarative agent. Five, with a clear business case: consider a custom engine agent, and make sure someone owns it.
The cost angle often forgotten
This matters more than it looks. Declarative agents grounded only in instructions and public websites are available in Copilot Chat at no additional cost. The moment an agent touches shared tenant data such as SharePoint or Graph connector content, it moves to metered consumption, and those agents are switched off by default for Copilot Chat users until an admin enables pay-as-you-go billing through a Copilot Studio subscription.
Fully licensed Microsoft 365 Copilot users get agents included. So the decision is not just “chat or agent”. It is “which licensing scenario are we in, and does this agent’s grounding push us into metered billing we have not planned for?” I have seen pilots stall on exactly this point, because the enthusiastic maker built something brilliant against a SharePoint library and nobody had turned on the billing plan.
Three patterns I keep seeing
The agent that should have been a prompt. Someone builds an agent to “write LinkedIn posts in our tone”. It has three lines of instructions and no knowledge sources. That is a saved prompt with extra governance overhead. Keep it in chat, or use Copilot’s prompt library.
The prompt that should have been an agent. A finance team member has a 400 word prompt saved in OneNote, pastes the same four reference documents every month, and has trained two colleagues to do the same. That is a declarative agent begging to exist. Ten minutes in Agent Builder pays back every month.
The custom engine agent that should have been a Power Automate flow. Deterministic process, clear rules, no judgement required. Do not put a language model in the loop just because the budget line says AI.
Where I land
Copilot Chat is your general-purpose workbench. Agents are the jigs you build once you have made the same cut enough times to know exactly what good looks like. Start in chat, notice what repeats, promote the repeatable work to a declarative agent, and reserve custom engine agents for the handful of processes where autonomy and integration justify owning the whole stack.
The organisations getting real value from this are not the ones with the most agents. They are the ones who can articulate, for every agent they have, which of the five questions it answered yes to.
Work with me on this
If your teams have Copilot licences and a growing pile of half-built agents, this is exactly the kind of sorting exercise I run in an AI enablement engagement: which tasks stay in chat, which become agents, and what the governance and billing model needs to look like before anyone else builds one. Have a look at how the AI Fractional Adviory engagement works, or get in touch and we will talk it through.
The post Copilot Chat vs Agents: When to Use Which appeared first on Gethyn Ellis.
PakarPBN
A Private Blog Network (PBN) is a collection of websites that are controlled by a single individual or organization and used primarily to build backlinks to a “money site” in order to influence its ranking in search engines such as Google. The core idea behind a PBN is based on the importance of backlinks in Google’s ranking algorithm. Since Google views backlinks as signals of authority and trust, some website owners attempt to artificially create these signals through a controlled network of sites.
In a typical PBN setup, the owner acquires expired or aged domains that already have existing authority, backlinks, and history. These domains are rebuilt with new content and hosted separately, often using different IP addresses, hosting providers, themes, and ownership details to make them appear unrelated. Within the content published on these sites, links are strategically placed that point to the main website the owner wants to rank higher. By doing this, the owner attempts to pass link equity (also known as “link juice”) from the PBN sites to the target website.
The purpose of a PBN is to give the impression that the target website is naturally earning links from multiple independent sources. If done effectively, this can temporarily improve keyword rankings, increase organic visibility, and drive more traffic from search results.
