Over the past year the word “agent” has appeared in the description of almost every AI product. Copilot has agents, Claude has agents, ChatGPT has agents. For a company executive it is hard to tell what has changed: is it the same chat window with a new name, or something genuinely different?
The difference is fundamental, and it matters not for terminology but for responsibility. An assistant that answers wrongly causes an inconvenience: a person reads it, notices the mistake and corrects it. An agent that misunderstands the task can send an e-mail to a customer, create an invoice in the accounting system or close a helpdesk ticket. That is why agents need a different design, different limits and different oversight.
In this article we explain the difference, describe which controls are essential, and give scenarios that already work at companies we support, not in experiments but in daily operations.
An assistant answers, an agent acts
An assistant is a conversation. You ask a question or provide a text, and it answers. It can be very good: summarise a contract, write a draft e-mail, explain an Excel formula. But the result stays in the chat window, and what to do with it is decided by a person. An assistant has no access to your systems, or only read access.
An agent has a goal and tools. It is given a task, such as “process this customer enquiry”, and access to systems: CRM, accounting, e-mail, calendar, documents. It decides for itself which steps are needed: read the e-mail, check the customer in the CRM, find the price list, prepare a reply, create a record in the system. Then it carries out those steps one after another, checking the result and, if needed, changing the plan.
In short: an assistant is a tool in a person’s hands, an agent is an employee with defined duties and access rights. And like an employee, it needs a job description, an access policy and supervision.
Limits: what an agent can and cannot do
The first rule we apply to every agent: it has only the access the task requires, and nothing more. An agent that processes incoming enquiries must read mail and write to the CRM. It has no right to delete records, change prices or send e-mails outside the company unless that is its task.
Technically this is solved through tool descriptions and access keys: each agent tool is a separately described function with clear permissions, most often through an MCP (Model Context Protocol) server that itself limits which operations it allows. An agent cannot “invent” a new operation; it chooses only from what it has been given.
The second rule: an agent has clear stop conditions. If an enquiry matches no known scenario, if the customer is not found in the system, if an amount exceeds a set limit, the agent stops and hands over to a person instead of trying to “solve it somehow”. A good agent is one that often says “I don’t know, handing over”, not one that always finds an answer.
Logs and human approval
Every agent action must be recorded: what it read, what decision it made and why, which tool it called, what the result was. Without that it is impossible to investigate errors or prove to an auditor what happened. In the context of NIS2 and DORA requirements this is not optional: an automated process that works with customer data must leave a trail.
Human approval (human-in-the-loop) is the second layer. In practice we apply three levels:
- The agent acts independently: the actions are reversible and low risk, for example assigning an enquiry to a category or preparing a draft.
- The agent prepares, a person approves: the action is irreversible or visible externally, such as an e-mail to a customer, an invoice or an order to a supplier.
- The agent only suggests: sensitive areas where a person makes the decision and the agent provides information and a recommendation.
You should start with the second and third levels. The first level appears when, over several months, the logs show that the agent makes fewer mistakes than a person on a specific task. That is a measurable decision, not a matter of faith.
Scenarios that already work
Below are five scenarios from our practice. None of them is futuristic; all rely on platforms available today.
Processing incoming enquiries
A company receives enquiries to a shared mailbox and through a website form. The agent reads each one, determines the type (price enquiry, technical question, complaint, spam), checks whether the sender is an existing customer in the CRM, prepares a draft reply from the knowledge base and assigns it to the responsible employee. In the morning the employee sees not 40 e-mails but 40 sorted enquiries with drafts. They review, correct and send. Processing time drops from hours to minutes.
Registering incoming invoices
Supplier invoices arrive by e-mail as PDFs. The agent extracts the data, matches it against the purchase order in the system, checks the supplier’s details and creates a record in the accounting system with the status “awaiting approval”. If the amount or the details do not match the order, the agent stops and flags the discrepancy. The accountant approves with one action or investigates the discrepancy. Checking the details is also a security measure here: altered-invoice fraud is recognised immediately.
First-line helpdesk
An employee writes to IT support: “the VPN doesn’t work”. The agent checks whether the user account is active, whether there are known outages and whether the device meets the requirements, and provides a known solution or performs a permitted action itself, for example resetting a password after identity verification. If that does not help, the ticket with all the collected information goes to an engineer. This does not replace the managed IT services team, but it lets the team work on real problems instead of repeated questions.
Meeting preparation and follow-up
Before a meeting with a customer the agent gathers the latest e-mails, open quotes in the CRM, unpaid invoices and notes from the previous meeting, and prepares a one-page summary. After the meeting it creates an action list from the recording or notes, assigns tasks and creates a CRM record. A person only reviews and approves. For a manager with five meetings a day, this means arriving at each one prepared.
Contract review against company rules
The legal or procurement department receives a supplier contract. The agent compares it with the company’s standard terms, flags deviations such as limitation of liability, payment terms and data protection clauses, and prepares a list of comments. A person makes the decision, but no longer reads 60 pages looking for what has changed.
Which platform to build on
Agents can be built on all three main platforms, and the choice depends on where your data and processes live.
If the company works in a Microsoft 365 environment, the natural path is Copilot Studio agents: they see SharePoint, Teams and Outlook, and connect to other systems through Power Automate. We describe such agents on the Microsoft 365 Copilot agents page. If you need more complex logic, processing of long documents, or an agent that runs in your own infrastructure, we look at Claude agents with the Agent SDK and MCP. If the company already uses the OpenAI ecosystem or needs a broader set of tools, ChatGPT agents with the Agents SDK are the third option.
In practice we build integrations through MCP, so that an agent can be moved from one platform to another without changing the connections to your systems.
Where to start
Implementing agents is not a big project if you start the right way: with one process, not with an “AI transformation”.
- Pick one process that repeats every day, has clear rules and whose mistakes are reversible. Sorting incoming enquiries is a good first candidate.
- Describe it the way you would describe it to a new employee: what information arrives, what decisions are made, when to turn to a manager.
- Set the agent’s access to the minimum needed, and set an approval level for each action.
- Run it in parallel with a person for 4 to 6 weeks: the agent prepares, the person checks. The logs will show the accuracy.
- Only then expand its autonomy or move to a second process.
If you want us to design and implement the first agent with you, we start with a process description and a risk assessment, not with a platform choice. The platform is the last question, not the first.
