Write down how the work really runs before you add an agent. An agent needs five things it cannot invent for itself — written rules, company memory, checks, a decision log and set permissions — and the quickest way to build them is on one process, with the people who do it.

Most organisations that try AI agents start with the agent. They pick a tool, connect it to the inbox or the accounting system and ask it to help. The first results look good. Then the agent does something nobody expected, nobody can say why, and the pilot quietly stops.

The problem is rarely the model. The agent was asked to work in an organisation whose rules live in people’s heads, whose approvals happen in chats, and whose history of decisions is not written anywhere. A new employee in that situation would ask colleagues. An agent guesses.

So preparing for AI agents is mostly preparing the organisation, not choosing the agent.

What an agent needs that it cannot invent

We call the set of things an agent stands on its harness. It has five parts. Each one answers a question the agent would otherwise have to guess.

1. Written rules. What is allowed here? Payment limits, who signs what, which supplier needs which check, how fast a customer must get a reply. If a rule is not written down, the agent cannot follow it, and you cannot check that it did.

2. Company memory. What happened before? The contract with this supplier, the last three complaints from this customer, the reason the price changed in March. People carry this in their heads and inboxes. An agent needs it in a place it can read, with the source of each fact.

3. Checks. How do we know the work is right? The same checks a careful employee makes: does the invoice match the order and the delivery, is the counterparty still in good standing, is the amount within the limit. A check that is written once can be run by an agent on every case.

4. A decision log. Who decided, and why? Every decision on record: who made it, when, on what grounds, from which sources and under which version of the rule. Without it you cannot audit an agent, hand work over, or teach the agent from past cases.

5. Permissions. What may this agent do alone? Read, suggest, draft, record, act: each a separate right, given to each agent separately, with a named person who owns it. Money, law, signatures and anything sent outside the organisation stay with people.

None of these is about AI. They are what a well-run organisation has anyway. Agents simply make the gaps visible faster, because they cannot fill them with common sense.

A quick test: which parts do you have?

You can check your own organisation in ten minutes. For one process you know well, answer five questions honestly:

• Where are the rules for this process written? In a document people actually use, or in the heads of two senior staff?
• If a key person left tomorrow, where would their knowledge of past cases be?
• Which checks are made before the work moves on, and are they written as steps or done by feel?
• Can you find who approved a specific case last month, and on what grounds, in under five minutes?
• If an assistant joined this process tomorrow, would anyone know exactly what they are allowed to do alone?

Every “no” is a part of the harness that is missing. That is normal. Very few organisations have all five for even one process. The point of the test is to know where you stand before an agent is asked to work there.

On our harness check you can answer six such questions with buttons and see which parts of your frame exist, with first steps for the gaps.

Why start with one process

The usual reaction to the test is to plan a big programme: write down all the rules, clean all the data, then bring in agents. That takes a year and rarely finishes.

It works better the other way round. Take one process that hurts — payments that wait days for a signature, customer requests that get lost between email and chat — and build the whole harness for that process only.

Here is how it looks on a fictional company. Zarvane Trading Group pays its suppliers through a chain of people: a buyer confirms the delivery, an accountant matches the invoice, the finance director approves, the treasurer pays. Payments often wait.

Mapping this one process with the people who do it shows:

• The rules exist, but in three versions: the policy document, what the finance director actually applies, and what the accountants remember. The first job is to agree on one.
• The memory is spread between the accounting system, email and a shared spreadsheet of “special” suppliers. It gets one place, with sources.
• The checks — invoice against order and delivery, supplier still in good standing, amount within limit — are written as steps for the first time.
• The decision log starts with the next payment: every approval records who, when, why and under which rule.
• The permissions are set: an agent may match invoices and prepare the case for approval; it may not approve or pay.

After that, an agent has something to stand on. It checks every invoice the same way, shows its sources, and hands the decision to the finance director with the case already prepared. The person still decides. The difference is that they decide on a checked case instead of a pile of documents.

The Invoices module is built around exactly this flow, and counterparty checks cover the “still in good standing” part.

Who needs to be in the room

Preparing one process is not an IT project. Three groups need to take part:

• The people who do the work. They know where the real rules differ from the written ones. If they are not asked, the map describes how the work should run, not how it does.
• The owner of the process. Someone has to decide which version of a rule is the right one. Disagreements will come up; that is the useful part.
• Whoever is accountable for the risk. Usually finance or legal. They decide what an agent may never do alone.

In our own work we collect what already exists — documents, system records, conversations — and then check it with these people in short facilitated sessions, question by question, until the process is agreed. We describe this on the page about our approach.

Common mistakes

Buying the agent first. Tools are easy to buy and hard to stop. Without the harness, every result needs a person to check it from scratch, so the time saved is small and trust drops quickly.

Writing rules nobody uses. A rule document that the team does not recognise will be ignored by the team and followed by the agent, which is worse. Rules must be agreed with the people who apply them.

Treating permissions as all-or-nothing. Either the agent is “on” and does everything, or it is “off”. In practice each capability needs its own level, starting low and rising only with a record of good work.

Skipping the decision log. It feels like paperwork until the first audit, the first handover or the first time an agent makes a strange choice. Then it is the only thing that helps.

Where to start this week

1. Pick one process where work waits or gets lost.
2. Run the five-question test above with the people who do it.
3. Write down, on one page, the rules as they are really applied today.
4. Decide who owns the process and who decides on risk.
5. Only then ask what an agent could prepare in it.

If you want a second pair of eyes, bring the process to us. We map it with you — every step, who does it, where it waits and which steps an agent could prepare while your people decide. The process review is free.

Give an AI agent permissions one capability at a time, on a ladder of five levels — read, advise, draft, record, execute — and start every capability low. An agent moves up a level only after a record of approved work and a decision by its named owner. Money, law, signatures and anything sent outside the organisation are always approved by a person.

The question we hear most often about AI agents is not “how clever is it?” but “what will it do without asking?” It is the right question. An agent that can only read is safe and not very useful. An agent that can do everything is useful until the first mistake that nobody saw coming.

The answer is a ladder of permissions, applied to each thing the agent can do, and climbed slowly.

The five levels

Every capability of an agent sits on one of five levels.

The higher the level, the stricter the permission, the checks around it and the record it leaves. Reading needs access rights. Executing needs all of that plus a person’s approval for anything that matters.

Permissions belong to capabilities, not to agents

The common mistake is to give an agent one level for everything: it is “allowed to draft” or “allowed to act”. Real work does not split that way.

Take a fictional company, Zarvane Trading Group, and its agent that helps with supplier payments. It does several different things, and each sits on its own level:

• matching an invoice against the order and the delivery — record: it marks the match itself, because the check is mechanical and fully on record;
• checking the supplier is still in good standing — advise: it raises a warning, a person reads it;
• preparing the payment for approval — draft: the finance director sees a ready case and decides;
• sending the payment — not given at all: a person pays.

One agent, four capabilities, four different levels. When the agent proves itself on matching, that capability can move up. The payment capability does not move just because matching went well.

What always stays with a person

Some things never move up the ladder to “execute alone”, however good the record:

• money — approving and making payments;
• law — anything that commits the organisation legally;
• signatures — contracts, official letters, documents signed in the organisation’s name;
• anything sent outside — to a customer, a bank, a regulator or another agency.

Inside the organisation an agent can do a great deal by itself: keep internal records, prepare drafts, set tasks for itself and for colleagues. The line is drawn where the action leaves the building or cannot be undone.

On our platform this is how the work is built, so nobody can switch it off on a busy day: the step that sends money or commits the organisation has a person at it.

How an agent moves up a level

An agent earns a wider permission in the same way a new employee does: by doing the work under supervision until the record shows it can be trusted. In practice that means four conditions.

1. A named owner. Every agent has a person who answers for it. That person, not the agent and not the vendor, decides whether a capability moves up.

2. A record of approved work. The agent works at its current level on real cases. Every draft it prepares is either approved as it is, corrected or rejected, and all three are on record. The owner looks at that record, not at a demonstration.

3. A test on agreed cases. Before a step up, the capability is run on an agreed set of cases with known right answers, including the awkward ones: the duplicate invoice, the supplier who changed owners, the request in the wrong language.

4. A step-by-step rollout. A new level is tried first in a test setting, then on a limited share of real work, then in normal operation. At each stage someone knows how to stop it.

A typical path for one capability looks like this: an agent starts by drafting replies to customer status questions, and a person sends each one. After enough replies were sent without changes, the owner allows it to send standard status updates by itself. Replies on complaints, prices or deadlines still go through a person.

What to write down for every agent

Before an agent works anywhere, it should have a short passport. Ours has six parts:

• Task — whom it helps, at which step, with what result.
• Input — which records and fields it may see, from which sources, and how fresh they must be.
• Output — what it hands over: a warning, a draft, a record, with links to the evidence.
• Permissions — separately for read, advise, draft, record and execute, per capability.
• Human decision — who approves its result, where that is recorded, and what the agent does when it is unsure or rejected.
• Checks — the test cases, the expected results, how its work is observed and how it is stopped.

An agent that is not on the register with such a passport does not work on any process. That one rule removes a whole class of surprises.

Agents may propose rules, not change them

There is one more boundary worth stating. An agent sees a lot of cases and often notices that a rule is outdated: a limit that is always exceeded, a check that never finds anything. It should say so. It should not change the rule.

A new working rule takes effect only after a person with the authority for that kind of decision approves a new version of it. The agent’s observation becomes a proposal on the owner’s desk, with the cases that support it. That keeps the organisation’s rules in people’s hands, and it keeps the decision log honest about who changed what.

Questions to ask any AI vendor

If you are choosing an agent platform, these questions show quickly whether permissions are taken seriously:

1. Can I set a different permission level for each capability of one agent?
2. Who is named as the owner of each agent, and where is that shown?
3. What happens when the agent is unsure — does it stop and hand over, or guess?
4. Which actions can never run without a person, regardless of settings?
5. Can I see the record of approved, corrected and rejected work behind a step up?
6. How do I stop one capability without stopping the whole agent?

If the answers are vague, the agent will be too.

You can see the ladder at work on our trust page, or assemble a team of agents for one of your processes and watch which permissions each of them gets.

Yes. An agency can run AI agents on its own servers, with local models doing the routine reading, matching and drafting, and with the core of the work — the queue, the process steps, the records and the decision log — running even without an internet connection. An outside model is used only if the agency allows it, for a hard text task, and names, contacts and amounts are masked before anything leaves. Officials make every decision.

For a government agency, the first question about AI is where the data goes. Applicants’ details, internal correspondence, decisions under review: most of it should not leave the agency’s environment, and some of it must not leave the country.

That rules out a lot of AI tools, which send every request to a model run by a foreign company. It does not rule out AI agents. It means designing the work so that what matters stays inside and whatever leaves does so on the agency’s terms.

Three zones: always inside, may leave, never leaves

The clearest way to think about it is to sort everything into three zones.

Always inside. The working core of the agency: the queue of cases, the steps of each procedure, the records of what was done and with what evidence, the handovers between officials, and the decision log. This part must work every day, including when the internet connection is down. AI makes it faster; it must not make it fragile.

May leave, with conditions. A small number of hard text tasks — summarising a long submission, drafting a complex reply — may sometimes go better with a stronger outside model. They go out only if the agency has allowed it, only after the identifying details are masked, and every such call is on record.

Never leaves. The real names, contacts and amounts behind a masked request, the checks on money, the decision itself, and the official’s signature.

What runs inside the agency

On the agency’s own servers, a full working setup looks like this:

• The platform itself — desks for each role, the procedures as steps, the records, the decision log. Installed in the agency’s environment from the same code as everywhere else, with the agency’s data and administration fully separate from any other customer.
• Local models — open models running on the agency’s hardware. They do the routine work: reading incoming requests, finding the applicant and the file, matching documents against registers, drafting standard replies.
• Every check on money — budget lines, amounts, limits. These run inside with the real figures, never on masked data and never outside.
• Connections to the agency’s systems — registers, document storage, email — through the agency’s own network.

None of this needs an outside service to keep going. If the internet is switched off, cases still arrive, agents still prepare them, officials still decide and everything is still recorded.

How an outside model is used, when it is allowed

Suppose the agency has allowed an outside model for one kind of task: drafting replies to long, complicated complaints. Here is what happens on a fictional case at the Department of Trade Services:

1. A complaint arrives. A local model reads it, finds the applicant’s file and the rules that apply.
2. The drafting task is judged too hard for the local model. Before anything leaves, the text is masked: the applicant’s name becomes “Person A”, the phone number is hidden, the amount becomes “Amount X”.
3. The outside model drafts a reply about “Person A” and “Amount X”. It never sees who the person is or how much is at stake.
4. Back inside, the real name and amount are put back. Any check on the amount runs inside, on the real figure.
5. The official reads the draft, with the rule and the sources attached, edits it if needed and approves it. The reply goes out under the official’s name.
6. The outside call, the masking and the approval are all on record.

The agency can switch the outside model off completely at any time. Then nothing crosses the border, and the work continues on local models alone. You can watch this exact path, with the switch, on our trust page.

Who is accountable

Keeping data inside is half of the question. The other half is who answers for the result.

The answer has to be simple: officials. Agents prepare cases, check documents against registers and draft replies. A person decides. Every decision is recorded with who made it, when, on what grounds, from which sources and under which version of the rule. That record serves internal audit, the handover of a case between officials, and the improvement of the agents themselves.

Agents also work within set permissions. Each agent has a named owner, starts with narrow rights, and earns wider ones only from a record of approved work. Anything that leaves the agency — a reply to an applicant, a letter to another agency — is approved by a person first. We describe this ladder in detail in how an AI agent earns permissions.

How this fits the UAE’s public direction on AI

The UAE has set out its ambitions for AI in public documents, and an agency choosing an AI setup will be asked how it fits them. Three are worth knowing:

• The UAE Strategy for Artificial Intelligence names boosting government performance at all levels among its aims, and providing services through AI among its themes.
• The UAE Charter for the Development and Use of Artificial Intelligence lists twelve principles. Among them are data privacy and human oversight, with the charter stressing the value of human judgement over AI.
• In Dubai, the Dubai Universal Blueprint for Artificial Intelligence, launched in April 2024, included appointing a Chief AI Officer in every government entity, and in June 2024 22 Chief AI Officers were appointed across Dubai government entities.

An on-premises setup with local models, masking at the border, people as the deciders and a full decision log is a practical way to put those principles to work inside one agency. SORP is an independent company; we refer to these public documents and do not claim any government endorsement.

Questions to settle before the first pilot

Before any agent works inside an agency, a few things should be decided on paper:

• Where exactly will it run? Which servers, in which data centre, administered by whom.
• Which local models, on what hardware? The routine work depends on them, so they must fit the agency’s own capacity.
• Is an outside model allowed at all? If yes, for which tasks, and who approved that.
• What is masked? At minimum names, contacts and amounts; often reference numbers and addresses too.
• Who owns each agent? A named official for every one.
• What is the first area? One flow — customer requests, the Director General’s instructions, a procurement step — not the whole agency at once.

The last point matters most. A pilot inside the agency’s own environment, on one flow, with the agency’s own officials deciding, shows more than any presentation. It is also the honest basis for a tender later.

On the government page you can see five flows an agency usually starts with and try the Director General’s office desk on fictional cases. If you lead the change in your entity, the Chief AI Officer kit drafts a briefing note for your first area and lists what the procurement pack holds.