AI agent has become a word that covers everything from a chatbot to a fully automated system. This article breaks down the concepts and provides a practical basis for assessing when an agent is the right solution and when it is not.
In this article
The short answer
An AI agent is software that works towards a defined goal by choosing for itself from a limited set of tools and approved data sources, guided by instructions, rights and stop rules.
It makes sense when a task requires interpretation of text, documents or other unstructured input, combined with lookups across multiple sources, and when the task repeats often enough that it pays to build and operate a solution.
It rarely makes sense when all steps can be described with fixed rules. Then a regular automated workflow is cheaper, more predictable and easier to test. The rest of the article unfolds that answer.
Four terms that are often mixed up
In conversations about AI in companies, the word "agent" often covers four different things, which have completely different price, risk and operational burden:
- Generic AI chat: answers questions in free dialogue. Good for posting and wording, but usually doesn't know your process, responsibilities or system boundaries, and it doesn't perform controlled actions in your systems.
- Automated workflow: performs known steps according to fixed rules. Stable, cheap to operate and easy to test, but it doesn't interpret. If it encounters an input that the rules do not cover, it stops or fails.
- Specialized AI Agent: interprets input and chooses the next step within limited tools, sources and instructions. Can handle variation but requires control mechanisms because its choices are not deterministic.
- Custom app with agents: gathers user interface, process status, rules, integrations and approvals in one work tool, where agents solve limited sub-tasks. The user interface does not have to look like a chat.
Many disappointed AI projects are really a wrong choice between the four, not bad technology. A company that needs a stable workflow buys an agent. A company with an interpretation problem builds rules. Both parts predictably fail.
What an agent actually consists of
A serious agent is not a prompt. It is the sum of a number of design choices that must be made explicitly:
- A defined goal: what task needs to be solved and what does a good result look like?
- Approved data sources: what can the agent read, and just as importantly, what can it not see?
- Named Tools: what actions can it perform and which are explicitly prohibited?
- Instructions and quality requirements: how should it work and what should it deliver?
- Rights: which identity does it act with, and how little access can it settle for (least privilege)?
- Stop and escalation rules: when should it stop and ask a human for help instead of guessing?
- Logging and traceability: can an outcome be traced back to the sources and decisions that produced it?
If one of the points is missing, it is not a technical problem, but a management problem. This is also why two agents with the same model can behave very differently: the difference lies in the framework, not in the model.
A concrete example: triage of incoming inquiries
Take a shared mailbox with mixed inquiries: orders, complaints, service questions and everything else. Today, an employee opens each email, evaluates it and distributes it. The task requires interpretation (free text), information retrieval from customer and case histories and is repeated daily. It is a classic agent candidate.
A proper first version reads the mailbox and the case system, classifies the request, retrieves relevant history and puts a proposal for category, priority and draft response in a queue. The employee approves, corrects or rejects. The agent sends nothing himself and everything can be tracked.
Note what doesn't happen: the agent doesn't respond to the customer directly, it doesn't create orders, and it doesn't delete anything. The power to act can be extended later, when the quality is documented, and only for those actions where the gain is commensurate with the risk.
When does an agent make sense?
Three conditions must typically be present at the same time:
- Interpretation: input is free text, documents, images or estimates that cannot be described with fixed rules.
- Information retrieval: the answer requires gathering and comparing information from several sources.
- Repetition: the task occurs often enough for the construction and operating costs to pay off.
Typical patterns in addition to triage are draft documentation based on notes and system data, checking deliveries against defined requirements, status collection across systems and searching in approved internal sources with source reference. What they have in common is that the agent makes drafts and proposals, while a human decides.
When is an agent the wrong choice?
- When the process can be fully described with rules: use classic automation. It is cheaper, faster and easier to debug.
- When the consequence of a mistake is high, and there is no proper approval or control mechanism between the agent's proposal and the action.
- When the process is unclear: an agent on top of a fuzzy process makes errors faster and more consistent, not fewer.
- When the task is rare and small: manual handling may be the honest and cheapest answer.
And a related opt-out: multi-agent architecture with many specialised roles sounds impressive, but each additional agent adds sources of error, cost and management needs. Division of roles makes sense when collection, control and integration actually have different requirements for access and quality, not as a starting point. The simplest sufficient architecture wins.
Authority to act: from read access to execution
The agent's power of action should be chosen per workflow, not as a general principle. A practical scale has four levels: read, suggest, act with approval, and act within fixed, reversible limits.
A pilot usually begins at the first two levels: the agent reads approved sources and submits drafts. Only when the quality is documented on real tasks, the power to act is expanded step by step. Critical, external, or irreversible actions should require human approval, and enforcement should reside in deterministic control code, not in the agent's own judgment of what to do.
What is often forgotten: operation
An agent is not finished when it works the first time. Sources change, systems are updated, and task content shifts. Monitoring, random quality control, log review and a fallback plan are therefore included in the decision, just as it must be agreed who owns the solution in operation.
Consider the operating burden when assessing the case. A small agent with a clear owner and straightforward operations is better than an ambitious agent that nobody maintains.
How to get started
Don't start with the technology, but with one concrete workflow: task, users, input, output and bottlenecks. Next, clarify data and risk: which sources should be used, may they be used, and what is the consequence of failure. Only then build a read-only or draft-based pilot and measure it against a baseline.
If there are several possible workflows, or if the data base is unclear, a limited mapping is the natural first step before investing in development.
Related reading
Not sure whether your workflow calls for an agent?
Describe one concrete workflow and we will assess whether an AI agent, classic automation or a combination is the simplest and most appropriate way.
Assess a workflow →