Agent, or just a model with a nice interface?
The word is applied to almost anything at the moment, so it is worth being precise. An AI agent has three properties that a chatbot does not.
- It pursues a goal, not a reply. The instruction is an outcome — reconcile this invoice — rather than a question to answer.
- It uses tools. It can query a database, call an API, read a file, send an email. Without tools, it can only talk about doing things.
- It runs in a loop. Act, observe the result, decide the next step, repeat until done or stuck.
Take that loop away and you have a chatbot. We compare the two in AI agents versus chatbots.
How the architecture fits together
- The goal. A request from a person, or a trigger such as an incoming email.
- The model. Decides what to do next given the goal and everything observed so far.
- The tools. A defined set of actions the agent is permitted to take.
- The memory. What has happened in this run, plus retrieved reference material, usually through RAG.
- The guardrails. Limits on what may be done without a human, a cap on steps, and a log of every action.
The engineering effort is almost entirely in tools, memory and guardrails. Making those safe, observable and reversible is ordinary software integration, which is why it lands with AI integration.
What an agent looks like in practice
Invoice reconciliation
An invoice arrives by email. The agent extracts the supplier, reference and line items, finds the matching purchase order, compares them, and either posts the match or raises an exception. Clean matches stop being touched by a person at all.
First-line support triage
A ticket arrives. The agent classifies it, looks up the customer, answers directly if the question is one of the routine forty, and otherwise routes it with a summary attached.
Internal knowledge assistant with actions
A member of staff asks about leave entitlement. The agent answers from current policy, and — because it has tools — can also submit the request.
When an agent is the right answer
An agent earns its extra cost when the task needs several steps whose order depends on what is found along the way. If the sequence is fixed, conventional workflow automation will be cheaper and easier to debug.
What agents cost
A single-purpose agent with two or three tools and a human approving anything consequential is typically a three-to-six-month build. The cost drivers are the number of tools, the consequence of an action, the quality of the source systems, evaluation, and running cost — a reasoning loop makes several model calls per task, not one.
Walk through one invoice, step by step
Mail arrives. The agent is allowed to read that mailbox and nothing else. It extracts supplier, reference, dates and lines. It calls a tool: find purchase order by supplier and reference. The order exists, the totals match within your tolerance, so it calls a second tool: create a draft bill in the accounts package, status “pending approval”. A person on the finance role sees the draft with the PDF attached, clicks post. If the totals do not match, the agent does not invent a story. It opens a task with the two numbers and stops.
That is six or seven model calls, two tools, one write that a human still owns, and a log you can show an auditor. It is also why “we will just give it the Tally password” is not a design.
Permissions are the product
Write down every tool as if it were a junior hire. Can it read invoices? Can it create a draft? Can it post? Can it email a supplier? Can it see every customer or only the ones the current user can see? The last one is where internal assistants go wrong: a warehouse clerk should not retrieve the MD’s salary policy just because the files sit on the same drive.
We implement tools as ordinary .NET methods with the same authorisation the screens already use. The model can only call what that user could click. That sounds conservative. It is the reason the system survives the first wrong suggestion.
What usually goes wrong
The agent loops: a tool fails, it tries again, it tries a third time, it burns money and still does nothing useful. Cap the steps. The agent “helpfully” emails a customer because the prompt said “sort it out”. Do not give it send-mail until the draft quality is boring. The source API returns half-empty records and the model fills the gaps. Validate every write against a schema and reject the rest.
When a workflow is cheaper than an agent
If you can draw the steps without a “here we interpret the email” box, you want workflow automation. An agent earns its keep when the order of steps depends on what is found — no matching PO, try the supplier alias list; still nothing, open a task. That branchiness is the cost. Fixed paths should not pay it.
Vendors blur this because “agent” sells. A rule engine with a chat skin is still a rule engine. Ask what happens when the tool fails. If the answer is “it figures it out”, you are being sold a loop with write-access. Cap the steps. Log every call. Keep consequential writes behind a person until the boring cases are actually boring.
What to put in the first statement of work
The goal in one sentence. The tools, listed as verbs: read mailbox, find PO, create draft bill — not “integrate Tally”. Who may run it. What it must never do. How you will know it worked after thirty days — hours, exception rate, not “staff like it”. If those lines are missing, you have a workshop labelled as a build.
Put the cap on steps in the same document. Ten is plenty for an invoice. If the agent needs twenty, the tools are wrong or the goal is a programme. Write the rollback: delete the draft, never the posted bill, in the first release. That sentence saves an argument in month two.
Name the owner of the exception queue in the same paragraph. An agent without an owner is a chatbot that can also do damage. We will not start a build that cannot name that person. It is not a staffing lecture. It is the difference between a system that survives the first wrong draft and a system that gets switched off. If they cannot name that person in the first call, the project is not an agent. It is a conversation you should have before anyone writes a prompt.
None of that is a research problem. It is the same integration discipline as any other .NET service. For the choice between this and a chatbot, see agents versus chatbots. For the wider decision, see AI for business.