You're reading The AI Directive — practical AI intelligence for UK business leaders. Subscribe here if someone forwarded this.
THE SIGNAL
Stop Reaching for the Heavy Tool First
There is a point in almost every AI conversation where someone makes it more complicated than it needs to be.
It usually starts innocently enough.
“Could we use AI to help with this?”
Reasonable question. Then, five minutes later, the room has wandered into Copilot Studio, connectors, governance, agent permissions, knowledge sources, workflow approvals, and a diagram that looks like it was assembled by committee after too much coffee.
This is very easy to do inside Microsoft 365, because the names are not exactly doing heavy lifting.
Copilot. Agent Builder. Copilot Studio.
They sound like three versions of the same thing. Small, medium and large. Starter, professional and “please call your reseller”.
That is not quite right.
The useful question is not: which one is best?
The useful question is:
What is the lightest tool that can safely do the job?
That is the bit I would put on the wall.
Standard Copilot is good when a person is working at pace across their own Microsoft 365 world: documents, meetings, chats, email, notes. It is useful for summarising, drafting, comparing, preparing and thinking. A human is very clearly still in charge.
Agent Builder sits in the middle. It is for when you want something more repeatable than “ask Copilot again”, but you are not yet building a full operational workflow. A defined assistant for a defined job. Useful, provided nobody pretends it has become a business system overnight.
Copilot Studio is the heavier thing. Not bad. Just heavier. You go there when the agent needs controlled sources, shared deployment, integrations, process logic, monitoring, approvals and proper ownership.
The mistake is reaching for the heavy thing because it sounds more serious.
I fell for this too.
When I started looking seriously at Microsoft’s AI stack, Copilot Studio looked like the obvious grown-up answer. More control. More structure. More “proper platform”. All the things that make an IT brain quietly nod along.
Then the practical disadvantages started to matter.
You have to be specific about what the agent can access. That is good from a governance point of view, but it changes the way the work feels compared with standard Copilot, where the assistant can work more naturally across your live Microsoft 365 context.
There are also data sync and source freshness constraints. Again, not a flaw exactly. Just a real operating trade-off. If you are used to a live assistant helping you work at pace, a more controlled Studio setup can feel oddly constrained.
For the job I was trying to do, the extra features did not outweigh the friction.
I needed to walk before I ran.
That was the useful lesson. Sometimes the more powerful tool is the wrong first tool.
I have seen the same pattern with plenty of technology, not just AI. A small operational problem turns into a platform conversation, and suddenly the original problem is standing in the corner wondering why everyone is talking about architecture.
Sometimes the answer really is Studio.
If an agent is near customers, suppliers, live records, finance, HR, operational decisions or anything external, you need more structure. You need boundaries. You need ownership. You need a way to know when it has gone wrong.
But if the job is “help me turn this messy meeting into a clear action note”, please do not form a steering committee.
Use the lighter tool.
This is where a lot of AI adoption gets tangled. Not because the tools are useless, but because the work has not been classified properly.
I would split it into three buckets.
Personal productivity: help me summarise, draft, compare, prepare and think. I review the output. I decide what happens next.
Team knowledge work: help a group use a common body of knowledge or a shared way of working. There is more consistency, but still a human review point.
Operational workflow: help run or coordinate a process where actions, records, decisions or external communication may be involved.
Those are not the same thing.
Treat them as the same thing and you get one of two bad outcomes.
You over-engineer simple work, and everyone quietly goes back to doing it the old way.
Or you under-govern serious work, and everyone discovers “lessons learned” as a coping mechanism after the fact.
Last week I wrote about the AI Operating Brief: the context that tells an assistant how to work with you. That is still the right starting point for a lot of personal and team use.
But once you move from “help me draft this” to “help the business run this”, the conversation changes.
Now we are talking about permissions, sources, approvals, ownership, monitoring and failure modes.
That is not being anti-AI.
That is just operations. Annoying, unglamorous, necessary. The usual.
The businesses that get value from AI will not be the ones that buy every shiny surface and hope adoption happens by osmosis.
They will be the ones that match the tool to the job.
Light where possible.
Structured where necessary.
Governed when consequences become real.
FIELD NOTES
The Decision Rule I Would Actually Use
Here is the practical version.
If the work is personal, fast-moving and reviewable, start with standard Copilot.
Good examples:
meeting summaries;
document comparison;
project update drafts;
email rewrites;
action extraction;
briefing prep.
The important phrase is reviewable. Copilot can help you get to a better draft or clearer view. It should not quietly become the decision-maker because everyone was busy.
If the task repeats and a team needs consistency, look at Agent Builder.
Good examples:
a department FAQ assistant;
a policy explainer;
a project support agent;
a proposal-drafting helper;
an onboarding assistant.
This is where the operating brief from last week becomes useful. Give the assistant the role, audience, sources, structure and boundaries. Otherwise you have not built an agent. You have built a slightly branded guessing machine.
If the work has operational consequences, consider Copilot Studio.
Good examples:
customer service triage;
supplier onboarding support;
internal request handling;
guided policy workflows;
controlled process assistants.
But do not start there just because it sounds impressive. Studio is where you go when you need the control, not when you want the slide to look more grown-up.
The line I keep coming back to is this:
Use the lightest AI surface that can safely do the job.
Light does not mean casual.
Heavy does not mean better.
It just means the design matches the risk.
And yes, that is less exciting than saying “we are building agents”.
Good. Excitement is not a delivery method.
WATCH THIS
I am collecting the practical AI build notes on the channel here:
The running theme is simple: AI gets useful when it is designed into work, not sprinkled over it like expensive seasoning.
THE SHORTLIST
1. Do not start an AI pilot by asking “which tool should we use?” Start by asking what kind of work it is: personal productivity, team knowledge work, or operational workflow.
2. A Copilot Studio agent with no named business owner is not an asset. It is a small orphan with permissions.
3. “Can it do this?” is only half the question. The better half is: should it do this, who approves it, what happens when it is wrong, and how will we know?
ASK ME ANYTHING
“Should we standardise on one Microsoft AI tool?”
— Sensible question, dangerous answer
I would standardise the decision process, not the tool.
There will be work where standard Copilot is enough. There will be work where a team agent is the cleanest option. There will be work where Copilot Studio is justified because the process has consequences.
Forcing everything into one bucket usually creates one of two problems.
Either you overcomplicate small work, and people stop using it.
Or you under-govern serious work, and risk management arrives late wearing a disappointed expression.
Neither is a strategy.
ONE THING
Use the lightest AI surface that can safely do the job. Anything heavier needs a reason. Anything lighter needs a boundary.
FROM THE EDITOR
If you are leading AI adoption, make tool choice boring.
Write a one-page decision guide. Put examples on it. Agree who owns each category. Give managers a simple way to say: this is personal productivity, this is team knowledge work, this is operational and needs governance.
That will do more than another inspirational AI town hall.
Admittedly, the town hall may have biscuits.
Next week: why your AI pilot probably does not need more training. It needs a decision.
See you Tuesday.
— Toby
🛠️ TOOLS I USE & RECOMMEND
These are tools I use personally. Affiliate links marked — I earn a small commission if you sign up, at no extra cost to you.
ElevenLabs — AI voice generation. I use this for scripted narration and YouTube production. (affiliate)
HeyGen — AI video avatars. I use this for structured video content and repeatable production. (affiliate)
beehiiv — The platform this newsletter runs on. If you're starting a serious newsletter, this is the stack I'd use again. (affiliate)
Some links in this issue are affiliate links. I only recommend tools I actually use.