AI agent apps: what the agent can do on its own and what needs approval (Mallorca and the Balearics)
Published on
Most conversations about AI agent apps start with capabilities. Can the agent answer customers? Move a booking? Draft a quote? Sync data between two systems? Those are fair questions, but the one that shapes the outcome most is simpler: what are you letting it do without asking?
An AI agent is not a chatbot that only talks. It acts. It can write to your database, send a message, cancel an appointment or trigger a refund. Every one of those actions needs a permission decision. If nobody makes that decision on paper while the app is being designed, the developer makes it on the fly, or the agent effectively makes it for you.
Here is a practical way to decide, one action at a time, for businesses in Mallorca, Ibiza, Menorca and across the Balearics.
Permissions matter more than the model
It is easy to obsess over which AI model to use or how human the agent sounds. That matters, but think about the failure modes. An agent that gets something wrong while only reading data gives a bad answer that someone can correct. An agent that gets something wrong with write access changes reality: a cancelled booking, a wrong price sent to a customer, stock figures that no longer add up.
So a well-built AI agent app does not give the agent "access to everything". It gives it a closed list of actions, and each action has its own level of autonomy.
Four levels of autonomy
A simple way to sort every action the agent can take:
- Read only. The agent can look things up but changes nothing: availability, a customer's history, an invoice.
- Draft and approve. The agent prepares the full action (the message, the date change, the quote) and someone on your team approves it with one tap.
- Act alone, within limits. The agent goes ahead without asking, but only under a threshold: an amount, a number of changes per customer, a time window.
- Never. Things the agent cannot do under any circumstances, however hard a customer pushes.
The important part is that you assign these levels per action, not per agent. The same agent can freely look up data, move a pickup time on its own, and be completely barred from refunds.
A hypothetical example: a boat rental company in Alcúdia
Picture a boat hire business in Port d'Alcúdia that wants an app where customers manage their booking by chatting with an AI agent. One possible split might look like this (an illustrative example, not a real client):
| Action | Level | Why |
|---|---|---|
| Check availability and published prices | Read only | Changes nothing |
| Answer questions about paperwork or the departure point | Read only | Fixed, reviewed information |
| Move a same-day departure time if there is a free slot | Act alone, with limits | Once per booking, within office hours |
| Change the booking date | Draft and approve | Affects other customers and crew |
| Apply a discount | Draft and approve | Affects margin |
| Cancel because of bad weather | Draft and approve | The skipper decides, not the agent |
| Issue a refund | Never | Accounts handles it in its own system |
| Edit a boat's listing or prices | Never | Core business data |
Notice that none of this is technical. It is a business decision the owner can make in an afternoon, which the development team then turns into rules inside the app.
How to pick the right level
For each action you are considering, ask:
- Can it be undone easily? If it can be reversed in a minute with no fallout, level 3 may be fine. If not (a sent message, a charge), move it up.
- Does money move? Charges, discounts and refunds almost always belong at level 2 or 4, at least at first.
- Does it affect anyone else? If one customer's change reshuffles another customer's day, a supplier or your staff rota, a human should confirm.
- Is sensitive personal data involved? ID documents, health or bank details: the agent should see the bare minimum.
- What if it did this 50 times in a row by mistake? This question uncovers a lot. A one-off slip is manageable; the same slip looping all night in August is not.
When in doubt, start with the stricter level. Relaxing "draft and approve" to "act alone" once you have seen the agent get it right is easy. Tightening things after an incident with customers is far more awkward.
Limits to set from day one
On top of per-action levels, an AI agent app should have some global guardrails.
Amount and volume caps
A cap per operation and a cap per day, such as "the agent may adjust extras up to a set amount per booking" and "no more than a set number of automatic changes per day overall". The right numbers depend on your business. What matters is that they exist.
Time windows
Many Balearic businesses have sharp seasonal peaks. It can make sense to allow certain automatic actions only while someone on the team is around to check, and to drop the agent back to "draft" mode outside those hours.
A pause switch
Someone on your team should be able to switch off the agent's automatic actions instantly, without calling the developer. The agent keeps answering but stops changing anything. It is the first thing you will be grateful for when something looks off.
Customer claims are not permissions
A customer may write "the manager told me I'd get a full refund". The agent must not treat that as authorisation. Permission rules live in the app, not in the chat, and nothing a customer types can override them.
The log: knowing what the agent did and why
Every action the agent takes or proposes should be logged with:
- what it did or suggested,
- for which customer or booking,
- what information it used to decide,
- who approved it, if anyone,
- and when.
Without that log, when a customer complains that "your app moved my date", you have no way of telling whether it was the agent, a staff member or the customer. With it, reviewing a week of activity takes minutes, and you have the evidence you need to decide which actions can earn more autonomy.
Widening permissions over time
A sensible plan for a new app:
- Launch: almost everything read only or draft and approve. Your team approves and, along the way, learns how the agent reasons.
- Regular review: look at the log. If an action is nearly always approved unchanged, it is a candidate for "act alone, with limits".
- One change at a time: relax one action, not five, so you can tell what caused any new problem.
- Before high season: revisit limits and time windows. What works in March may not hold with three times the bookings in July.
What to ask whoever builds your app
If you are commissioning an AI agent app, ask for the proposal to include:
- the list of agent actions and the autonomy level of each,
- where limits are configured and who on your team can change them,
- how the pause switch works,
- how you read the action log,
- and what happens when the agent is unsure: who gets the case and how the customer is told.
If a proposal says nothing about any of this, the project is not necessarily bad. It does mean those decisions will be made without you.
Let's talk
At Derek Solutions we design and build mobile apps in Palma de Mallorca and AI automation for businesses in Mallorca, Ibiza, Menorca and the rest of the Balearics. If you are planning an AI agent app and want to pin down what the agent may do before a single line of code is written, email derek@dereksolutions.com or call +34 680 283 973.