Governing the actions of agents

An agent does not get all the actions from a default site. Its perimeter results from the skills, workflows and authorizations you associate with it.

Build a controlled perimeter

1. Give the agent a unique and observable goal.
2. Match only the workflows necessary for this goal.
3. Check the connectors used by each step.
4. Set sensitive actions on confirmation or blocking.
5. Publish agent only after testing on test data.
6. Set a default agent only when it actually has to host new conversations.

Control points

• reading actions do not reveal too wide a perimeter;
• important writings require good confirmation;
• optional steps may fail without masking an incomplete result;
• only one agent carries the expected default role;
• the deactivated connectors are not assumed to be available.

Principle of every privilege

Create several specialized agents rather than a general agent with all access.

See Authorize workflowsand Govern actions.

Example: support agent without writing

For an agentSupport commandes, allow the search and consulting skills of an order, but no change workflow. If a return workflow is required, allow it separately and set the creation of the request to Confirmation required.

The scope of jurisdiction limits the tools visible by the agent, the workflow authorization limits revenues and permission protects the writing action. Test a reading, a change request and a non-subject question to check each barrier.