What Happens When The Screen Stops Being The Starting Point?

image

I keep coming back to a simple question: what if the future interface is not a grid of icons?

For years we have trained ourselves to use devices by hunting for the right app, opening it, finding the right menu, tapping the right button, then hoping we remembered where the command lives. That feels normal because we have done it for so long. But normal is not the same as permanent.

AI changes that. Not because it makes the existing interface prettier, but because it challenges whether that interface needs to be the starting point at all.

The app may become the background

I don’t think apps disappear overnight. That is too neat and too dramatic. Businesses still need systems of record. People still need Outlook, Teams, Word, Excel, SharePoint and the rest. The real shift is that the app may stop being where the user begins.

Instead of opening Outlook, finding the email thread, checking the calendar, then drafting a reply, I can see people simply asking Microsoft 365 Copilot: “What do I need to respond to before tomorrow morning, and can you draft the first three replies?”

That is not just a faster way to use Outlook. It is a different relationship with the machine.

The software is still there. The data is still in Microsoft 365. The security, permissions, retention and compliance boundaries still matter. But the user experience moves up a layer. The task becomes the centre, not the application.

That is a big change.

Mobile makes this more obvious

This shift feels especially likely on mobile devices.

A phone is powerful, but it is still a small piece of glass. The more we expect from it, the more ridiculous some workflows become. Open an app. Switch apps. Copy something. Paste it somewhere else. Tap through three screens. Accept a prompt. Go back because you missed something.

That is a lot of ceremony for a device that is usually in your hand while you are walking, travelling, waiting, or trying to get something done between other things.

Voice changes the equation. If I can pick up a phone and say, “Summarise the Teams discussion about that client issue, check whether there is anything in my inbox I need to act on, and create a Planner task for the follow-up,” then the icons become less important.

Not irrelevant. Just less central.

The interface becomes more like a conversation with context. That means the device needs to understand intent, identity, permissions and the work graph around me. This is where Microsoft 365 has an advantage, because so much of the business context already lives inside Outlook, Teams, SharePoint, OneDrive and the calendar.

The danger is sloppy delegation

There is a trap here though.

Asking AI to “do something” sounds simple, but business work is rarely simple. A useful assistant needs to know when to act, when to ask, when to show its reasoning, and when to stop. That matters even more when the interface becomes conversational.

If the AI becomes the front door to the device, then governance becomes part of the user experience. Not something hidden in the admin centre. Not something bolted on after the fact.

For MSPs and business owners, that is the real lesson. The future interface may be conversational, but the foundation still needs to be boringly practical: identity, conditional access, data classification, permissions, auditability and user training.

AI does not remove operational discipline. It exposes whether you had any.

I’m watching the starting point

I don’t think the question is whether AI replaces the operating system. The operating system will still exist. Something has to manage the device, the hardware, the identity and the applications.

The better question is whether people will feel like they are using an operating system at all.

My guess is that, over time, more people will start with the request rather than the app. They will ask, instruct, refine and approve. The screen will still matter, but it may become more of a confirmation surface than a navigation surface.

That is the shift I’m watching. Not AI as another icon on the device, but AI as the place where the work begins.

Stung by my own stupidity

If you aren’t aware, when you built or run anything new in Copilot Studio it will all be charged PAYG against Azure. To allow this you need to connect your Power Platform environment to an Azure subscription. You can find details on how to do that here:

https://blog.ciaops.com/2022/04/29/set-up-payg-for-power-platform/

Now with all that in place I built a new modern agent in Copilot Studio to answer M365 questions (called Sage) built using the new Github Copilot harness and using Claude Opus 5 as the LLM.

image

I then tested it a few times in ‘Preview’ and was happy that it was all working. I knew at this point, all that was going to cost me a few bucks because now even creation costs with the new Copilot Studio. All good so far and still in budget.

Next, I wired up a new Workflow in Copilot Studio to wait for a message to be posted into a Microsoft Teams channel, take that, post it to the newly created Sage agent, then take the reply from the agent and post it back into the same channel. Quick and easy to create. Job done, I thought.

Can you see the logic flaw yet? I certainly didn’t initially. In short, the workflow I created basically replies to every message posted into a channel. Ahem, those replies then trigger the agent to run again and post yet another message, which again triggers another message posting from the agent, and on and on. So, I had created an infinite loop.

My mistake was now running the workflow and calling the agent and posting into the Team every minute or so. I didn’t recognise my error for a few hours! Yes, hours. I estimate the loop I created with the workflow ran for about 3.5 hours in total. Ouch. When I finally realised upon checking back into the channel I immediately deleted the workflow to stop the race condition, however I knew I was going to pay for my mistake.

Fast forward a day or so when I have all the billing data available. Here’s what the results of my oversight were:

Screenshot 2026-08-21 073742

The error had cost me around AU$250. D’Oh!

All of this is always a learning experience, so now that I had understood the ‘bill shock’ amount I wanted to see what more billing information I could obtain about what had actually happened. I visited the Power Platform admin center | Licensing Copilot Studio, scrolled down to Top 5 agents and users, then selected View all agents which showed me this:

image

then when I drilled into my environments I can see:

image

and at the bottom you can see the autonomous consumption of 16,376.01 credits. If I divide that by the 3.5 hour run time I get 4,678.86 credits consumed per hour. If I then divide that by 60 to get the cost per minute I get 77.98 credits. Thus, each post to the channel in effect cost around US$0.78 which is about AU$1.20.

The detail also shows that creating the agent cost around 67.26 + 379.77 = 447.37 credit which is around US$4.50 and AU$6.95 to create.

I have now added notifications at 90% capacity like so in this admin console because they are not enabled by default:

image

I would expect, like the budget notifications from Azure, they are not immediate which makes avoiding costly mistakes harder when your error maybe racking up a few dollars per minute charges!

I accept full responsibility for my error and oversight and bill incurred, however I think there are some important learnings and observations here with the new PAYG billing for AI services. These in essence boil down to the fact that it very difficult to get a good understanding of exactly what your costs are in real time or prior. Typically, you need to wait a full 24 hours until all the billing data has been collected and by then you maybe up for thousands of dollars if you are not very careful.

Another observation is that if you make a logic error in your build you won’t find that until you look at your bill. I was lucky that I found mine after a few hours, imagine if it had run for more than 24 hours before the billing data alerted me? Ouch.

I believe this lack of immediacy an d visibility on costs is going to be a major barrier for adoption of PAYG agents in Microsoft 365, whether Cowork or the new Copilot Studio, especially in SMB.

image

Hopefully, we get to a point like we have with Github Copilot (above) where I can quickly and easily see my usage in the development environment (here Visual Studio Code). Without this type of spending certainty many business are simply not going to use what are fantastic AI tools to help their business. This risk of runaway costs is simply too great.

Another point that I want to reinforce here is that when you implement PAYG with agents you need to monitor your costs DAILY! This will be a big change for many MSPs who may occasionally go into a customers tenant to look at licensing monthly. If your customer has PAYG AI and you are responsible for managing these costs you need to keep an eye on this every single day to minimise what a single logic error could cost.

Ensure you enable all the alerting that you can when you use PAYG AI services, no matter where or whom they are from. Hopefully, doing this and my sorry tale here helps you better monitor your costs and avoid ‘AI usage bill shock’.

Your Skills Files Are Business IP

image

I keep seeing businesses get excited about building reusable prompts, agents, SOPs and skills.md files. Fair enough. That is where the real value starts to appear. Not in one clever prompt, but in documenting how the business works and making that repeatable.

But there is a quiet problem underneath it.

The better those files become, the more they stop being “documentation” and start becoming business intellectual property. A well-written skills.md file may contain how you scope jobs, respond to clients, handle exceptions, use Microsoft 365 Copilot, build proposals, or deliver a managed service consistently. That is not just a file. That is your operating model written down.

And yet, in many businesses, that content sits in a SharePoint library or Teams channel where almost everyone can read it, copy it, sync it, or forward it.

Convenient? Yes. Sensible? Not always.

The process library is now crown-jewel data

Businesses normally think about sensitive data as payroll files, contracts, financial spreadsheets and customer records. Those still matter. But AI changes the definition of what is valuable.

If your business has spent months refining reusable skills, prompts, checklists and delivery playbooks, then you have created a process asset. It explains how your business turns knowledge into outcomes. That deserves proper governance.

I am not saying every user should be locked out. The point of documenting processes is that people can use them. But there is a difference between “available to the team that needs it” and “available to anyone who inherited access from a Team created three years ago”.

That distinction matters when these files become grounding material for Copilot or custom agents. If Copilot can find the content, summarise it and reshape it quickly, then poor permissions become easier to exploit.

Copilot is not the leak. Oversharing is.

Access should match the work

The first control is boring and important: permissions.

Store these files in a dedicated SharePoint site or library. Do not scatter them across personal OneDrives, random Teams channels, email attachments and old project folders. Give the library an owner. Use Microsoft 365 groups or Entra ID security groups to control access. Review membership regularly.

The test I like is simple. If someone left tomorrow and joined a competitor, what could they still download today?

That question cuts through wishful thinking.

Some people need edit rights. Most only need read rights. Some only need access to the process area they work in. If everyone has everything, you do not have knowledge management. You have a shared filing cabinet with the front door open.

Labels and DLP are not decorations

This is where Microsoft Purview matters.

Apply sensitivity labels to the process library. A label like Confidential – Internal Process can make the handling expectation clear and drive protection such as encryption and access restrictions where appropriate.

Then add Data Loss Prevention policies around the same content. If someone tries to email a bundle of process files externally, copy them into chat with an outside party, or move them into unmanaged locations, you want friction, warning, logging, or blocking depending on the risk.

This is not about distrusting staff. It is about recognising that staff move on, mistakes happen, and valuable business knowledge should not be one drag-and-drop away from leaving the organisation.

Offboarding is too late

Many businesses only think about this when someone resigns. By then, the files may already be synced locally, copied into another tool, or forwarded elsewhere.

The right time to protect process IP is when the library is created. Classify it. Restrict it. Monitor it. Review it. Make access part of onboarding and removal part of offboarding.

If you are building AI skills for your business, treat them as assets, not notes.

The future advantage will not belong to the business with the most prompts. It will belong to the business that protects, improves and governs the way it works.

Shared Ownership Is Where Culture Becomes Real

image

I hear culture talked about as if it is something written on a wall, captured in a values statement, or mentioned during onboarding. That is the easy version. The harder version is what happens on a normal Tuesday when something is broken, unclear, duplicated, delayed, or ignored.

That is where culture shows up.

Not in the big presentation. Not in the annual planning day. In the small moments where someone decides whether to leave the problem sitting there or do something useful about it.

The warning sign is hesitation

One of the quietest culture problems in any business is when good people start waiting for permission to care.

They see a clumsy process, notice a client communication could be clearer, or hear a decision drift past without an owner, and tell themselves it probably belongs to someone more senior.

None of that looks dramatic. Everyone looks polite, busy, and professional.

But the business is paying a tax every time that happens.

The work gets slower. The standards get softer. Small issues become normal. People learn that caring too much creates extra work, so they keep their heads down. That is how ordinary cultures become fragile cultures.

Ownership has to be visible

If I want a team to lift its standard, I cannot just tell people to take responsibility. I have to make it practical.

That means making it clear that improvement is not reserved for managers. If a client onboarding checklist in SharePoint is out of date, the useful response is not to complain about it in the background. Fix it, or at least raise it clearly in the right Teams channel with enough context for someone to act.

If a meeting ends with vague actions, do not let them vanish into the air. Use Copilot in Teams to summarise the discussion, check the actions, and then make sure the next steps land somewhere visible, such as Planner or a shared work tracker.

That is not bureaucracy. That is housekeeping.

The point is not that every person can change every decision. The point is that every person can make the problem clearer, remove friction, and stop the next person tripping over the same thing.

Quiet leadership matters

The best ownership I see is often quiet. It is not the person dominating the room. It is the person who notices a gap and calmly closes it.

They ask the extra question. They document the missing step. They follow up after the meeting. They update the shared note. They make the next handover cleaner than the last one.

In an MSP or any service business, that behaviour compounds quickly. Clients feel it when internal ownership is strong. Tickets are cleaner. Handover notes make sense. Recurring issues get spotted earlier. The client does not have to re-explain the same problem three times.

That is culture in operational form.

I am not interested in a team where people only do what is printed beside their name. That might keep the lights on, but it will not build something excellent.

The better standard is this: if you are close enough to see the issue, you are close enough to help move it forward.

That does not mean being reckless or ignoring roles, approvals, or security boundaries. It means acting like the quality of the whole business matters, not just your own narrow lane.

Shared ownership is not a slogan. It is a habit. It is built in the everyday choices people make when there is no applause attached.

And if you want to know the real strength of your culture, do not just listen to what people say in the meeting. Watch what they clean up afterwards.

Care About The Work

image

I can usually tell when a team is disconnected from the work it produces.

Not because the work is terrible. Often it looks fine from the outside. The newsletter goes out. The video gets posted. The webinar happens. The support article lands in SharePoint. The client update gets sent from Outlook.

But inside the business, nobody is really paying attention.

The team does not watch the video. They do not read the newsletter. They do not know what was promised in the webinar. They do not see the questions clients are asking after the content goes live.

That is where the problem starts.

Your own team is the first audience

I think many businesses make a mistake here. They treat content, education, communication and client resources as something created by one person or one small group. Everyone else is expected to be “too busy” to engage with it.

I see it differently.

If you work in the business, you need to understand what the business is saying.

That does not mean everyone has to become a marketer. It does not mean every technician needs to write articles. It does not mean every account manager needs to appear on camera.

It means the people who serve the client should know the message the client is hearing.

If a Microsoft 365 security update goes out to clients, the service desk should know about it before the client rings. If a Copilot readiness article is published, the account manager should know the point of view before the next review meeting. If a training video explains why governance matters, the project team should have watched it before they start implementation work.

That is not bureaucracy. That is alignment.

Consumption creates better feedback

The other thing people miss is that internal consumption makes the work better.

A team that reads, watches and listens can challenge weak ideas before clients see them. They can say, “That example will confuse people.” They can say, “Clients are already asking about this.” They can say, “We need a simpler explanation for the business owner.”

That feedback is gold.

This is where Microsoft 365 can really help, but only if it is used deliberately. I like the idea of having a dedicated Teams channel where published content, draft ideas and client questions are visible. Drop the newsletter link in there. Pin the SharePoint page. Use Copilot in Teams to summarise the discussion after people have commented. Capture the useful follow-up items in Planner rather than letting them disappear into chat history.

The tool is not the culture. But the tool can make the culture easier to practise.

The important part is that everyone understands the loop.

Create something. Share it internally. Let the team react. Improve the next version. Listen to what clients say. Bring that back to the team. Repeat.

That loop builds judgement. It also builds ownership.

Make it expected, not optional

I do not have much time for the idea that “mandatory” automatically means heavy-handed.

Some things should be expected.

If the business publishes advice to clients, the team should know what that advice is. If the business takes a position on AI, security, productivity or service delivery, the team should be familiar with that position. If clients are being educated, the people supporting those clients should not be the last to know.

The standard is simple: if we produce it, we pay attention to it.

That does not need to become a long meeting or a corporate ritual. It can be a short weekly review. It can be a Teams post with three questions. It can be a Copilot-generated summary of what went out, what clients asked, and what the team noticed.

But it does need to happen.

Because care is visible. Not in a fluffy motivational sense, but in the final product. You can feel when a team has thought about the work. You can feel when people have challenged it, improved it, and connected it back to the client.

You can also feel when it was pushed out by someone working alone while everyone else walked past it.

If your own people are detached from what you create, do not be surprised when the outside world is detached as well.

The work has to matter internally first.

That is where better culture starts. That is where better feedback starts. And that is where better client outcomes start.

Add Microsoft Learn as a knowledge source to Copilot Chat

image

I need to refer to Microsoft Learn documentation a lot. Therefore, I want it included irectly as part of my data sources with Copilot Chat. To do that go to the settings in the top right hand corner as shown above.

image

Add Microsoft Learn to your sources from the Browse sources section as shown above.

That will now make Microsoft Learn a primary data source when prompting Copilot Chat.

Productivity Starts With Owning The Work

image

When someone on my team tells me they are overwhelmed, I usually do not start with the task itself. I start with where the work is captured.

Not in their head. Not spread across ten chats. Not buried in a half-read email thread. Captured somewhere they can see it, sort it, challenge it, and act on it.

That sounds basic, but I keep seeing good people come unstuck at this point. They are smart. They care. They are capable. Yet the work is scattered, and once that happens, every day becomes reactive.

The problem is not usually effort.

It is visibility.

Busy Is Not The Same As In Control

A lot of people mistake movement for productivity. They answer messages quickly. They jump into meetings. They fix whatever is currently making noise. From the outside, it can look like they are working hard.

But if you ask what matters most this week and the answer is vague, there is a management problem. Not always from above. Often it is a self-management problem.

I have learned not to treat that lightly.

If a person cannot show what they are working on, what is waiting, what is blocked, and what matters next, then they are running their day on memory and pressure. That might survive for a while, but it does not scale.

This is where Microsoft 365 can help, but only if the behaviour is already there. Planner will not make someone disciplined. Teams will not magically create priorities. Copilot will not fix a messy operating rhythm if there is no trusted place for the work to live.

The tool supports the habit.

It does not replace it.

Make The Work Visible

The best teams I see make work visible early.

That might mean capturing actions from a Teams meeting into Planner. It might mean asking Copilot in Outlook to summarise a long thread, then turning the actual next steps into tasks instead of leaving them as good intentions. It might mean keeping a shared Loop page for the current priorities so everyone can see what has changed.

None of that is fancy.

That is the point.

Productivity is not about building a complicated system that only one person understands. It is about creating enough structure so the next decision is easier. What needs doing? What can wait? What needs someone else? What should be deleted entirely?

Those questions matter far more than another app, another dashboard, or another clever prompt.

Lead The Standard Before You Demand It

If I want my team to operate with clarity, I have to model it first.

That means I need my own priorities written down. I need to show how I decide what gets attention and what does not. If everything is urgent when it reaches me, I am teaching the team that noise wins.

This is especially important with Copilot adoption. I can tell people to use Copilot all I like, but if my own workflow is chaotic, the message will not land. A better approach is to show the habit in action. Here is the meeting summary. Here are the actions. Here is what I moved into Planner. Here is what I am not doing this week.

That is how productivity becomes cultural rather than personal.

The Real Foundation

I do not see personal productivity as a soft skill.

I see it as operating discipline.

Before strategy, before automation, before AI, people need to manage their own commitments. If they cannot do that, every improvement you add sits on unstable ground.

So start small. Make the work visible. Decide what matters. Put it somewhere trusted. Review it regularly.

Then teach the team to do the same.

Because once people can manage themselves, everything else has a chance to work.

Comparing LLMs in Copilot services–Round 7-Final

image

Round 1 – https://blog.ciaops.com/2026/07/30/comparing-llms-in-copilot-services-round-1-chat/

Winner – Opus

Round 2 – https://blog.ciaops.com/2026/08/08/comparing-llms-in-copilot-services-round-2-researcher/

Winner – Critique

Round 3  – https://blog.ciaops.com/2026/08/11/comparing-llms-in-copilot-services-round-3-cowork-claude/

Winner – Opus 5

Round 4 – https://blog.ciaops.com/2026/08/12/comparing-llms-in-copilot-services-round-4-cowork-gpt/

Winner – GPT 5.6 Terra

Round 5  – https://blog.ciaops.com/2026/08/14/comparing-llms-in-copilot-services-round-5-cowork/

Winner – Opus 5

Round 6 – https://blog.ciaops.com/2026/08/16/comparing-llms-in-copilot-services-round-6/

Winner – Opus 5

I’ve been pitting different LLMs inside M365 Copilot against each other ina world cup style elimination to see which comes out on top. The process involves taking a standard prompt and running it against all options. This prompt creates a multi page document requiring deep research and is quite involved. The results are then compared against each other using SharePoint Copilot and Gemini. Conclusions are then drawn.

For the final, we have Opus 5 (Cowork) and Opus (Chat). The results are:

https://github.com/directorcia/general/blob/master/Copilot/Comparisons/20260816-Copilot-Grok-eval.md

1. Opus 5 (Cowork)

2. Opus (Chat)

Therefore, the initial over all Copilot LLM winner is a clear win for:

Opus 5 (Cowork)

The trade off is that the cost for this US$22, while the runner up’s price was included in the cost of a Microsoft 365 Copilot license.

These test have revealed a few things, in my opinion:

A. Claude Opus is the superior model

B. Opus in chat is almost as good as Opus Cowork but much cheaper

C. For most work Opus in chat is probably you best option

The challenge with these report, as with any LLM’s is they are not definitive. Another round could reveal completely different results as could the method of evaluation, however as a best effort I think it does have validity and provide some general findings that do help understand the model choices in Copilot.

For comparison, I have create a document parameters page here:

https://github.com/directorcia/general/blob/master/Copilot/Comparisons/20260816-File-paramters.md

so you can now compare all the various output document sizes, pages, etc to each other. I have also made available a copy of each model output document, without any changes to it, so you can look at each for yourself. You will find them all at:

https://github.com/directorcia/general/tree/master/Copilot/Comparisons/20260816

The idea is to wait until we see new models appear in Copilot and use the same methodology against these also when they appear. That will hopefully provide some sort of bench mark when it comes top model strength.

I hope this series of tests has been interesting and helpful to you and I’d love to hear your thoughts on the results.