Most AI policies are written for the whole organization. Agents need something narrower. An Agentforce agent has a job, a user record that limits what it can see, a set of actions it can take and a point where it must hand over to a person. Each of those is a decision, and each decision needs an owner. This guide sets out a one-page charter for every agent, how to fill it in with your business, IT and compliance owners, and how it lines up with what Saudi Arabia, the UAE and the DIFC expect from organizations that use AI.
The short version
- One agent, one page, one named owner. The charter records what the agent is for and who is accountable for it.
- Ten fields cover it: job and risk level, owners, users and channels, data, actions, language, handover, tests, monitoring, and change control.
- The agent’s user record is your first control. Salesforce creates agent users with minimal access, so every permission you add widens what the agent can reach.
- Test before launch and after every change. Testing Center runs synthetic conversations in a sandbox and checks whether the agent picks the right topic and action.
- The charter doubles as evidence for SDAIA’s AI Ethics Principles, the UAE Charter for the Development and Use of AI, and DIFC Regulation 10.
Why each agent needs its own charter
Policies set principles. Agents need decisions. Who agreed that this agent may book an inspection without a person checking? Who signed off its Arabic tone? Who reviews it when Salesforce changes the model underneath? Without one page that answers those questions, the answers live in chat threads and in the memory of one administrator. With it, an auditor, a regulator or the next owner can see in five minutes what the agent is for, what it can touch and who is accountable.
A charter also keeps agents small. When a team has to write down the job in one sentence, scope creep shows up on the page before it shows up in production.
The one-page charter
Ten fields, each with a person who signs it. Keep it to one page. If a field needs more, the agent is probably doing too much.
| Field | What to write | Who signs |
|---|---|---|
| 1. Job and risk level | The job in one sentence, the outcomes it must never decide alone, and its risk level under the framework that applies to you | Business owner, with compliance |
| 2. Owners | The business owner, the technical steward, and the person who can switch the agent off | Head of the function |
| 3. Users and channels | Who talks to it (customers, employees or partners), where (web, app, WhatsApp, Slack), and how they are verified | Business owner and security |
| 4. Data it can see | The objects, fields and knowledge it needs, and what it must never see | Data owner and data protection officer |
| 5. Actions it can take | Each action, what it changes, its limits, and which actions need a person to approve | Process owner |
| 6. Language and tone | Arabic, English or both, the register, the terms that must never be translated, and who reviews the Arabic | Brand and Arabic content lead |
| 7. Handover | When it must pass the conversation to a person, and what context goes with it | Service lead |
| 8. Tests | The test set, the pass threshold, and when tests run again | Quality lead |
| 9. Monitoring | What is reviewed, how often and by whom: accuracy, handovers, complaints and cost | Business owner |
| 10. Change control | Who approves changes to instructions, topics, actions or the model, and when the agent is retired | Technical steward and compliance |
Five decisions that matter most
1. Scope the job narrowly
Agentforce agents are built from topics, instructions and actions, and Salesforce’s own testing tools measure whether an agent picks the right topic and action for a request. A narrow job means fewer topics, clearer instructions and tests that can prove the agent works. “Answer service-charge questions and open maintenance requests” is a job you can test. “Help residents” is too broad to test.
2. Treat the agent user as the boundary
Salesforce documents that a service agent uses a dedicated user record that decides which data it can read and edit, and that this user is created with minimal access so the agent is secure by default. Every permission set you add widens its reach, so write field 4 before anyone touches permissions. One detail deserves a line of its own on the charter: context such as the customer’s contact record identifies who is talking, and it does not restrict what the agent can access. If only verified customers should see their own records, your flows and Apex have to check verification. Our guide to Claude in Salesforce covers why loose sharing rules matter more once agents arrive.
3. Put limits and approvals on actions
For every action, the charter should say what it changes, its limits (an amount, a count, a record type) and whether a person approves it. Start with agents that read and answer. Add actions that change records once the tests and the handover are working, and add them one at a time, each with its own line in field 5.
4. Design the handover before the conversation
Write down the triggers: the customer asks for a person, the agent cannot resolve the request after two attempts, a complaint, a vulnerable customer, or a question that needs regulated advice. Then write down what travels with the conversation: the transcript, the intent and the verification status. If the agent speaks Arabic, the person who receives the handover has to as well.
5. Decide how you will know it works
Salesforce built Testing Center to generate synthetic conversations from natural-language instructions and run them in a sandbox, a copy of your production configuration, before an agent goes live. The Einstein Trust Layer keeps an audit trail that follows a prompt through each step, so reviews can rest on evidence. Rerun the full test set after every change to instructions, topics, actions or the model, and attach the results to the charter.
An illustrative charter
Here is the charter for a resident service agent at a property developer. The values are examples to show the level of detail. Your owners set the real ones.
| Field | Example |
|---|---|
| Job and risk level | Answer service-charge and permit questions and open maintenance requests. It never waives charges or approves permits. Limited risk, in the owner’s assessment. |
| Owners | Head of community services (business owner), Salesforce lead (steward), service operations manager (can switch it off) |
| Users and channels | Residents on the website, the app and WhatsApp, verified by unit number and a one-time code |
| Data it can see | The resident’s unit, open cases and service-charge balance, read only. No payment card data. |
| Actions it can take | Open a maintenance case. Book one inspection slot per request. No refunds or waivers. |
| Language and tone | Arabic and English, warm and plain. Community and unit names are never translated. The Arabic content lead reviews a sample each month. |
| Handover | On request, after two failed attempts, for complaints and for payment disputes. The transcript and verification status go with it. |
| Tests | A set of synthetic conversations in each language before launch, rerun after any change, against a pass threshold the owner sets |
| Monitoring | Weekly for the first month, then monthly: handovers, resolution, complaints and an Arabic sample review |
| Change control | The steward proposes, the owner approves, and compliance signs again if data or actions change. Retire it if the job moves to another channel. |
How the charter lines up with Gulf AI principles
The charter is internal governance, and it also gives you the evidence that Gulf frameworks ask for. Use it as a governance aid, and confirm with your legal team which rules apply to your sector and free zone.
| Framework | What it expects | Where the charter answers it |
|---|---|---|
| SDAIA AI Ethics Principles (Saudi Arabia, effective September 2023) | Seven principles, including privacy and security, transparency and explainability, and accountability and responsibility. Four risk levels, from little or no risk to unacceptable. A Responsible AI Officer, and assessment of higher-risk systems. | Job and risk level, owners, tests and monitoring |
| UAE Charter for the Development and Use of AI (2024) | Twelve principles, including safety, algorithmic bias, data privacy, transparency, human oversight, and governance and accountability | Owners, data, handover (human oversight) and tests |
| DIFC Data Protection Regulation 10 (2023) | Notice when personal data is processed by autonomous systems, human-defined purposes that prevail, conditions on high-risk processing such as appointing an Autonomous Systems Officer, and a register of use cases | Job (the human-defined purpose), users and channels (the notice), owners, and the set of charters as your register |
Who signs, and when
- Before the build: the business owner and the steward agree the job, the data and the actions.
- Before go-live: compliance signs the data and the risk level, the Arabic content lead signs the language, the service lead signs the handover, and the test results are attached.
- After every change: the steward reruns the tests and the owner approves.
- Every quarter: the owner reviews the monitoring and decides to keep, change or retire the agent.
Where to start
Pick the first agent you plan to launch and write its charter before anyone builds it. It takes an afternoon with the right people in the room, and it will save weeks of rework. If you are still choosing that first agent, the Agentforce Readiness Assessment covers ownership, approvals, testing and monitoring as one of its eight areas. See also how we deliver Agentforce in Arabic and English.
Frequently asked questions
What is an agent charter?
A one-page document for each AI agent that records its job and risk level, its owners, users and channels, the data it can see, the actions it can take, its language and tone, its handover rules, its tests, its monitoring and its change control.
Who should own an Agentforce agent?
A named business owner who is accountable for its outcomes, supported by a technical steward who maintains it, and a named person who can switch it off.
Does Agentforce respect our Salesforce permissions?
A service agent works through a dedicated user record that decides which data it can read and edit, and Salesforce creates that user with minimal access. Every permission you add widens its reach, and customer verification has to be checked in your flows and Apex.
How do we test an agent before launch?
Salesforce Testing Center generates synthetic conversations and runs them in a sandbox to check whether the agent picks the right topic and action. Rerun the tests after every change and keep the results with the charter.
Which Gulf AI frameworks should the charter reflect?
It depends where you operate. Common references are SDAIA’s AI Ethics Principles in Saudi Arabia, the UAE Charter for the Development and Use of AI, and DIFC Data Protection Regulation 10 for personal data processed by autonomous systems in the DIFC. Sector regulators may add their own rules.
Planning your first agent? The Agentforce Readiness Assessment gives you three use cases, a scorecard and a costed pilot plan in ten working days, free for qualifying customers. Want your whole org checked first? Start with the free Salesforce Health Check.
Sources
- Salesforce Help: Configure Service Agent Access
- Salesforce: Agentforce Testing Center announcement
- Trailhead: Meet the Einstein Trust Layer
- SDAIA: AI Ethics Principles
- UAE AI Office: Charter for the Development and Use of AI
- Mayer Brown: AI regulation in the DIFC (January 2026)
- Clyde & Co: DIFC regulation for autonomous systems (September 2023)
