Separate knowledge from permission
Knowing the cancellation policy does not automatically mean an assistant may cancel a booking. Treat access to information and permission to change a system as separate decisions. Start with the minimum knowledge and actions needed for the selected task. A connected provider account should not silently become permission for every agent to act.
Define what requires a person
Write specific rules for complaints, exceptional prices, sensitive information and requests outside the assistant’s remit. Include the customer’s explicit wish to speak to a colleague. A rule such as “hand over when uncertain” needs examples so the team can evaluate it. Define which details should accompany the request and which must not be collected.
Test exceptions before publishing changes
A successful ordinary example is not enough. Test missing knowledge, conflicting instructions, a disconnected integration and an action that needs approval. In Feleo’s agent testing, tool actions are previews; they are not proof that a live external write occurred. Review the result before publishing a configuration and keep a clear record of the version being used.
Treat an unknown result as unknown
A connection can fail after a provider has received a request. Blindly trying again may create a duplicate booking or message. The team needs a way to inspect the result and reconcile it before repeating the action. Customer wording should reflect the evidence: “we are checking the booking” is different from “your appointment is confirmed”.
Keep this checklist
- Knowledge access and action permissions are separate
- Exceptions have named owners
- Changes are tested and explicitly published
- Uncertain actions are reconciled before retrying
Prepared by the Feleo team. Examples are planning guidance, not customer results. Confirm the scope of your own pilot before launch.