An internal assistant can read a record, but should it change it?

Why “just let it update the record” goes wrong

Once an internal assistant can answer questions about bookings, jobs or invoices, the obvious next request is “can it fix things too?” It can, but only with a boundary. Natural language is ambiguous. “Move the Sharma group to the corporate rate” could mean all rooms or the two the guest called about, from tonight or from check-in. A person reading that request would ask. An assistant that executes immediately will guess, and the guess will be written into the system of record.

The answer is not to forbid actions. It is to make every action pass through five visible stages.

Read, propose, approve, apply, undo

1. Read. The assistant looks up the record using the requester’s own access. If the staff member cannot see the folio, neither can the copilot on their behalf.

2. Propose. It drafts the change as a structured edit: record, fields, old values, new values, reason. Nothing is written yet.

3. Approve. The proposal goes to whoever is authorised for that kind of change. For some changes, that is the requester. For others, it is a manager.

4. Apply. On approval, the system writes the change, stamps who approved it and when, and links it to the original request.

5. Undo. The previous values are kept so the change can be reversed in one step, within a defined window, by an authorised person.

An illustrative example: a rate change at a hotel

Consider a hypothetical 120-room business hotel in Dubai running an AI-native operating system with a copilot that front office staff can type or speak to. A front desk executive receives a call from a corporate client and asks the copilot: “Move the three Al Noor rooms to the corporate rate for the whole stay.”

Read. The copilot finds a group booking under Al Noor Trading with four rooms, not three, checking out in two days. It flags the discrepancy rather than choosing: “There are four rooms on this booking. Which three?” The executive picks rooms 512, 514 and 516.

Propose. The copilot drafts the change: three room reservations, rate plan from “BAR Flexible” to “Corporate Al Noor”, nightly rate from an illustrative AED 620 to AED 480, applied to all nights including the two already stayed. It shows the total folio difference for each room.

Approve. The hotel’s role matrix says front desk staff may change rates for future nights within the same rate family, but a retroactive change across rate families needs the front office manager. The proposal is routed to the manager with the call note attached. The manager approves future nights only and rejects the retroactive part.

Apply. The system applies the approved portion, records both the approval and the partial rejection, and updates the folios.

Undo. The next morning, accounts notice the corporate contract had expired the previous month. The finance controller reverses the change from the audit view. Old rates are restored, and the reversal is linked to the original request.

The copilot saved time at every step, but it never decided anything the hotel had not delegated to it.

Which actions can skip approval

Not every change needs a second person. A useful decision rule is to let an action run on the requester’s own approval only when all of these are true:

• The requester is already allowed to make the same change by hand.

• The change affects one record, not a batch.

• The change has no direct money, tax or legal effect (a contact number, a note, a preferred room type).

• The change can be undone completely within the system.

• The action has been tested on synthetic records and its proposals matched what a person would have done.

If any of these is false, keep the approval step. Over time, a team can move specific action types into the self-approved list based on evidence, rather than on how confident the demo looked.

A pre-launch checklist for copilot actions

• A role matrix exists that says who may change what, by hand, today.

• The assistant inherits the requester’s access and nothing more.

• Every proposal displays record, field, old value, new value and reason.

• Ambiguous requests produce a question, not a guess.

• Approvals are logged with the approver’s name and time.

• Partial approval is possible.

• Undo has been tested on a real copy of the data, including after other edits.

• Someone owns the list of action types and reviews it monthly.

Where SolvTree fits

This is the copilot layer inside the AI-native ERP and internal AI tools we build: an assistant that reads, proposes and acts within your role rules, with approvals and undo built in. We start with read-only questions on one workflow and add one action type at a time once its proposals have been checked. For a broader view of the operating-system approach, see what an AI-native ERP is.

Next step: If you are weighing what your staff assistant should be allowed to do, book a free 30-minute operational audit and we will map one internal action and its approval boundary. The report is yours to keep.