AI agents for SMEs: where to start without wasting budget

In recent years the word "agent" has become ubiquitous: every piece of software seems to have one. For a small or medium-sized business the risk cuts both ways: investing in something that isn't needed, or giving up a tool that could genuinely lighten day-to-day work. Here I try to clear things up, starting from how I design agents in real projects.

What an AI agent is, in practice

An agent is a program that uses a language model (an LLM such as GPT or Claude) not just to answer a question, but to reach a goal by carrying out a sequence of steps. At each step the model decides which tool to use – read an email, query the ERP, search a document archive, fill in a draft – looks at the result and carries on until the task is done or a person needs to step in.

That is the difference from a chatbot: a chatbot talks, an agent acts on business systems. It is also why an agent must be designed with the same care as any other software that touches real data and processes.

When an agent makes sense (and when it doesn't)

Agents work best when the work has three characteristics:

• unstructured inputs: emails, PDFs, scanned documents, free-text notes, requests phrased differently every time;
• variability: cases that are similar but never identical, where a fixed rule is not enough;
• several systems involved: today someone copies information from one window to another.

If, on the other hand, the process is already fully rule-based – "if the amount exceeds X, send it to manager Y" – a traditional workflow or a system integration is cheaper, faster and more predictable. Using an LLM to apply a deterministic rule means paying more for a less reliable result.

Typical processes to start from

• Triage of incoming requests: the agent reads emails or tickets, classifies them, extracts the useful data and routes them to the right team with a draft reply.
• Data extraction from documents: orders, delivery notes and supplier quotes are read and turned into structured data to be checked and recorded in the ERP.
• Assistant for internal documentation: procedures, manuals and template contracts become searchable in natural language, with a reference to the source document.
• Preparing drafts: quotes, periodic reports and meeting summaries, starting from data already in your systems.

In all these cases a person remains responsible for the final decision: the agent prepares, the person checks and approves.

How to set up the first project

1. Pick a small, frequent, tedious process. A task repeated dozens of times a day is better than a large cross-department project. Results come sooner and are easier to measure.
2. Measure the starting point. How long does it take today? How many errors or rework cycles? Without a baseline, you will never be able to say whether the project worked.
3. Plan for human oversight from day one. In the first phase the agent proposes and a person approves. Autonomy is increased gradually, only where the data shows it is reliable.
4. Give the agent the least privileges possible. If it needs to read orders, it must not be able to delete them. The tools an agent uses are APIs with precise permissions, not full database access.
5. Build a set of test cases. A collection of real (anonymized) examples with the expected outcome: it is the basis for evaluating the agent today and for catching regressions when the model or the instructions change.
6. Keep costs under control. Every model call has a cost. Spending limits, caching and choosing the right model for each task make a big difference.

The architecture I usually adopt

In the multi-agent systems I design – such as the SpinFlow framework – a few elements recur, and I recommend them for smaller projects too:

• an API gateway in front of the models, centralizing logs and spending limits and making it possible to switch provider without rewriting the application;
• an orchestrator that defines the allowed steps, time limits and the points where human approval is required;
• tools exposed as services with explicit permissions towards the ERP, CRM or document archive;
• context management that gives the model only the information it needs, not the entire company archive;
• an evaluation pipeline that re-runs the test cases on every change.

Risks to manage, without alarmism

• Wrong but convincing answers. An LLM can be wrong with great confidence: that is why you need checks, source references and oversight.
• Prompt injection. An email or document can contain instructions written specifically to trick the agent. Least privilege and keeping data separate from instructions are the first line of defense.
• Personal and confidential data. You need to know which data reaches the model provider, where it is processed and under which contractual terms. Often it is enough not to send data the task doesn't need.
• Regulation. In the EU the GDPR applies as for any other processing of personal data, and the Artificial Intelligence Act sets obligations graded by the risk level of each use. For many internal uses the obligations are limited, but they must be checked case by case.

In short

A good first AI agent project is small, measurable, supervised and built to the same quality standards as any other business software.

If you are thinking about where to introduce AI in your company, the starting point is not the latest model, but the process that wastes most of your people's time today. Everything else is built from there. On this topic you may also like the article on automating business processes in five steps.