Copilot has always been a prompt-and-response tool. You ask it something, it responds. Useful, but reactive.

Cowork changes the model. Instead of prompting Copilot with a question, you delegate a goal.

'Compile a risk summary from the last three quarterly reports.'

'Review these 40 supplier contracts and flag anything that doesn't match our standard terms.'

'Pull together a briefing note on this client from our SharePoint files and recent email threads.'

Cowork plans the work, executes it across your Microsoft 365 environment, and delivers the output. You don't have to stay at your keyboard while it runs. It runs on GPT-5.5

 Thinking and Anthropic's Claude Opus 4.8, with an Auto mode that picks the right model for each task.

This is the part that caught some organisations off guard at the end of July. And it's worth being very direct about it.

Cowork doesn't run on your per-seat Copilot licence alone. It uses Copilot Credits on top of it.

Credits are billed at $0.01 (R0.18 / £0.008) per credit. Every Cowork task consumes credits based on the model used, the volume of context retrieved, the number of tool calls made, and how long the task runs.

To give you a sense of what that looks like in practice:

Those numbers are per task. For a team running Cowork heavily, costs can accumulate quickly.

Teams that configured spend alerts and usage caps before expanding access managed their costs without surprises. Teams that enabled Cowork broadly without billing controls had an uncomfortable finance conversation at the end of July.

Configure spend alerts and usage caps in the Microsoft 365 admin centre before you expand Cowork access beyond a small pilot group. This is not optional. It's five minutes of setup that prevents a much longer conversation later.

Two billing options exist: pay-as-you-go at the standard rate, and prepaid annual credits at a lower per-credit rate. Pay-as-you-go is the right starting point for most organisations. Two to three weeks of pilot data tells you what your actual usage pattern looks like. Then you can make an informed decision about whether prepaid credits make economic sense.

Cowork executes tasks using the permissions of whoever initiates them. It reads email, accesses SharePoint, generates documents, and takes actions in connected apps — all based on whatever access the user already has.

This is why the permissions work that should precede any Copilot deployment matters even more before scaling Cowork. An overshared SharePoint environment doesn't become safer when Cowork starts running in it. It becomes a more efficiently exploited one.

Two things to have in place before you expand access:

•  Purview audit logging for Cowork activity — this is included in the GA baseline, but needs to be verified as active. It's what gives you the ability to see what Cowork actually did on behalf of a user.

•  Agent 365 governance — if you're using Agent 365, Cowork activity falls under the same governance framework. Agent 365 gives you visibility into Cowork as a managed agent alongside any others in your environment.

GTconsult helps organisations across South Africa, the UK, and the US get more from Microsoft 365 and SharePoint — from custom development and migrations to security, support, and AI solutions.

This is not a Copilot problem. Copilot works. The problem is almost always what happened — or didn't happen — before anyone pressed enable.

Here are the five things that separate a Copilot deployment that delivers from one that quietly becomes expensive shelfware.

Think of Copilot as an amplifier. It takes what's in your Microsoft 365 environment and makes it faster to find, easier to use, and more accessible.

If your data is well-organised and current, that amplification is genuinely powerful.

If your SharePoint looks like a digital filing cabinet that hasn't been touched since 2018 — inconsistent folder structures, outdated documents, no metadata, no content types — Copilot will amplify that too.

Garbage in. Garbage out. Except now it happens at AI speed.

The data hygiene work — archiving what's obsolete, applying sensitivity labels, enforcing consistent content types — is unglamorous. It's also the single thing that most determines whether your Copilot deployment succeeds.

Enabling Copilot for 500 people on day one is the fastest way to ensure that 500 people try it once, get inconsistent results, and decide it's not worth the effort.

The organisations that see strong Copilot adoption do it differently. They pick one team with a specific, measurable workflow. A finance team that produces a weekly report. A procurement team that reviews the same document types every month. An HR team with a predictable onboarding process.

Deploy to that team. Train them on that specific workflow. Measure whether it saves time. Document what worked. Then use that as the blueprint for everyone else.

This sounds obvious. Most organisations skip it.

If you don't define what success looks like before a Copilot deployment, you can't tell whether it's working three months in. You can't identify problems early. You can't justify the investment to leadership when they ask.

Your success metrics don't need to be complicated. Weekly active usage versus licences assigned. Time saved on a specific recurring task. User satisfaction score from the pilot team. The Microsoft 365 admin centre has a Copilot Dashboard that gives you adoption data across every application. Use it from day one, not after things start going wrong.

The pattern is consistent enough that it has a name in the industry: "shelfware." Licences that are paid for, assigned, and barely used.

It usually unfolds the same way: licences purchased, announcement made, training session held, adoption flatlines, leadership asks why ROI is low, nobody has a good answer because nobody measured anything, the investment is hard to justify at the next renewal.

None of that is inevitable. It's the result of skipping the preparation that sits between procurement and deployment.

The good news: all of it is fixable. Even if you've already deployed.

If your Copilot adoption is lower than you'd hoped, start with the Copilot Dashboard in the admin centre. It will show you exactly where usage is and where it's not. That data tells you which of the five steps above to address first.

GTconsult works with organisations across South Africa, the UK, and the US on Microsoft 365 planning, deployment, governance, and adoption. Get in touch for a free consultation.

In July 2026, Microsoft launched the Agent Store's governed publishing flow. Teams can now build agents in Copilot Studio, submit them for admin review, and publish them under a 'Built by your org' section that anyone in the organisation can find and use.

This is genuinely useful. Internal tools that were previously invisible are now discoverable.

But here's the governance implication: an agent built by one team — with permissions that made sense for that team's specific use case — is now accessible to everyone in the business. An agent with broader data access than it needs, that was previously used by three people, can now be triggered by anyone who finds it in the Agent Store.

Agent 365 is the control layer that lets IT see, govern, and apply policies to everything in that Agent Store catalogue. Without it, you're publishing without visibility.

If you haven't opened Agent 365 yet, here's the sequence that makes sense:

1.  Open the Microsoft 365 admin centre and navigate to Agent 365. Review the registry. Most organisations find agents they weren't aware of — including some deployed by teams without IT involvement. That discovery alone is worth the five minutes it takes.

2.  Check the Agent Store under 'Built by your org.' These agents are now discoverable org-wide. Verify that everything published has been through a proper review and is appropriately scoped.

3.  Use Defender's asset context mapping to go beyond a list of agent names. Understand what identities and cloud resources each agent can actually reach. That's the question that matters for a real security posture assessment.

4.  Set a governance baseline — before the list of agents grows any longer. Decide what data access is permitted by default for new agents, when admin approval is required for publishing, and how permissions will be reviewed over time.

The last step is the important one. It's much easier to establish governance standards before there are 50 agents to manage than after.

AI agents are no longer a future consideration for enterprise IT. They're running now, in your environment, whether IT knows about them or not.

Agent 365 gives you the visibility to see what's there, the controls to govern how agents behave, and the security integration to respond when something goes wrong.

The organisations that will manage AI agents well are the ones that set up the governance layer before the list of agents gets unmanageable. That moment is now.

GTconsult works with organisations across South Africa, the UK, and the US on Microsoft 365 planning, deployment, governance, and adoption. Whether you’re just getting started or trying to unlock value from licences you’ve already bought, we can help.