Finding Where AI Belongs in a Business Process
Deterministic Automation, Human Authority, Knowledge, Transactions and Generative Reasoning
The previous article established a fundamental principle for modern Power Platform architecture:
Process before platform.
Before opening Power Automate, Power Apps or Microsoft Copilot Studio, we should understand the business process, discover its AS-IS state, identify problems, model responsibilities, design a TO-BE process and determine what work actually needs to occur.
That leads naturally to a more difficult question.
Once the process has been redesigned, which activities should use artificial intelligence?
The answer cannot simply be “the activities that Copilot Studio can perform.”
Technical capability and architectural responsibility are different things.
A Large Language Model can analyze text, classify information, generate recommendations and participate in selecting Tools. An Agent can potentially invoke an API, execute a Flow or interact with enterprise systems. None of this automatically means that the Agent should be responsible for every decision or operation it can technically perform.
The correct question is therefore not:
Can AI do this?
It is:
Should AI be responsible for doing this?
This distinction becomes one of the foundations of enterprise Agent architecture.
Some activities are deterministic. Some represent human authority. Some retrieve trusted information. Some modify authoritative business systems. Some genuinely require interpretation of ambiguous or unstructured information.
Treating all of them as “AI tasks” creates fragile architecture.
A better approach is to classify the work first and introduce generative intelligence only where its characteristics provide meaningful value.
This article develops that classification and connects it directly to Microsoft Power Platform, SharePoint, Power Automate, enterprise systems and Microsoft Copilot Studio.
1. The Process Is Larger Than the Agent
One of the easiest mistakes when beginning with Copilot Studio is to see the Agent as the application.
A user talks to the Agent. The Agent understands the request. It has Knowledge. It can call Tools. It can execute workflows. It can communicate results.
From the conversational interface, it can appear that the Agent is responsible for everything.
But the business process is larger than the conversational experience.
Consider a purchase request.
An employee might tell an Agent:
“I need to purchase three new engineering workstations for the design team.”
Several different activities may follow.
The employee’s statement needs to be interpreted. Corporate procurement policies may need to be retrieved. Required information might be missing. A purchasing category may need to be identified. A financial threshold may determine which approval path is required. A manager may need to authorize the expenditure. Finally, an ERP transaction may need to be created.
Although these activities appear inside one conversation, they are fundamentally different types of work.
The Agent may participate in several of them, but it should not automatically own all of them.
This leads to an important architectural principle:
The Agent is a participant in the business process, not necessarily the business process itself.
Section summary
| Process responsibility | Possible owner |
|---|---|
| Understand user intent | Agent |
| Retrieve procurement policy | Knowledge/Retrieval |
| Identify missing information | Agent/application logic |
| Evaluate fixed financial threshold | Deterministic rule |
| Approve expenditure | Authorized human |
| Execute workflow | Power Automate |
| Create purchase transaction | ERP |
| Communicate result | Agent |
2. The First Classification: Deterministic or Probabilistic?
The first distinction we should make is between deterministic and probabilistic computation.
Traditional business applications are primarily deterministic.
If a business rule states that purchases above $10,000 require CFO approval, the expected result should not depend on how a language model interprets the situation.
For the same valid input and the same business rule, we expect the same result.
Conceptually:
Amount = 12,500
combined with:
If Amount > 10,000 → CFO Approval
should always produce:
CFO Approval Required
This is an excellent task for conventional application logic, a Power Automate condition, a business rule or another deterministic execution mechanism.
Now consider a different requirement:
“Read the employee’s justification and summarize why this purchase is needed.”
There may be many valid summaries.
The input is unstructured. Language is ambiguous. There is no single sequence of deterministic comparisons that naturally captures the task.
This is precisely where an LLM becomes useful.
Generative AI therefore introduces a different computational model into enterprise architecture.
Traditional automation generally asks:
What rule should execute?
Generative AI can address:
What does this information appear to mean?
These capabilities complement each other.
They should not be confused.
Section summary
| Characteristic | Deterministic | Generative |
|---|---|---|
| Same input should produce same decision | Usually yes | Not necessarily |
| Explicit rules | Strong fit | Usually unnecessary |
| Unstructured language | Limited | Strong fit |
| Mathematical comparison | Strong fit | Poor reason to use AI |
| Interpretation | Limited | Strong fit |
| Summarization | Difficult traditionally | Strong fit |
| Auditability | High | Requires additional controls |
| Typical technology | Code / Flow / business rule | LLM / Agent |
3. Not Every Decision Is a Reasoning Problem
The word decision can be misleading.
We frequently say that a system “decides” something when it evaluates a rule.
For example:
If the request exceeds $10,000, route it to the CFO.
Technically, software is making a routing decision.
But there is no judgment involved.
The rule already contains the decision made by the organization.
The software is merely evaluating it.
Compare this with:
Determine whether the business justification appears sufficiently detailed.
Now interpretation is involved.
The information may be incomplete, ambiguous or expressed in many different ways.
An LLM might help analyze it.
But even here we should distinguish analysis from authority.
The Agent might say:
“The justification does not explain why the existing workstations cannot meet the engineering requirement.”
That can be useful.
It does not necessarily mean the Agent should reject the purchase.
The architecture could instead be:
Agent analyzes → Human decides
This is one of the most important patterns in enterprise AI.
Section summary
| Operation | What is actually happening? | Appropriate mechanism |
|---|---|---|
| Amount > 10,000 | Rule evaluation | Deterministic logic |
| Select approval path | Routing | Workflow |
| Analyze justification | Semantic interpretation | LLM |
| Recommend additional information | Generative assistance | Agent |
| Approve expenditure | Exercise of authority | Human |
| Record approval | Transaction | Workflow/system |
4. Human Authority Is Its Own Architectural Category
Not every activity should be classified as either automation or AI.
Some activities exist because an organization has assigned authority to a person or role.
Approving a significant purchase is a good example.
The manager may consider budget, priorities, team requirements, current organizational conditions and responsibilities that are not completely represented in the application.
More importantly, the manager is accountable for the decision.
That accountability matters.
An Agent may prepare the information needed for the decision. It may retrieve policy, summarize the request, identify inconsistencies and explain possible implications.
But assistance and authorization are different responsibilities.
A useful pattern is therefore:
AI prepares → Human authorizes → System executes
This can produce a much stronger process than either extreme.
Without AI, the manager may spend unnecessary time collecting and interpreting information.
Without human authorization, the organization may delegate too much authority to a probabilistic system.
Human-in-the-Loop architecture allows us to combine the strengths of both.
Section summary
| Capability | Agent | Human |
|---|---|---|
| Summarize request | Strong | Possible |
| Retrieve relevant information | Strong | Possible |
| Detect missing context | Strong | Strong |
| Suggest next action | Strong | Strong |
| Exercise organizational authority | Limited role | Strong |
| Accept accountability | No | Yes |
| Approve sensitive transaction | Support | Primary authority |
5. Knowledge Is Different from Reasoning
Another important category is Knowledge.
Suppose the employee asks:
“What is the maximum amount I can purchase without CFO approval?”
This is not primarily a workflow problem.
It is an information-retrieval problem.
If the organization’s procurement policy exists in SharePoint, the Agent can retrieve relevant information and use it as grounding for the response.
Conceptually:
User Question
↓
Agent
↓
Knowledge Retrieval
↓
SharePoint
↓
Relevant Policy Content
↓
Grounding
↓
Generated Answer
This distinction is fundamental because an LLM may already possess general knowledge about purchasing processes.
But general knowledge about how companies commonly handle purchasing is not the same thing as the organization’s approved procurement policy.
In our earlier Copilot Studio experiments, we demonstrated precisely this distinction. An Agent could initially answer beyond the contents of its configured Knowledge, while restrictive Instructions changed its behavior so that it stopped extrapolating when the available Knowledge was insufficient.
For enterprise architecture, this leads to an important rule:
When the business question has an authoritative answer, retrieve that answer from an authoritative source rather than asking the model to invent the most plausible answer.
Section summary
| Requirement | Primary capability |
|---|---|
| Find corporate policy | Knowledge |
| Identify relevant content | Retrieval |
| Use retrieved content as evidence | Grounding |
| Explain policy naturally | LLM |
| Handle missing policy information | Instructions / controlled behavior |
| Change corporate policy | Not a Knowledge operation |
6. Knowledge and Action Must Remain Separate
This distinction becomes even clearer when we compare two user requests.
The first is:
“What is our purchase approval policy?”
The second is:
“Create my purchase request.”
They may occur consecutively in the same conversation, but architecturally they belong to different categories.
The first requires information.
The second requires an operation.
Knowledge answers:
What does the Agent know?
Action answers:
What can the Agent do?
This separation is one of the most useful mental models when designing Copilot Studio solutions.
A SharePoint document describing procurement policy may be an excellent Knowledge Source.
Creating a purchase request requires a Tool, Flow, Connector, API or another operational capability.
Connecting SharePoint as Knowledge should not be confused with giving the Agent permission to modify SharePoint.
Similarly, giving an Agent a Tool that creates a SharePoint item does not make that Tool a Knowledge Source.
The architectures are different because the security implications are different.
Section summary
| Dimension | Knowledge | Action |
|---|---|---|
| Purpose | Provide information | Perform operation |
| Typical direction | Read/retrieve | Execute/change |
| Example | Read procurement policy | Create request |
| Copilot concept | Knowledge Source | Tool/Action |
| Typical risk | Incorrect disclosure/grounding | Unauthorized operation |
| Security question | What can the user retrieve? | Who executes the operation? |
7. Transactions Belong to Authoritative Systems
Another category must be separated from generative reasoning: the enterprise transaction.
Suppose a purchase has been approved and must now become a purchase requisition in SAP, Dynamics 365 or another ERP.
The ERP is usually the authoritative transactional system.
The Agent may initiate the operation through an approved integration mechanism, but the Agent should not become an alternative source of truth.
Conceptually:
Agent
↓
Tool
↓
Power Automate / Connector / API
↓
ERP
↓
Transaction ID
↓
Agent
↓
User
The Agent provides the conversational layer.
The integration layer performs the technical operation.
The ERP maintains transactional authority.
This separation creates cleaner responsibility boundaries and makes failures easier to reason about.
If the ERP rejects the transaction, the Agent should not simply invent a successful result. It should receive the structured failure and communicate it appropriately.
This is another reason why enterprise Agents must be designed as participants in systems architecture rather than as magical replacements for existing systems.
Section summary
| Responsibility | Component |
|---|---|
| Understand request | Agent |
| Collect missing information | Agent / structured interaction |
| Apply deterministic validation | Flow/application |
| Authenticate integration | Connector/API identity |
| Execute transaction | ERP/API |
| Store authoritative state | ERP |
| Interpret result | Agent |
| Communicate outcome | Agent |
8. The Five Fundamental Categories of Business Work
We can now consolidate the classification.
A modern business process frequently contains at least five fundamentally different kinds of work.
The first is deterministic work, where explicit rules define the expected result.
The second is human-authority work, where organizational responsibility and accountability matter.
The third is Knowledge work, where trusted information must be retrieved.
The fourth is transactional work, where an authoritative system must change state.
The fifth is generative work, where interpretation of language, documents or ambiguous information creates value.
Integration forms the connective tissue between these categories.
This classification gives us a practical framework for evaluating every activity in a BPMN TO-BE process.
Section summary
| Category | Core question | Typical owner |
|---|---|---|
| Deterministic | What rule applies? | Code / Power Automate |
| Human Authority | Who is accountable for the decision? | Person / role |
| Knowledge | What does the approved information say? | SharePoint / Knowledge |
| Transactional | Which authoritative state must change? | ERP / Dataverse / business system |
| Generative | What does this unstructured information mean? | LLM / Agent |
| Integration | How do capabilities communicate? | Connector / API / Flow |
This table becomes one of the central architectural tools of the entire series.
9. Applying the Classification to BPMN
The real value appears when this classification is applied to the TO-BE process created in the previous article.
Imagine the following purchasing process:
Employee submits requirement
↓
Validate required information
↓
Analyze business justification
↓
Retrieve procurement policy
↓
Determine approval level
↓
Manager reviews request
↓
Create ERP requisition
↓
Notify employee
Instead of immediately assigning Microsoft products, we first classify the activities.
“Validate required information” is primarily deterministic.
“Analyze business justification” is generative.
“Retrieve procurement policy” is Knowledge-oriented.
“Determine approval level” may be deterministic if explicit thresholds exist.
“Manager reviews request” represents human authority.
“Create ERP requisition” is transactional.
“Notify employee” is deterministic communication.
Now the architecture begins to emerge naturally.
Section summary
| Process activity | Classification | Likely implementation |
|---|---|---|
| Collect requirement | Conversational/structured | Agent / Power Apps |
| Validate required fields | Deterministic | Flow/application |
| Analyze justification | Generative | Copilot Studio |
| Retrieve policy | Knowledge | SharePoint + Retrieval |
| Determine approval level | Deterministic | Power Automate |
| Review purchase | Human authority | Approval |
| Create requisition | Transactional | ERP/API |
| Notify requester | Deterministic | Power Automate/Agent |
Notice what happened.
We did not ask:
“Where can we put Copilot?”
The process itself revealed where generative intelligence could provide value.
10. Generative AI Is Most Valuable at Semantic Boundaries
This classification reveals a deeper pattern.
Generative AI becomes particularly valuable at semantic boundaries.
A semantic boundary exists where information must be interpreted rather than merely transported or compared.
A user describes a requirement in natural language.
A document must be summarized.
Several pieces of information need to be compared conceptually.
An ambiguous request needs classification.
A technical document must be explained to a nontechnical user.
These are places where traditional deterministic software frequently requires substantial custom logic or rigid forms.
An LLM can provide flexibility.
By contrast, once the information has been transformed into a structured fact such as:
Amount = 12,500
there is usually little value in asking the LLM whether the amount exceeds 10,000.
This suggests a powerful design principle:
Use AI to cross semantic boundaries; use deterministic systems to enforce deterministic rules.
Section summary
| Situation | Semantic uncertainty | AI value |
|---|---|---|
12500 > 10000 | None | Very low |
| Validate required field | Low | Low |
| Interpret free-text requirement | High | High |
| Summarize document | High | High |
| Retrieve exact transaction ID | Low | Low |
| Explain transaction result | Medium | High |
| Decide fixed approval threshold | None | Very low |
| Identify intent from conversation | High | High |
11. The LLM Should Not Become the Business Rules Engine
This deserves explicit attention.
It is technically possible to write an Instruction such as:
“Purchases above $10,000 must be approved by the CFO.”
The Agent may interpret this correctly.
But should that be the authoritative implementation of the business rule?
Usually not.
Important deterministic business rules should live in mechanisms designed to represent and enforce deterministic logic.
Otherwise, the organization risks placing operational policy inside natural-language prompts that may be harder to test, audit, version and enforce consistently.
Instructions should guide Agent behavior.
They should not automatically become substitutes for every business rules engine.
A healthier architecture is:
Agent understands request
↓
Structured parameters
↓
Deterministic rule
↓
Result
↓
Agent explains result
This gives each computational model the responsibility it handles best.
Section summary
| Concern | Instructions | Deterministic logic |
|---|---|---|
| Tone | Excellent | Not relevant |
| Scope | Excellent | Limited |
| Agent behavior | Excellent | Limited |
| Fixed financial threshold | Possible but weak architecture | Strong |
| Mandatory validation | Possible but risky | Strong |
| Auditable routing | Weak | Strong |
| Natural-language interpretation | Strong | Weak |
12. The Agent Should Not Become the Security Model Either
The same principle applies to authorization.
An Instruction such as:
“Only managers should access confidential purchasing information.”
is useful behavioral guidance.
It is not an adequate security boundary.
Security must be enforced by the underlying identity, authorization and data-access architecture.
If SharePoint contains restricted documents, access should respect appropriate SharePoint and Microsoft 365 permissions.
If an API performs sensitive operations, authentication and authorization should constrain what can actually be executed.
If a Tool runs using a connection, we must understand whose identity and permissions that connection represents.
This produces another fundamental principle:
Instructions can guide behavior. They should not replace authorization.
Section summary
| Requirement | Appropriate control |
|---|---|
| Agent should avoid discussing a subject | Instructions |
| User must not retrieve a document | Authorization/permissions |
| User cannot execute an API operation | API/identity authorization |
| Sensitive operation requires approval | Workflow + human authority |
| Agent should explain access failure | Instructions/response design |
Security remains part of the architecture beneath the Agent.
13. AI Can Recommend Without Being Authorized to Execute
Another useful pattern separates recommendation from execution.
Suppose an Agent analyzes a purchase request and concludes:
“Based on the information provided, this appears to be a capital expenditure request and may require Finance review.”
That recommendation can be valuable.
But the next step does not necessarily need to be:
Agent → Execute Finance Process
The system might instead present the recommendation to the user or an authorized employee.
This creates graduated levels of Agent authority.
An Agent can retrieve.
It can explain.
It can analyze.
It can recommend.
It can prepare an operation.
It can request confirmation.
It can invoke an operation.
And, in more advanced scenarios, it may operate autonomously.
These are not equivalent levels of risk.
Section summary
| Level | Agent responsibility | Operational risk |
|---|---|---|
| 1 | Retrieve | Low |
| 2 | Explain | Low |
| 3 | Analyze | Moderate |
| 4 | Recommend | Moderate |
| 5 | Prepare action | Moderate |
| 6 | Execute after confirmation | Higher |
| 7 | Execute through controlled workflow | Higher |
| 8 | Autonomous execution | Highest |
Agent autonomy should therefore be a deliberate architectural decision, not merely a feature that is enabled because it exists.
14. Designing the Complete Architecture
We can now combine the classifications into a coherent enterprise architecture.
Consider again our purchasing scenario.
The employee begins with an unstructured need.
Copilot Studio provides the conversational interface and interprets the request.
SharePoint provides approved procurement Knowledge.
Retrieval identifies relevant policy content.
The LLM uses that information to help the employee understand requirements and structure the request.
Power Automate evaluates deterministic business rules.
A manager provides authorization.
An integration mechanism calls the ERP.
The ERP creates the authoritative transaction.
The result returns through the integration layer.
The Agent communicates the outcome naturally.
Conceptually:
Employee
↓
Copilot Studio
Conversation + Interpretation
↓
SharePoint Knowledge
Retrieval + Grounding
↓
Structured Request
↓
Power Automate
Deterministic Rules
↓
Human Approval
Authority
↓
ERP API
Transaction
↓
ERP
System of Record
↓
Structured Result
↓
Copilot Studio
Interpretation + Communication
↓
Employee
This architecture is powerful precisely because AI is not everywhere.
Each component has a defined responsibility.
15. From AI-First to Responsibility-First Architecture
A useful way to summarize the architectural evolution across these articles is to compare two mindsets.
The first is technology-first:
We have Copilot Studio → Where can we use an Agent?
The second is responsibility-first:
We have a business process → What responsibilities exist → Which computational model fits each responsibility → Which technology implements it?
The second approach produces better boundaries.
It also makes alternatives visible.
Perhaps a process does not require an Agent at all.
Perhaps SharePoint and Power Automate solve the problem more predictably and at lower operational complexity.
That is not a failure to use AI.
It is good architecture.
Section summary
| Technology-first | Responsibility-first |
|---|---|
| Start with product | Start with business outcome |
| Search for AI use cases | Identify process responsibilities |
| Agent becomes central | Process remains central |
| Capabilities drive design | Requirements drive capabilities |
| AI tends to spread | AI is selectively introduced |
| “Can AI do it?” | “Should AI do it?” |
16. A Practical Decision Framework
When examining any BPMN activity, we can now apply a sequence of questions.
First, determine whether the result can be expressed through explicit rules.
If yes, deterministic automation is probably appropriate.
If not, determine whether the activity requires interpretation of language, documents or ambiguous information.
If yes, generative AI may provide value.
Then ask whether the activity changes authoritative business state.
If it does, identify the System of Record and the controlled integration mechanism.
Next, determine whether the activity represents organizational authority.
If it does, identify the accountable person or role.
Finally, determine whether trusted organizational information is required.
If it is, identify the authoritative Knowledge Source.
The Agent emerges only after these responsibilities are understood.
Section summary
| Question | Architectural implication |
|---|---|
| Can explicit rules determine the result? | Deterministic automation |
| Does it require semantic interpretation? | Consider LLM/Agent |
| Does it require trusted information? | Knowledge/Retrieval |
| Does it modify authoritative state? | Transactional system |
| Does it require organizational authority? | Human |
| Does it cross system boundaries? | Integration |
| Does it merely communicate results? | Agent may provide conversational layer |
17. The Architectural Principle
The three articles now form a progression.
The first established:
Low-Code does not mean Low-Knowledge.
The second established:
Process before platform.
This third article adds:
Responsibility before intelligence.
Together they produce a much stronger methodology:
Understand the Business
↓
Discover the Process
↓
Model AS-IS
↓
Measure and Improve
↓
Design TO-BE
↓
Classify Responsibilities
↓
Separate Deterministic, Human, Knowledge, Transactional and Generative Work
↓
Identify Where Intelligence Adds Value
↓
Select Technology
↓
Implement
This is a fundamentally different approach from beginning with Copilot Studio and attempting to expand the Agent until it controls the entire process.
Conclusion
The most important question in enterprise AI architecture is not whether artificial intelligence can perform an activity.
Modern models can perform an increasingly broad range of tasks.
The more important question is whether the characteristics of that activity justify delegating responsibility to a generative system.
Deterministic rules should generally remain deterministic.
Authoritative transactions should remain controlled by authoritative systems.
Organizational authority should remain attached to accountable actors.
Corporate facts should be retrieved from trusted Knowledge.
Security should be enforced by identity and authorization mechanisms.
Generative AI should be introduced where interpretation, language, ambiguity and semantic reasoning create meaningful value.
This produces an architecture in which the Agent is neither a chatbot isolated from enterprise operations nor an artificial replacement for every existing system.
It becomes something much more useful:
An intelligent participant operating inside a deliberately designed business process.
That distinction also changes how we think about Microsoft Copilot Studio.
Copilot Studio is not simply a faster mechanism for building conversational applications. It provides a reasoning and interaction layer that can participate alongside SharePoint, Power Automate, Dataverse, APIs, ERP systems and human actors.
But its value depends on the quality of the boundaries we design around it.
The objective should therefore never be to maximize the amount of AI inside the process.
The objective is to place intelligence precisely where intelligence improves the process.
And this gives us the next logical step in the series.
Once we know where AI belongs, we can begin translating the business architecture into Microsoft technology:
BPMN → SharePoint → Power Apps → Power Automate → Copilot Studio → Dataverse → APIs → ERP
The next article can therefore address:
From BPMN to Power Platform Architecture — Translating a Business Process into SharePoint, Power Automate, Copilot Studio and Enterprise Systems.
