The scenario
A supplier invoice arrives by email, has to be matched to a purchase order and a goods receipt, checked against the contract, and either posted or routed to an exception owner. Today three people touch it.
AgentOS demo
An agent that finishes the work, with permissions, approvals and an action log
One real workflow across ERP, CRM or HRMS, executed end to end in a sandbox: what the agent may touch, where a human approves, and what evidence is written for every action.
In Saudi Arabia
What turns the AgentOS demo into a production system
A working demo and a system a Saudi reviewer will sign off are two different things. These are the questions asked before go-live, and what we hand over against each one.
AuthorityWhat it requiresWhat we buildWhat you keep
SDAIA, PDPL
Lawful basis for every personal-data field the demo touches, before it runs on real records.
Field-level data map produced during scoping, sanitised extract used until that map is signed off.
Data map and lawful-basis note the client's DPO can file before production access is granted.
NDMO
Data classification and quality controls on the sources the demo would depend on in production.
Source-by-source classification, with quality thresholds agreed before the pilot widens.
Classification map and a quality gate report your data office keeps.
NCA ECC
Access control, logging and read/write boundaries clear before wider rollout.
Entitlements scoped per role, every action logged, write paths gated behind approval.
Control matrix and an action log your risk function can replay.
SAMA (regulated finance)
Human authorisation before an agent takes an irreversible action on a customer account.
Risk-tiered action classes with a hard stop and named approver above threshold.
Signed action-authority matrix and a replayable log per case.
Where it runs
The demo itself can run on a sanitised or representative extract, but where the data cannot leave a system, the build happens inside your environment inside Saudi Arabia, not ours.
Arabic, as it is spoken here
Arabic questions and documents are handled as first-class input, not translated to English before processing, including organisational and Gulf-dialect terms.
Who it is for
Operations and shared-services owners carrying a queue of repetitive, rules-based work.
Sample workflow
The chain of work behind the answer
1
Trigger
- Email, queue or system event
- Case opened with an ID
- Classification and priority
2
Understand
- Document extraction, Arabic and English
- Policy and contract clause retrieved
- Missing fields requested, not guessed
3
Act with tools
- Scoped API calls to ERP, CRM, HRMS
- Each tool permissioned per role
- Dry-run before any write
4
Human checkpoint
- Threshold and risk-tier rules
- Approver sees the reasoning and evidence
- Reject sends the case back with a reason
5
Evidence
- Full action log per case
- Trace of every tool call
- Cost and outcome per completed case
The agent is measured on completed cases and exceptions, not on how convincing its language sounds.
What you will see
Two examples, start to finish
A three-page supplier invoice in mixed Arabic and English, no PO number in the subject line.
- Behind it
- Extract header and lines → find the PO by supplier, amount and date window → pull the goods receipt → check the contract price clause → three-way match.
- What comes back
- Matched and queued for posting, or an exception card naming the exact mismatch, the clause it breaks and the owner it went to.
“Onboard this new joiner for Sunday.”
- Behind it
- HRMS record created → asset and access requests raised with role-based entitlements → induction scheduled → line manager notified for approval.
- What comes back
- A completed checklist with each system reference number, and anything requiring approval held rather than forced through.
Deliverables
What you keep after the session
Every item below is an artefact your team can reuse, whether or not the engagement continues.
One agent running a real workflow
Built in a sandbox against your systems or their test instances.
Tool and permission map
Every API the agent may call, with the scope and the role behind it.
Approval design
Where a human must decide, by risk tier and value threshold.
Action log sample
A full audit trail for the cases run in the session, in the format audit will accept.
Exception taxonomy
The cases the agent should never attempt, and why.
Session agenda
- The workflow run end to end, including a deliberate failure case
- Removing a permission live, and watching the agent stop
- The approval screen from the approver's side
- Reading a case audit trail line by line
What we need from you
- One workflow with a known volume and a named owner
- Test-instance access or exportable sample cases
- The policy or contract rules the workflow must respect
Where data cannot leave a system, the demo is built inside your environment instead of ours.
FAQ
Frequently asked questions
Can the agent act without a human?
Only inside the risk tier you approve. Low-risk, reversible actions run unattended; anything above the threshold you set waits for a person.
How is this different from RPA?
RPA replays fixed clicks and breaks when a screen changes. An agent reads the case, retrieves the governing rule and calls an API, so variation is handled instead of breaking the run.
What stops it from acting on data it should not see?
Tool scopes carry the same entitlements as the user or service account behind the case, and every call is logged.
Topic cluster
Explore the topic cluster
Curated links across our Saudi hubs, sector pages and long-form blog research.