If agents from more than one vendor will touch your Gulf systems of record, this is for you. If no agent touches a real system yet, start with the process instead.
This is a leadership playbook. The worked examples in it are simulated to show the shape of the evidence you should ask for. They are not client results or measurements, and each one is labelled.
What can it solve for a Gulf team running many agents?
Five jobs, each tied to a problem you will meet once agents from more than one vendor touch the same systems. Everything in the table comes from MuleSoft's own documentation or release notes, so read it as what the vendor says it does, not as what we have measured.
What it does not solve is the process. A broker routes work you have already described, and our agent program operating model is how we write it down: a claim, a receipt, an owner. If nobody can say which step is a rule and which is a judgment, no tool will decide that for you.
Why are Gulf teams under pressure to act now?
Two clocks: a government target and tax deadlines. Neither waits for your architecture.
On 23 April the UAE Cabinet announced a framework to move 50% of federal government sectors, services and operations to agentic AI within two years. It said ministers, directors general and entities will be assessed on their speed of adoption and the quality of implementation.
Tax rules add dates that force integration work, with or without agents. They matter here because the same few systems, ERP and tax platform, are where agents will be asked to act. UAE firms at AED 50 million or more go live on e-invoicing on 1 January 2027 and Saudi Wave 25 integration is due 1 February 2027.
A late UAE e-invoice costs AED 100 per document, capped at AED 5,000 a month, per RSM's summary of Cabinet Decision No. 106 of 2025. The Saudi dates come from Grant Thornton. Check your own dates with your tax adviser.
The common thread is that a ministry, a bank or a trader soon runs agents from several vendors against the same few systems of record. Somebody has to say which agent may do what, and prove it.
Which steps should a model decide, and which a rule?
Put a fixed rule on every step a regulator or auditor will ask about, and give a model the judgment calls. That split is our view of good practice, and it is the design MuleSoft's Agent Script is built for.
MuleSoft's 14 July release notes call Agent Script a graph-based language that gives explicit control over how brokers coordinate agents, tools and models. MuleSoft's June post describes a hybrid of deterministic workflows and agentic reasoning, with a graph view and model support for Salesforce-managed models, OpenAI and Gemini. The broker talks to other agents over version 1.0 of the Agent2Agent (A2A) Protocol, according to the same release notes.
For a regulated process, the benefit is a record you can read: which steps followed a fixed path and which a model decided.
Here is how we would split the work in five Gulf settings. This is our judgment, not a vendor claim.
Rule or model, by setting
Each row follows one habit: a person can point at the rule and say who wrote it.
Where else would it pay?
Wherever one customer request crosses several agents and a system of record. Here are six more settings, in our own words, with the Agent Fabric piece we would reach for first. The pieces are the ones in the table above, and each row is a design idea to test, not a result.
In each row the model never owns the audited step. That is the whole design.
Several rows also have a Mindcat app at the front of the work. Clinic and Bookings sit beside the clinic row, Stays beside the hotel row, Maintain beside field service, People beside HR and Projects beside construction. They are separate products with their own pages, so read each one for what it does today. Agent Fabric sits behind them, when an agent from another vendor needs the same rules.
Who answers when an agent from another vendor acts?
A person does, and the agent has to carry that person's identity. Two sources say so, one from a regulator and one from MuleSoft.
Inside the Dubai International Financial Centre, Regulation 10.3.4 of the DIFC Data Protection Regulations deems the deployer of an autonomous or semi-autonomous system to be a controller for the personal data it processes. DIFC's guidance adds that the system operates "within the appropriate human-established limits", much as an employee would. It binds DIFC entities and DIFC personal data only. The federal UAE and Saudi rules are separate, and we do not cover them here. Our kill switch post has the longer read on Regulation 10.
MuleSoft's answer to the identity half is Trusted Agent Identity, an on-behalf-of model (our page on trusted agent identity covers how we set it up). Its announcement says the agent acts "with the real authority of the user they're helping", and that every action traces back to the originating user. It says MuleSoft's gateway enforces this on any agent, "regardless of where it is hosted or how it was built", and that high-risk actions can ask for a second check mid-task. That is the claim to test: take an agent from a vendor that is not on your MuleSoft platform, make it write to one system of record, and see whose name is in the log. We have not run that test, and the page does not give a ship date.
What does the evidence look like? A simulated example
Take one customer complaint that two vendors' agents handle: a service agent from one vendor reads the case, and an in-house agent from another proposes a refund. This is a simulation we built to show the record you should ask for. The names, times and amounts are invented.
Then the stop drill. Someone reports that the refund agent is proposing refunds it should not. The drill below is also simulated. Its times are invented, to show which handoffs to time.
Simulated stop drill, invented times
Minute 0
Reported. The agent register shows its owner and deputy
Minute 3
Owner pauses the agent at the gateway, which is the one place every call passes
Minute 6
Checked: a test call from that agent is refused
Minute 20
Writes already made are listed and sent to a human to reverse
The point of both is the questions they force. Can you produce that record for an agent you did not build? Can you name the person who pauses it? If the answer is a shrug, you have found the work.
Which pieces are live, and which were dated for later?
Some are live and some were dated Q3 2026 in MuleSoft's June post. We could not confirm from public pages on 12 October that all the Q3 items had shipped. Treat each as unproven until you see it in your tenant.
One discrepancy to check: the June post names Microsoft Copilot Studio for the July A2A Bridge release. A later release note or post may read differently, so confirm which platforms are supported in your tenant before you design around either.
A stop control only helps if you have drilled it. Our kill switch post has the drill.
What would we check in the first week?
Five things, in this order, before any agent touches a system of record.
- 01List every agent that will touch the process, from every vendor, and the systems each can reach. If it is not on the list, nobody can stop it.
- 02Mark each regulated step as a fixed rule with a named owner. Leave the model only the messy-input steps.
- 03Ask for each Q3 control in your own tenant, with a date. Anything not shown works only on paper.
- 04Run a stop drill in a sandbox and time it. Write down every place someone lacked access.
- 05Send one write through an agent from outside your platform and read the log. If it does not show the named user, the agent is not governed yet.
Our founder taught the Dreamforce 2026 breakout "Agent Fabric: See, Control, and Govern Every Agent" on 16 September (see our Dreamforce 2026 page), and has put 200+ agents into production. This post is that thinking, written for Gulf teams. We have not yet run the outside-vendor identity test above on a client system, so we have not claimed a result for it.
At Mindcat, we start the same way for any agent work: read what already touches the process, write down what is worth fixing, then build around it. You get a written note, not a dashboard.
This is not for you if no agent touches a real system yet. Start with the process, not the platform. We also do not replace your counsel on UAE and Saudi data rules, or your tax adviser on the e-invoicing dates.
