An AI agent is software that pursues a goal across multiple steps, decides what to do next based on what it finds, and uses tools to act on real systems. That last part is what separates it from a chatbot. A chatbot answers. An agent does.
The distinction matters commercially, because the two fail in different ways and cost different amounts to build.
What makes something an agent
Four things have to be true. Software missing any of them is automation with a language model attached, which is fine, but it is not an agent and should not be budgeted like one.
It works toward a goal, not a single response. Given “reconcile this month’s invoices”, an agent plans the steps rather than answering a question about invoices.
It decides its own next step. The sequence is not fixed in advance. If a record is missing, the agent looks for it rather than failing at step three of a hardcoded script.
It uses tools. It queries your database, calls your API, sends the email. Without tools it can only produce text, and text alone rarely finishes a job.
It knows when it is done. It has a definition of success and stops when it reaches one, or escalates when it cannot.
If you are weighing an agent against a conventional chatbot for a specific use case, we cover that comparison in detail in AI agents vs traditional chatbots.
How agents actually work
Five components, and the model is only one of them.
The model does the reasoning. It reads the situation and decides the next action. This gets the most attention and is rarely what determines success.
Tools are the functions the agent can call. Read a customer record, create a ticket, issue a refund. Each one you expose expands what the agent can do and what it can get wrong, so tool design is where most of the safety work lives.
Context is the information the agent gets before it acts. Your documentation, your records, the current state of the task. An agent without access to your business data is guessing, and it will guess fluently, which is worse than failing loudly.
Memory carries information between steps and across sessions, so the agent does not re-ask what it was told two steps ago.
Boundaries define what the agent may do unsupervised. Which actions need human approval, when to escalate, what it must never touch. Systems without explicit boundaries are the ones that produce the stories companies do not want to be in.
Where businesses are actually using them
The pattern across deployments in 2026 is consistent. Agents work where the task is repetitive, the inputs are messy, and a human currently spends time on judgment calls that follow a learnable pattern.
Support triage. Reading an incoming ticket, pulling the customer’s history and order status, resolving the routine cases and routing the rest with context attached. The agent does not need to answer everything. Handling the predictable half well is usually the whole business case.
Document processing. Invoices, contracts, claims, applications. Extracting the fields, checking them against records, flagging what does not reconcile. This is where agents earn their keep fastest, because the inputs are genuinely messy and rules-based extraction has always broken on the edge cases.
Internal knowledge retrieval. Answering staff questions from policies, documentation and past decisions. Lower risk than customer-facing work, which makes it a common first deployment.
Sales and CRM hygiene. Researching inbound leads, enriching records, drafting follow-ups, keeping the pipeline current. Work that gets skipped when people are busy, which is most of the time.
Reporting. Pulling numbers from several systems, assembling them, writing the summary. Recurring, structured, and tedious enough that nobody defends it.
The common thread is not intelligence. It is that each task crosses system boundaries, requires reading unstructured input, and was previously too fiddly to automate with rules.
Where they do not work
Being straight about this saves money.
Tasks with no tolerance for error and no review step. If a wrong action is expensive and nobody checks the output, an agent is the wrong tool until you add the review step.
Work that is genuinely one-off. Agents repay a build cost. A task you do twice a year does not justify one.
Processes nobody can describe. If your team cannot explain how the decision gets made today, an agent cannot learn it from the same absence of information. Document the process first. Teams often find that exercise alone was the win.
Anything where the data is not accessible. If the information lives in someone’s head, or in a system with no API, the agent cannot reach it. This is the most common reason agent projects stall, and it surfaces late if nobody checks early.
What it takes to deploy one
The model is the cheap part. The work is everything around it.
Connecting to your data, so the agent knows about your business. Building and securing the tools, so it can act without acting wrongly. Defining boundaries and approval steps. Building an evaluation harness, so you can tell whether a change made things better. Controlling cost, since token spend scales with usage in ways that surprise people.
Teams that treat agent projects as model-selection exercises tend to produce impressive demos that never reach production. The demo works because a person is steering it. Production has no one steering.
For the technical detail on building one, see how to build a custom AI agent.
How to tell whether you have a candidate
Ask five questions about a specific process, not about AI in general.
- Does someone do this repeatedly, at least weekly?
- Does it involve reading unstructured input such as emails, documents or tickets?
- Does it cross more than one system?
- Can you describe the decision rules, even roughly?
- Is there a natural point where a person could review the output?
Four or five yeses means you have a candidate worth costing. Two or fewer means the process is not ready, and the honest next step is fixing the process rather than buying software.
Where this is heading
The interesting change in 2026 is not that models got better. It is that connecting them to real systems got routine. The infrastructure for retrieval, tool use and evaluation has matured to where the integration work is predictable rather than experimental.
That shifts the constraint. It is no longer whether an agent can do the task. It is whether your data is reachable, your process is describable, and your team can tell good output from bad. Those are organisational questions, and they are the ones worth working on first.
Ethersofts builds AI agents that run in production. We handle the part that determines whether it works: connecting to your data, integrating with the systems you already run, setting boundaries for autonomous action, and building the evaluation to prove it is doing the job.
If you have a process in mind and want to know whether it is a real candidate, talk to an engineer.