AI agents that finish the job, not just answer the question
An agent differs from a chatbot in one respect that matters: it takes actions in your systems. Crux builds agents with defined authority limits, approval gates on consequential steps, and a complete record of what was done and why.
- Receive Supplier invoice arrives in the shared inbox
- Plan Agent decomposes: extract, match to PO, check tolerance, route
- Act Reads the invoice, queries SAP for the purchase order
- Observe Variance is 4.2% — above the 2% auto-approve threshold
- Escalate Routes to a human approver with reasoning attached
- Log Every step written to the audit trail, reviewable later
What separates an agent from a chatbot
Agentic AI — الذكاء الاصطناعي الوكيل — describes software that pursues a goal rather than answering a prompt. A chatbot returns text. An agent decides on a sequence of steps, calls real systems to carry them out, reads what came back, and adapts. The difference is not intelligence. It is authority: an agent can change data in your ERP.
That is the whole engineering problem. Giving software the ability to act is straightforward. Constraining what it may act on, proving afterwards what it did, and stopping it cleanly when it goes wrong — that is the work, and it is where most agent pilots quietly stall before production.
Every agent Crux deploys carries an explicit authority boundary: which systems it may write to, which value thresholds it may clear alone, and which actions always require a named human approver. That boundary is agreed with the process owner before a line of code is written.
Why pilots stall
Almost never because the model was not capable enough. Usually because nobody could answer what happens when it is wrong, who signs off on that risk, or how an auditor would reconstruct a decision six months later. Those questions are cheaper to answer at design time than after a board asks them.
Where agents earn their keep, and where they do not
We turn down agent projects that fall in the right-hand column. A deterministic script is cheaper to build and cheaper to trust.
- Multi-step work where the next step depends on what the last one returned
- Unstructured input — documents, email, free text — that rules cannot parse reliably
- High volume where exceptions are the minority and can be escalated
- Processes spanning several systems that have no single owner
- Work where reviewing a recommendation is faster than doing it from scratch
- Anything with a correct answer a rule can compute — VAT, interest, eligibility maths
- Single-step lookups, which are an API call, not an agent
- Irreversible actions with no practical approval gate
- Processes nobody has documented, where the agent would encode the confusion
- Work where a wrong outcome cannot be detected before it causes harm
Five things that sit between the model and your systems
This layer, not the model, is what makes an agent safe to run in production.
-
Task decomposition
A goal becomes an ordered plan of steps with declared dependencies, so a failure at step three does not silently corrupt step five.
-
Tool and system access
Each agent gets scoped credentials — read here, write there, nothing else. Access is granted per tool rather than per agent, and revocable independently.
-
Authority limits
Numeric and categorical thresholds define what may proceed unattended. Above the line, the run pauses for a named approver rather than guessing.
-
State and memory
What the agent learned during a run persists across its steps; what it should not retain — personal data under PDPL — is scoped and discarded deliberately.
-
Audit and replay
Every decision, tool call and input is recorded, so any outcome can be reconstructed months later during an audit or an incident review.
Where Saudi enterprises deploy agents first
Sector shapes the workflow. Regulatory context shapes the authority limits.
| Sector | Typical first agent | Approval gate |
|---|---|---|
| Banking | Document review in onboarding and KYC packs | Any exception or adverse finding |
| Government | Citizen request triage and routing across departments | Anything affecting entitlement |
| Healthcare | Prior authorisation preparation and payer follow-up | Every clinical determination |
| Energy | Maintenance work order drafting from sensor anomalies | Any shutdown or safety action |
| Telecom | Network incident triage and first-line diagnosis | Customer-facing credits |
| Logistics | Shipment exception handling and re-routing | Cost above a set threshold |
One workflow first, and it has to survive contact with reality
Roughly 8 to 12 weeks to supervised live operation for a first agent.
-
2 weeks
Readiness review
We map candidate workflows against the fit criteria above and return a shortlist — with an honest column for the ones that should stay deterministic.
-
1–2 weeks
Authority design
Thresholds, approval gates, system scopes and the halt procedure, agreed with the process owner and whoever signs off on risk.
-
5–7 weeks
Build and shadow run
The agent runs alongside the existing process without acting, so its decisions can be compared against what your team actually did.
-
3–4 weeks
Supervised release
Live, with every action approved by a human, until the approval rate stabilises and the exceptions are understood.
-
Ongoing
Widen the boundary
Authority extends step by step against measured performance, never by default.
Answered plainly
What is agentic AI, in practical terms?
An agent is software that pursues a goal across several steps, choosing which tools to call and adapting to what those calls return. The practical difference from a chatbot is that it acts inside your systems rather than producing text about them.
How do you stop an agent doing something expensive?
Authority limits, set before the build. Numeric thresholds and categorical rules define what may proceed unattended; everything above the line pauses for a named human approver. There is also an immediate halt capability, tested before production rather than assumed.
What happens when an agent gets it wrong?
It will. The design assumption is that mistakes are detected and reversed cheaply — shadow running before live release, approval gates on consequential actions, and a full decision trail so any outcome can be reconstructed and the cause fixed.
Do agents work with Arabic documents and interfaces?
Yes, with deliberate handling. Arabic document processing, dialect variation between Gulf Arabic and Modern Standard Arabic (اللغة العربية الفصحى), and bidirectional text in interfaces are specified during design rather than assumed to work.
How does this satisfy SDAIA and PDPL requirements?
Accountability, data residency and explainability are architectural rather than documentary. Every decision carries a trail, memory scope is defined against PDPL retention rules, and workloads run on Saudi cloud regions. Compliance is demonstrable rather than asserted.
How long before an agent is doing real work?
Roughly 8 to 12 weeks to supervised live operation for a first workflow, including the shadow-run period. Extending authority beyond that is deliberately gradual and driven by measured performance.
Find out which of your workflows should not be an agent
A two-week readiness review assesses candidate workflows against the fit criteria and returns a shortlist — including the ones we would advise against automating this way.