The rules are the asset

The question has moved on

Most organisations are past the question of whether to use agentic AI. Teams are already using it, usually faster than the policy that was meant to cover it. The interesting question is now a harder one.

An agent that writes code, reads systems and takes actions is not a tool in the way a spreadsheet is a tool. It accumulates context. It learns the shape of your estate. It acquires working knowledge of your conventions, your architecture and your decisions. Within a few months, a serious agentic setup holds a meaningful amount of institutional memory.

Almost nobody is backing that up. Almost nobody can say who is allowed to change it. And almost nobody has written down the rules the agent is supposed to work inside.

WAJD Group builds with agentic AI every working day, across a portfolio spanning manufacturing and supply chain systems, defensive security, formulation, medical device pre-production and learning platforms. This paper sets out what we have learned about governing it, and what we now run for other organisations as a managed service.

Rules, not prompts

A prompt is advice. It applies to one conversation and then it is gone. A ground rule is a law: it has a number, a reason, a place to live, and it outlives the session that created it.

Our ground rules sit in plain text, versioned, read at the start of every session and cited by number when they apply. A few of the ones we work under:

• Own the runtime. Anything a production system depends on at request time must be ours. No third party AI in the path where the material is sensitive. When a project needed QR encoding and the only route was an external dependency, we wrote the encoder instead, because taking the dependency would have broken the rule.
• No camera, ever. No facial analysis, no emotion inference. Enforced as a header the application cannot switch on, rather than a paragraph in a privacy notice.
• Close every loop. Any action gated in the interface must also be gated on the server. If the button is hidden, the endpoint still has to refuse.
• Isolation. An agent working in one system does not touch a neighbouring one, however obvious the fix looks.

None of these are sophisticated. What makes them work is that they are written once, referenced by name, and enforced by tests rather than by good intentions.

Encode the rule as a test, not a paragraph

This is the most transferable lesson we have, and it is the difference between governance that survives a refactor and governance that does not. Prose in a policy document has no defence against a well meaning engineer six months from now. A test does.

In one platform the rule was that a credential must be earned rather than bought, and commercially there was constant pressure to soften it. The resolution was not to soften it but to split the object: money can buy access to the training, and can never grant the qualification. That intent is now held in place by a test that fails if any purchasable item ever becomes capable of granting a pass.

In another, an agent acts on a person's behalf, so the authority boundary was written before the features. It may act on anything safe and reversible. It must ask when an action touches another person, spends an allowance or commits the user. And there are things it may never do at all, whatever permission is granted.

A test inspects the function signature and fails if a wallet parameter is ever introduced. A second scans the module for any action name containing a financial or credential term. That second test caught our own naming mistake within a day of being written, which is the entire argument for writing it.

Rules make pivots cheaper, not slower

The common objection is that governance slows delivery. Our experience is the opposite, for a reason that is not obvious until you have lived it.

Because a rule required every capability to ship behind a switch from day one, changing strategic direction became a configuration change rather than a deletion. Two substantial features were parked in an afternoon: the navigation entry disappears, the endpoint refuses, and entering the address by hand routes the user home. The code and its tests remain intact for the day the strategy changes back.

Organisations without that discipline face a worse choice every time priorities move. Delete the work and lose it, or leave it live and accumulate risk.

Let the agent correct your numbers

A well governed agent is not only a builder. It is a check on your own reasoning, and it is worth deliberately pointing at the assumptions you like most.

On one commercial model we had been quoting a ninety three percent gross margin. Working through the unit economics under a rule that requires outcomes to be reported faithfully, the agent showed that the figure was the margin on a paying user, while the serving cost lands on every active user. At realistic conversion the model lost money per user, and break even sat at roughly double a normal freemium rate.

That correction changed a commercial strategy. It is much better found in your own kitchen than in front of an investment committee.

Never let it grade its own visible work

Two failures taught us this, and both passed every automated check that existed at the time.

An audio processing component scored well against a simulated environment and then degraded a real microphone, because the echo path on real hardware arrived far later than the filter could observe. Simulation was not evidence.

Separately, a trained component produced entirely plausible output while having no effect whatsoever. The only way to prove it was to run the identical input with and without the component and compare the results byte for byte. A single good looking result cannot detect the failure mode "this did nothing".

The lesson generalises well beyond AI. Any component whose output looks reasonable by construction needs a test designed to catch it doing nothing at all.

Several clocks at once

The reason we invest in this discipline is that agentic systems are heading into operations, and operations is where weak governance becomes expensive rather than embarrassing.

Our work on autotwins takes that seriously. The network twin assembles itself from purchasing, ERP and logistics records. The asset twin is learned largely from operating history rather than modelled from first principles. The agentic twin reasons on the live twin and acts within guardrails. The prefix is load bearing: self assembling, self synchronising, self checking, with fidelity measured and published, and a twin that degrades loudly rather than quietly.

Alongside it we build hierarchical reasoning engines deliberately kept small: five recurrent cells of roughly three hundred thousand parameters each, updating at periods of one, two, four, eight and sixteen steps. Each level reads the level below as evidence and the level above as context, and each predicts its own input one period ahead, so it trains without labels and without any third party model in the loop.

The idea is the schedule rather than the scale, and it maps onto how a business actually runs. A machine stoppage is a second by second problem. A shift roster is daily. A supplier contract is quarterly. A plant investment is a five year commitment. A system that reasons on one timescale will always be the wrong instrument for at least three of those. That is the same argument we make in agentic AI in operations.

The exposure nobody has budgeted for

If your teams are using agentic AI seriously, then somewhere in your organisation there is a laptop holding conversations that document decisions, prompts that took months to get right, project context an agent needed weeks to accumulate, tool permissions and configuration nobody has written down, and, if you are doing it well, the ground rules themselves.

Ask three questions about that material.

• Is it backed up? Usually not, or only incidentally, inside a personal cloud account.
• Can a new starter be productive on day one? Or do they begin from an empty context and rebuild months of accumulated understanding by hand?
• Can your security team say who may change the rules the agent works under, and produce a record of what changed and when?

For most organisations the honest answers are no, no and no. That is not an argument against adoption. It is an argument for treating agent context as what it now is: a business record, with the same retention, recovery and access expectations as any other.

What WAJD Group provides

We run this as a managed service, so your teams keep moving and the risk stops accumulating.

• Automated backup of AI working context. Conversations, prompts, project context, agent configuration, tool permissions and the ground rules themselves, captured on a schedule rather than when somebody remembers.
• Recovery you have actually tested. Restore a working agent environment onto a new machine, for a new starter, or after a loss, and prove it with a rehearsal rather than assume it.
• Storage in your tenancy or ours. Where the material is commercially sensitive it does not go to a third party cloud at all. We build and run self hosted setups precisely because some organisations cannot put their internal material anywhere else.
• Ground rules as governed artefacts. We draft your rule set with you, version it, put it under review, and enforce it with tests in your build pipeline so it cannot quietly erode.
• Authority boundaries in code. The act, ask and never model, implemented and tested against your risk appetite, so the limits on an agent's autonomy are enforced rather than described.
• An audit trail. Who ran what, when, under which rules, and what changed as a result, in a form your security and compliance functions can read without needing to understand the tooling.
• Assurance reviews. Secrets exposure, permission scope, prompt and context leakage, dependency risk, and the failure modes that pass automated checks while doing nothing.
• Enablement for IT and security. The practical training that lets those teams support agentic AI at scale, so their answer to a new request is a considered yes rather than a defensive no.

The point of all of it is to reduce operational risk without slowing innovation. Governance that costs a week and saves a quarter is a good trade. Governance that stops delivery gets bypassed, and a bypassed control is worse than no control, because it produces confidence without protection.

The first thirty days

We keep the shape deliberately simple.

• Week one, discovery. Where agents are already in use, what context exists, where it lives, and what is currently recoverable. This is almost always broader than the sponsor expects.
• Week two, rules. A first ground rule set drafted with your engineering and security leads, numbered, with reasons attached, and agreement on which ones are hard.
• Week three, enforcement. Backup and recovery in place and tested. The hard rules encoded as checks in your pipeline. The audit trail switched on.
• Week four, handover. Your teams running it, with a recovery rehearsal completed and a review cadence agreed.

After that we run it as a managed service, or we step back and you run it yourselves. Both are good outcomes. We would rather leave you with a capability than a dependency.

Where this stops

Backing up agent context does not make an agent safe, and no rule set removes the need for judgement. A rule can only be enforced where there is a system boundary to enforce it at, which means work done outside your estate stays outside your governance. Encoding rules as tests catches regression, not intent. And an audit trail tells you what happened, which is worth a great deal and is not the same as preventing it.

What this does do is convert a category of risk that is currently invisible into one that is measured, owned and recoverable. That is a smaller claim than the market usually makes, and it is one we can evidence.

Related work

The operational side of this argument is in agentic AI in operations, and the twin it acts on is in autotwins. The engine where these guardrails run against a live supply chain is WAJD Forge.