Start with the process. Then apply the right AI.

TL;DR

AI projects often start with the wrong question: Which tool should we use?

A better approach is to first understand the process, the business outcome, the knowledge involved and where human judgement still matters.

From there, the right solution may be:

• an AI agent;
• workflow automation;
• better knowledge architecture;
• Microsoft 365 Copilot;
• or sometimes no AI at all.

The goal should not be to maximise the amount of AI in a solution. It should be to improve the process in the simplest, most appropriate way.

Start with the process. Then apply the right AI.

One of the easiest mistakes to make with AI is to start with the technology. Should we deploy Microsoft 365 Copilot? Should we build an agent in Copilot Studio? Could Power Automate handle it?

Those are reasonable questions. But they are usually being asked too early. The better starting point is much simpler:

What are we actually trying to improve?

That question changes the conversation. Instead of searching for somewhere to use AI, you start examining the work itself: the process, the people involved, the information they need, the repetitive steps slowing them down and the points where human judgement still matters.

Only then should technology enter the discussion. That is what I mean when I say:

Start with the process. Then apply the right AI.

AI has created understandable pressure inside organisations. Executives want a strategy. Employees want access to new tools. Technology teams are being asked what they are doing with AI.

That can quickly turn into technology looking for a problem. An organisation buys licences and then asks where they can be used.

A team decides it needs an AI agent before understanding the process the agent is supposed to improve. A chatbot is built because the requirement sounds conversational, when the underlying problem is actually poor knowledge management.

Or AI is introduced into a workflow that could have been solved more simply with automation. The technology may work perfectly while the business problem remains largely unchanged.

That is not necessarily an AI failure. It is often a problem-definition failure.

Before choosing an AI technology, I want to understand a few basic things. What outcome are we trying to improve? What happens today? Where does work slow down?

Which activities are repetitive? Which require judgement? What information does the process depend on? And where does a human still need to remain accountable?

These questions start revealing what kind of solution you actually need. Some activities are highly predictable.

A document arrives. It needs to be renamed according to a convention, given metadata and moved into the correct SharePoint location. That may primarily be an automation problem.

Other activities involve language, ambiguity and synthesis. A Business Analyst receives a lengthy workshop transcript and needs to identify requirements, unanswered questions, user stories and acceptance criteria.

That is a much stronger candidate for an AI agent assisting knowledge work. Different problems require different tools.

A solution I worked on was inspired by a very ordinary operational problem. A medical practice was spending significant time opening incoming documents, identifying them, renaming them and filing them correctly. It would have been easy to call this an “AI document-management opportunity”. But much of the initial problem was predictable.

Known document types. Known destinations. Known metadata. Known business rules. That meant a large part of the value could be delivered using capabilities such as Power Automate and SharePoint. AI becomes more useful later when documents are genuinely ambiguous or unstructured. That distinction matters.

The objective should not be to maximise the amount of AI in a solution. The objective should be to improve the process.

Now consider a different problem. A Business Analyst attends a two-hour workshop and then spends significant time afterwards reviewing the transcript, extracting requirements, identifying gaps, drafting user stories and structuring the output.

The work is language-heavy. It requires interpretation. It benefits from organisational context. And there is a meaningful first-pass workload that an AI agent can assist with.

That makes it a much stronger AI use case. But even here, the goal should not be to remove the Business Analyst.

I use a simple 10 / 80 / 10 principle. The human establishes the context and direction. The agent performs much of the first-pass drafting. The human reviews, challenges, corrects and owns the final result.

The exact percentages are not important. The principle is:

Use AI to reduce the effort required to produce the work without transferring accountability away from the person responsible for the outcome.

There is another reason to start with the process rather than the tool. AI agents depend on the information available to them. If policies are duplicated, obsolete, poorly classified or scattered across uncontrolled locations, adding an agent does not make those problems disappear. It may simply expose them faster.

For organisations already invested in Microsoft 365, this is where SharePoint becomes especially interesting. With the right structure, metadata, permissions, ownership and lifecycle controls, SharePoint can become part of the governed knowledge foundation that AI agents depend on.

Before asking how clever an agent can become, ask:

What information will it rely on, and should we trust that information?

The same applies to governance. It should not be something that happens just before an AI solution goes live. Questions about data, permissions, accountability, human approval and acceptable outputs affect the design itself.

Where is human approval required? What information may the solution use? Who owns its outputs? What happens when confidence is low?

How will we evaluate whether it is performing acceptably? These are not simply compliance questions. They are process and architecture questions.

Once the opportunity is understood, I favour a focused prototype before a large rollout. A good prototype should test more than whether the technology works. It should test whether the process improves.

Can users incorporate it naturally into their work? Is the underlying knowledge good enough? Are outputs reliable enough? Where is human review still required?

Does the solution genuinely save effort or improve quality? A prototype allows the organisation to learn before committing to scale.

Before deciding whether you need Copilot, an agent, automation or something else, ask: What business outcome are we trying to improve? What does the current process actually look like? Which parts are repetitive, which require judgement and which depend on trusted knowledge?

What information would the solution rely on? Where must a human remain responsible? How will we know the change has worked?

Only then should the technology decision begin. Because by that point, the question is no longer:

“Where can we use AI?”

It becomes:

“What is the most appropriate way to improve this process?”

That is a much more valuable question. Sometimes the answer will be an AI agent. Sometimes it will be automation. Sometimes it will be better knowledge architecture. Sometimes Copilot may already be enough.

And sometimes the right answer is to leave the process alone. The discipline is not knowing how to put AI everywhere. It is knowing where AI genuinely earns its place.

That is the approach behind BrightPrompt AI:

Start with the process. Then apply the right AI.