I have been thinking about something that comes up in conversations with organisations, technology teams, and developers - there seems to be a bit of confusion about when to use traditional software, when to use GenAI, and when to use agents - which is understandable.
The technology has moved quickly. What started for many people as chatbots and content generation has now expanded into copilots, workflow assistants, tool-using agents, autonomous processes, and increasingly blurred boundaries between software and human-like decision support. The temptation is therefore, to treat every problem as an AI problem.
The opposite is also risky. Some organisations are so focused on controlling AI that they miss where it can genuinely improve work.
The question is, in some ways simple: Where should we use deterministic systems, where does GenAI add value, and when is an agent actually justified?
My working principle is - Deterministic where possible. AI where beneficial. Agents only where necessary.
What is it?
First off, this is not an anti-AI position - it’s a pragmatic design principle. Traditional software is still the right answer for a lot of work. If a problem can be solved with rules, scripts, APIs, database queries, workflow tools, ETL processes, or a conventional application, start with these. Those systems are easier to test, easier to support, easier to explain and they behave consistently, which matters when the process needs predictable outcomes.
GenAI becomes useful when the work involves judgement, ambiguity, language, interpretation, summarisation, classification, synthesis, drafting, or question answering. That is where AI starts to make sense. It can help review a policy document, summarise a meeting, extract information from a messy set of files, draft a response, classify service requests, analyse incident notes, or support procurement and vendor review work.
But that does not mean GenAI should execute every action, an important design principle is the separation of thinking from doing. Let AI reason, recommend, draft, summarise, and analyse - then let deterministic systems, APIs, workflow engines, and approved business processes execute the action.
Agents are a further step again. An agent becomes relevant when the path cannot be fully defined in advance. It may need to decide which tool to use, what information to retrieve, what step comes next, or how to adapt as the task unfolds. That can be powerful, but it also changes the risk profile.
- A simple assistant helps a person work faster.
- A copilot supports a person inside a task.
- A cowoker starts to take on a process.
- An agent starts to perform delegated work across tools.
- An autonomous agent begins to operate with limited human intervention, taking on a role.
Those are not just technical differences, they are operating model differences. As autonomy increases, the need for controls, observability, security, review, and accountability increases as well.
What does it mean from a business perspective?
The difference is that AI systems introduce more variability and act more like people. They interpret, infer, summarise, and sometimes get things wrong in ways that are not always obvious. That means we need to design the surrounding process with judgement, review, escalation, and recovery in mind.
AI value is created in the business process, not in the model itself. The useful question is not whether an organisation has deployed AI. The useful question is where AI improves real work. That might be faster triage of service requests, better knowledge reuse, improved policy review, more consistent report drafting, faster meeting preparation, or reduced effort in document-heavy internal processes.
The risk profile changes as AI moves closer to action. An assistant that helps someone draft an email is one thing. An agent that updates a service ticket, changes a record, triggers a workflow, sends a communication, or affects a financial or legal process is another. The closer AI gets to operational action, the more deliberate the design needs to be.
Quality control becomes a design issue. It is not enough to ask whether the model is good. The better question is how the process validates the output: Are there business rules? Are there schemas to validate output against? Are confidence thresholds used? Is there human review where the risk justifies it? Can the organisation inspect what happened when something goes wrong?
If you cannot inspect it, should you automate it. Observability is not just a technical concern it becomes part of the operating model. Prompts, inputs, retrieved context, outputs, reasoning, tool calls, approvals, errors, retries, latency, cost, and outcomes all matter when AI becomes part of a business process. Where available, reasoning traces and intermediate execution paths can also be useful, but they should be treated as diagnostic evidence, not as guaranteed explanations of model behaviour.
Security also changes. AI systems introduce risks that do not exist in traditional software in quite the same way. Prompt injection is a good example - if an AI system is reading external documents, emails, web pages, forms, or vendor content, then malicious instructions can be hidden inside the material being processed. That means AI security has to be addressed during design, testing, and operation. It cannot be bolted on at the end.
Existing management disciplines become more valuable, not less. Good architecture, risk management, service management, governance, procurement, testing, and support practices all still matter. That sounds like a lot, but it is not new work - it’s the sort of work IT departments have been doing for years.
What do I do with it?
Start with some level of management discipline applied to the appropriate level of maturity, autonomy, and risk - some examples below (send me a note and I’ll send you a copy of my Guidance document - it’s short and digestible).
Separate assistance from action. Treat AI that helps people think, draft, summarise, or analyse differently from AI that changes data, triggers workflows, sends messages, or takes action in systems.
Use deterministic systems wherever the process is known and repeatable. If the rules are clear, use the rules. If the calculation is exact, do not ask a language model to do it. If a workflow can be defined in advance, a workflow engine may be the better answer.
Use GenAI where interpretation is needed. That is where the value often sits, especially in organisations with document-heavy processes, internal knowledge, service requests, policies, procurement material, meeting notes, reports, and operational history.
Consider agents only where the path is genuinely dynamic. If the work requires planning across tools, adapting to changing information, or deciding which step to take next, an agent may be useful. But start with limited autonomy: Assistants before copilots; Copilots before coworkers; Coworkers before agents and Agents before autonomous agents.
Design for human intervention from the beginning. Pause, override, escalation, approval, and recovery mechanisms are not signs of failure. They are how organisations keep people accountable while still gaining value from automation.
Measure outcomes, not just model performance. Accuracy matters, but business value usually shows up in operational terms - cycle time, reduced rework, improved quality, increased consistency, backlog reduction, faster triage and reduced effort. Those are the kinds of measures that help leaders understand whether AI is improving the work or simply adding another tool to the environment.
Design for model replacement. Models, vendors, and platforms will continue to change. The more tightly a process is coupled to a specific model, the harder it becomes to adapt later.
The point is not to slow AI adoption down, the point is to avoid turning every workflow into a probabilistic experiment. Good AI adoption is not about choosing between traditional software and AI, it is about understanding what each is good at and designing the overall process accordingly.
- Rules where rules work.
- AI where judgement helps.
- Agents where dynamic action is genuinely needed.
- And human accountability throughout.
Are developers and business teams getting clearer on these distinctions, or is everything still being pushed into the same broad “AI solution” bucket?