Having an AI agent built as one link in your process

What an AI agent is, in plain words

An AI agent is software that is given a goal, works out for itself which steps that takes, and uses tools to carry those steps out. Tools is not a metaphor here: they are concrete actions you hand it. Look up a customer number, check the stock level of an item, create a draft order line.

The difference with the two things it gets confused with most often:

• A chatbot talks. It answers questions from documents you gave it, does not look in your system and changes nothing there. The full comparison is in our article on AI agents versus chatbots.
• Fixed automation follows a path you drew in advance. Order email in, fields out, look up the customer, create the order, send a confirmation. If this, then that.
• An agent sits in between. You say what needs to happen, not in which order. It picks its own route: look this up, notice something is missing, go and check that, and only then record the result. That freedom is its strength and its risk.

Where the agent sits in the chain

Take a wholesaler receiving orders by email: tidy PDFs, three lines of text, a photo of a handwritten note. What has to happen is not one action but a chain of seven steps, and the agent is at most three of them. The rest is integration work, permissions and an approval screen.

That is where the most common mistake lives. Someone drops in an agent that reads an order email beautifully, but the result ends up nowhere: no integration with the package, so a person retypes it anyway. A link without a chain is not automation. So build the chain out first and then decide which link needs an agent:

1. 01Arrival. The email lands in a mailbox and gets picked up. No AI needed, just an integration.
2. 02Reading. Which customer, which items, which quantities, which date. Language understanding earns its place here: one writes “20 pcs 12mm”, the next builds a table.
3. 03Checking. Does the customer exist, is the item number valid, is there stock, is there a price agreement.
4. 04Deciding. Everything clear, or something is missing. This is where an agent makes a difference: in case of doubt it can go and look somewhere else.
5. 05Recording. A draft order in your system, with the uncertain points flagged.
6. 06Human. Someone approves or corrects. For known customers you can narrow that check later, for new ones never.
7. 07Feedback. The confirmation to the customer and a note in the record.

When an agent is overkill

This is the most important section on this page, and not everyone likes the answer: the vast majority of processes at small businesses are better off with fixed automation. If you know exactly which steps happen in which order, using an agent is like hiring a driver who picks the route when there is only one destination.

The test: can you write the process out on one sheet as if-then rules, listing every case? Then you do not need an agent, but an integration and a handful of rules. At a manufacturer pulling the same list out of the same system every morning, that is the whole story.

• Predictable. With an agent, the same email can be handled differently on Monday than on Thursday. For an invoice line that is unacceptable.
• Cheap. A fixed rule costs next to nothing per case. An agent makes several calls to an AI model per case, and that adds up at volume.
• Testable. You push twenty cases through and see what comes out. With an agent you test behaviour, not outcomes.
• Explainable. When something goes wrong you point at the rule that was set wrong.

When an agent does earn its place

Three situations where that freedom genuinely adds something. If your process fits none of them, pick the fixed version.

• Lots of exceptions. A haulage company processing deviation reports: late, refused, wrong location, damaged, recipient absent. You could write those rules out, but there will be a hundred and a new one every month.
• Information from several sources. An accountancy firm that has to check the client file, the email history and the bookkeeping package for one question. Which sources are needed depends on the question.
• Steps that differ per case. An installation company assessing a fault report: sometimes the installation date is enough, sometimes the maintenance contract and last job sheet are needed, sometimes it is warranty.

The tools: without integrations an agent amounts to nothing

An agent without tools can only talk. Everything that makes it useful sits in the actions it may perform in your systems, and someone has to build those tools. Choosing a model and writing the instruction takes hours; the integrations take days.

• Access. Does your package have an API, and is it in your subscription? Some vendors only release integrations in a more expensive tier. Check that with your own vendor.
• Permissions. The agent should get its own account with precisely the rights it needs, not a staff member’s.
• Reliability. An integration that only works when the package answers politely is not an integration.
• Translation. Your item numbers, customer numbers and statuses. Every system names things differently, and that mapping has to be maintained.
• A test environment. You do not want an agent practising on your live administration, and not every vendor offers one.

The limits: what an agent never does on its own

An agent picks its own steps. So you have to assume it will one day pick a step you had not thought of. You do not solve that by writing in the instruction that it should be careful, but by not giving it the tool.

• Moving money or initiating a payment. Never, not even below a threshold amount.
• Setting prices or discounts. It may look up and show a price agreement, not invent one.
• Sending anything outward without a check. Customer email, quotes, invoices: it drafts, a person presses send.
• Deleting or overwriting for good. Adding and drafting is fine; throwing away is a human job.
• Entering into commitments: promising a delivery, confirming a deadline, accepting something on your behalf.

How you enforce those limits technically

The difference between an agent that is safe and an agent you hope is safe comes down to four measures. They cost build hours and are not optional.

One: it only gets tools you switched on explicitly. Not general access to a system, but six named actions. Two: reading and writing are separated — most tools only look, and anything that changes something writes to a draft status that sets nothing in motion without human approval.

Three: hard limits in the integration, not in the text. A maximum number of steps per case, a maximum number of calls per day, and a stop as soon as it tries the same thing twice. That prevents a rising bill and an agent going round in circles. Four: everything is recorded — every step, every tool, every outcome. Without a log you cannot reconstruct anything after a mistake, and then only switching it off is left.

Building it yourself or having it built

The honest answer: there is plenty you can do yourself, and we would rather say that now than after a quote. The off-the-shelf builder tools get you further than most people think: a helper for one team, an internal knowledge assistant on your work instructions (usually not an agent but a chatbot with your text), or a prototype. A course also makes you a better client.

Rule of thumb: if it helps one team and nothing breaks when it is down for a day, keep it in-house. Self-built agents run aground on three things, always in the same order.

• The integrations. Inside widely known services the building blocks are ready-made. The moment you reach into the package your administration lives in, that stops: reading documentation, arranging access, working out field names, writing error handling. That is programming, even when the tooling looks visual.
• The governance. Who may do what, what happens to customer data, what the data processing agreement says for the services you clicked together. The moment it runs through your business process, that is a real question.
• The maintenance. This is where most self-built work dies. The colleague who made it leaves, a vendor changes something, and nobody knows how it hangs together. If the answer to “who fixes this in a year” is nobody, do not put it in a production process.

What goes wrong in practice

Three problems show up in agents that are already running. None exciting, all three preventable.

• Getting stuck on an exception. A customer not yet in the system, a discontinued item number, an attachment in an odd format. The annoying part is not that it gets stuck, but that it carries on as though nothing is wrong. Build an explicit exit: stop when in doubt, state the reason, into a tray for a human.
• Costs creeping up. Every step is a call and costs money. Five steps over a simple case is fine, forty because it keeps second-guessing itself is not. Without a limit and a counter you only find out on the invoice.
• Nobody noticing. The dangerous one: an agent that quietly stops, or that writes something slightly wrong for three weeks. You need monitoring that checks daily whether it runs and whether the numbers look normal, plus a log per case. A weekly email with counts and errors is the difference between knowing and assuming.

The difference with an off-the-shelf agent in your package

More and more software packages ship an assistant of their own. If it is in your subscription, switch it on first: it is included, it knows your data and it needs no integrations. We have no interest in building something you already have.

The question is not whether it is any good, but whether it covers your case. It stays inside its own package, while most processes at small businesses run through two or three systems — think of a construction firm where estimating, planning and administration each live somewhere else. And it does not know your exceptions: your price agreements, your way of naming items, the customer who orders by WhatsApp.

What we will not do is claim what your package can or cannot do; that differs per version and subscription. Ask your vendor, and ask what an integration costs.

What it costs at Ubert and how to start

Our rates are fixed and do not vary per client. What does vary is the number of hours, and we only know that once we have seen the process. A project price given before the shop floor carries a margin for the unknown, and you pay it.

• AI scan: free, five minutes online. You get a score, a few concrete opportunities and a price indication.
• Core session on your shop floor: a half-day of 4 hours at €596 excluding VAT and travel, a full day €1,192. Advisory rate €149 per hour, travel €0.45 per kilometre. You get a core report with a go or no-go per opportunity.
• Building: €110 per hour for straightforward work, €165 per hour for complex development, paid monthly in advance from an AI budget you set. With an agent the weight sits in the integrations, not in the agent itself.
• Running costs: what the AI models and connected services cost per month once it is live. This scales with your volume; we work it through beforehand.
• Maintenance: a few hours a month once something is genuinely running. Integrations change and exceptions surface.
• Also: we carry professional and public liability insurance, and a subsidy partner checks whether a scheme exists for your project.

Frequently asked questions

What we do for this

Further reading

Other topics

First work out whether you need an agent

Start with the free AI scan: five minutes online, no sales call. If you want to know whether your process calls for an agent or simply a good integration, book an intro call. If the answer is “no agent”, we will say so.