Not every broken workflow needs an AI agent. A practical look at when AI adds real value, when simpler software is enough, and why the business problem should determine the architecture.
AI agents have become one of the most attractive ideas in software.
Give an AI access to tools, company knowledge, and a goal. Let it reason about what needs to happen, choose the right actions, and complete the work with minimal human involvement.
For some problems, that is genuinely useful.
But when a business says, “We need an AI agent,” there is a question worth asking first.
What problem are we actually trying to solve?
The answer often reveals that the company does not have an AI problem.
It has a systems problem.
Start With the Work, Not the Technology
Imagine a company where employees receive customer requests through email.
Someone reads each request, copies information into a spreadsheet, searches through several folders for related documents, messages another employee for confirmation, updates the spreadsheet, and eventually replies to the customer.
It is slow and repetitive.
An AI agent sounds like an obvious solution.
It could monitor the inbox, understand the request, search the documents, contact the appropriate employee, update the records, and prepare the response.
Technically, that is possible.
But look at the workflow again.
Why are customer records stored in a spreadsheet?
Why are documents spread across several folders?
Why does an employee need to message another person every time?
Why does information have to be copied manually between systems?
The agent may automate the workflow without addressing why the workflow became inefficient in the first place.
Sometimes the better solution is much less exciting.
Build one system that captures the request, stores the relevant information, connects the documents, and gives employees a clear process for handling it.
No autonomous agent required.
A Bad Process Does Not Become Good Because AI Runs It
Software has always had this problem.
Organizations accumulate processes over time. A spreadsheet solves an immediate problem. Someone introduces another spreadsheet. Email becomes part of the workflow. Documents appear in shared folders. Important knowledge stays in someone’s head.
Eventually, the organization has a process that technically works but requires people to constantly move information between disconnected places.
AI can automate parts of that process.
But automation and improvement are not the same thing.
Suppose an employee spends ten minutes copying information from one system into another.
We could build an AI agent that reads the first system, interprets the information, and enters it into the second.
Or we could ask why the systems cannot exchange the information directly.
If the transformation follows predictable rules, a normal integration may be cheaper, faster, easier to test, and more reliable.
The AI agent solves the visible task.
Better system design may remove the task entirely.
Automating unnecessary work still leaves you with unnecessary work.
There Is a Ladder Before You Reach an Agent
When evaluating a workflow, it helps to avoid jumping directly from manual work to autonomous AI.
There are several levels of intervention.
Each level introduces different capabilities and different costs.
A better workflow may remove unnecessary steps without requiring new technology.
Traditional software can centralize information and enforce a consistent process.
Deterministic automation can connect systems and execute predictable rules.
AI augmentation becomes useful when the work involves language, interpretation, retrieval, classification, or other tasks that are difficult to express as fixed rules.
An AI agent becomes interesting when the system needs to choose between actions, use multiple tools, respond to changing situations, and determine intermediate steps toward a goal.
The important point is not that one level is better than another.
It is that complexity should enter only when the problem requires it.
Predictable Work Usually Wants Predictable Software
Consider a simple approval workflow.
A request arrives.
If the amount is below a threshold and the requester meets certain conditions, it goes to one person. Otherwise, it goes to another.
You could give this problem to an LLM.
But there is little reason to.
The rules are known. The inputs are structured. The expected behaviour is deterministic.
Normal application logic handles this extremely well.
This system is easy to test.
Given the same input, it should produce the same result. If something goes wrong, developers can trace exactly which condition produced the decision.
Introducing an AI agent would add uncertainty without adding much capability.
This leads to a useful principle:
If you can clearly describe the decision as stable rules, start with normal software.
AI becomes more interesting when those rules stop being sufficient.
AI Earns Its Place When Interpretation Becomes the Work
Now consider a different problem.
A company receives hundreds of documents written by different organizations in different formats. Employees need to determine which documents matter, identify important changes, compare them against existing information, and decide what deserves attention.
Writing deterministic rules for every possible document becomes difficult.
The problem contains ambiguity.
That is where AI starts earning its place.
A model can help classify documents, extract information, retrieve related material, summarize changes, or recommend what someone should inspect next.
The architecture might look like this:
This is already an AI system.
It still does not necessarily need an agent.
The model has a focused responsibility inside a larger workflow.
That distinction matters because adding AI and adding agency are two different architectural decisions.
An Agent Is Useful When the Path Cannot Be Fully Predetermined
A traditional application follows paths developers have explicitly designed.
An agent is useful when determining the path is itself part of the problem.
Suppose a system receives a request and may need to:
search internal knowledge;
inspect several documents;
query an external service;
compare conflicting information;
request additional context;
choose another tool based on what it discovers;
recommend or perform an action.
The sequence cannot always be known beforehand.
One request might require two steps.
Another might require six.
The result of one operation determines what the system should do next.
Now agency provides something useful.
The system is not merely generating text. It is deciding how to navigate a problem.
But that flexibility has a cost.
Every Layer of Intelligence Creates New Failure Modes
Traditional software can fail.
AI systems can fail in additional ways.
Agents introduce even more possibilities.
A model may misunderstand the request.
It may retrieve weak evidence.
It may choose the wrong tool.
It may use the correct tool with incorrect parameters.
It may interpret the result incorrectly.
It may repeat an action.
It may decide that a task is complete when it is not.
And if the agent can perform real actions, those errors can move beyond a bad answer and become changes to real systems.
This is why an architecture such as:
should make us uncomfortable for consequential workflows.
The more authority the agent receives, the more engineering needs to exist around it.
That can include validation, permission boundaries, tool restrictions, evidence tracking, structured outputs, retries, duplicate detection, human approval, execution records, and recovery mechanisms.
At some point, the surrounding infrastructure may become more complicated than the agent itself.
That is not necessarily wrong.
It simply means the business problem needs to justify that complexity.
AI Should Not Become the Business Logic
There is another architectural trap worth avoiding.
Suppose a company has an important rule:
Transactions above a certain amount require manager approval.
That rule should probably exist as explicit application logic.
It should not depend on whether a language model remembers the policy from a prompt.
The same applies to permissions, financial constraints, security boundaries, mandatory approvals, and other deterministic business rules.
AI can operate inside those boundaries.
It should not silently replace them.
The application defines what is allowed.
The AI handles the uncertainty within those limits.
This separation makes the system easier to understand and gives developers somewhere deterministic to enforce important constraints.
Sometimes the Best AI Product Barely Looks Like AI
There is a tendency to make AI visible.
Chat interfaces appear everywhere. Products advertise agents, copilots, assistants, and autonomous workflows.
But users usually care much more about the outcome.
An employee who previously spent twenty minutes finding information may now receive the relevant material immediately.
A business that manually reviewed hundreds of documents may now have the important ones prioritized automatically.
A team that repeatedly copied information between systems may find that the information simply appears where it belongs.
Whether an agent was involved is an implementation detail.
Sometimes AI should be a conversation.
Sometimes it should be a recommendation.
Sometimes it should quietly classify information in the background.
And sometimes it should not exist in the architecture at all.
Good product design does not maximize how visible AI is.
It minimizes how much unnecessary work the user has to do.
Start With the Smallest System That Solves the Problem
When approaching a business workflow, I prefer a different sequence of questions.
First:
What outcome are we trying to improve?
Reduce processing time? Increase revenue? Improve a decision? Reduce operational risk?
Then:
What prevents that outcome today?
Maybe information is fragmented.
Maybe the process contains unnecessary manual steps.
Maybe employees cannot find what they need.
Maybe a decision requires interpreting too much unstructured information.
Maybe several systems simply do not communicate.
Only then should we ask:
What technology is actually required?
The answer might be a database.
An API integration.
A better internal application.
A deterministic workflow.
Search.
RAG.
An LLM.
Or an agent.
The architecture should emerge from the problem rather than the other way around.
Complexity Has an Operating Cost
A system does not stop costing money when development ends.
Someone has to understand it.
Monitor it.
Debug it.
Secure it.
Update it.
Explain failures.
Respond when an external dependency changes.
Every additional component creates another place where assumptions can break.
Agents are no exception.
If an agent saves ten hours of work each week but creates fifteen hours of review, debugging, and exception handling, the company has not automated the workflow.
It has moved the work somewhere else.
This is why the simplest viable architecture deserves serious consideration.
Simple does not mean primitive.
It means every component has a reason to exist.
Build Toward Autonomy Instead of Starting There
Sometimes an agent really is the right destination.
Even then, it does not have to be the starting point.
Begin by understanding the workflow.
Centralize the information the system needs.
Automate predictable steps.
Introduce AI where interpretation creates value.
Observe how the system behaves.
Identify where human decisions are still necessary.
Then, if enough of the remaining workflow requires dynamic reasoning and tool use, introduce agency deliberately.
This approach may look slower than beginning with an autonomous agent.
In practice, it often prevents teams from building sophisticated technology around a poorly understood problem.
The Goal Is a Better Business System
AI agents are useful technology.
They will become appropriate for more workflows as models, tooling, and infrastructure improve.
But businesses do not ultimately need agents.
They need orders processed faster.
Information found sooner.
Decisions made with better evidence.
Customers served more effectively.
Risks identified earlier.
Employees spending less time on repetitive work.
An agent is one possible mechanism for producing those outcomes.
It is not the outcome itself.
That distinction should shape how we build.
Start with the business problem. Let the architecture earn its complexity.
Sometimes that path ends with an autonomous AI agent.
Sometimes it ends with a well-designed application and a few reliable integrations.
The better system is the one that solves the actual problem with the least unnecessary complexity.
