Technology
One reference architecture behind every system we build.
Models are the easy part. Orchestration, context and controls are the work.
RCPT-4F2A19
Renewal outreach sent
- ContextCRM account record, read 11:04 UTC · Last 40 days of activity, 62 events · Renewal date and contract value
- AuthorityClosos · revenue agent · L4 · Bounded autonomy
- PolicyOUTBOUND-03 · named accounts, business hours, one touch per week
- ActionAuto, inside boundary. Owner notified.
- Result1 email queued to the economic buyer, CRM task created.
- EvidenceRecall window 15 minutes. Task deletable. Full input snapshot kept.
If it cannot be proved and undone, it should not be automatic.
The output of the Trust Layer, written at the moment of action.
Operating loop
Understand, Decide, Act, Prove, Learn.
Play the loop. Each station shows the check that fires there.
Reference architecture
Five layers, spanned by trust.
Identity, policy, evidence and approval cut across every layer.
- 01
Experience Layer
Role-adaptive interfaces, workflows and approval surfaces. What a person actually sees and signs.
- Role-adaptive UI
- Workflows
- Approvals
- Review queues
- 02
Orchestration Layer
Agents, routing, planning and policy-aware execution. The part that decides what happens next and whether it is allowed.
- Agents
- Routing
- Planning
- Policy-aware execution
- 03
Intelligence Layer
Foundation models, domain reasoning, retrieval, classifiers and evaluators, selected per task, not per vendor relationship.
- Foundation models
- Domain reasoning
- Retrieval
- Classifiers
- Evaluators
- 04
Context Layer
The organisation's real substrate: systems of record, communication and knowledge. Context is what separates a demo from a deployment.
- CRM / ERP
- Data stores
- Email & calendar
- Documents
- Knowledge
- 05
Measurement Layer
Evaluations, performance, cost, adoption and outcome feedback: the evidence that a system is worth its autonomy.
- Evaluations
- Performance
- Cost
- Adoption
- Outcomes
Trust Layer
Identity, permissions, policy engine, evidence, audit, human approval and rollback, spanning every other layer rather than sitting beneath them.
- Identity
- Permissions
- Policy engine
- Evidence
- Audit
- Approval
- Rollback
Shared primitives across every system
Context fabric
One place a system reads the world from: records, documents, signals and history, resolved and current.
Executable policy
Rules written as controls the runtime enforces, not a PDF someone is meant to remember.
Action runtime
The layer that actually does things, inside boundaries, with a reversal path for anything consequential.
Trust Receipts
A signed record of what was done, on what basis, under which rule, and who could undo it.
Evaluation harness
Continuous scoring against the outcome that matters, so drift shows up before a customer finds it.
One stack, six systems. Conceptual view of shared components.
Trust Layer
- Identity
- Permissions
- Policy engine
- Evidence
- Audit
- Approval
- Rollback
Autonomy model
Autonomy is allocated per action, not per product.
Consequence and reversibility set the level.
L3 · Act with approval
The system executes, but only after an explicit human approval on the specific action.
Different actions within the same system can run at different autonomy levels, based on risk, confidence and reversibility.
L3
Act with approval
Governance load
52
The system executes, but only after an explicit human approval on the specific action.
The system may
Executes the specific approved action.
A human still
Approves that exact action first.
Evidence written
Approver, policy matched, result.
Governance load is an illustrative index, not a measured figure. Autonomy is set per action, so one system usually runs at several levels at once.
Canonical autonomy model. Referenced everywhere else on this site.
Conceptual model
Value rises with autonomy, and so does the governance requirement.
Conceptual illustration of the relationship we design around. It is not derived from measured data.
More autonomy can unlock more operational value, but governance and evidence must rise with it. Autonomy is only defensible where the evidence layer is genuinely in place. Conceptual illustration of a design principle, not measured data.
Evidence
What a system writes when it acts for you.
Pick an action and read the receipt it produces.
Every consequential action writes one of these as it happens, not afterwards.
RCPT-4F2A19
Renewal outreach sent
- ContextCRM account record, read 11:04 UTC · Last 40 days of activity, 62 events · Renewal date and contract value
- AuthorityClosos · revenue agent · L4 · Bounded autonomy
- PolicyOUTBOUND-03 · named accounts, business hours, one touch per week
- ActionAuto, inside boundary. Owner notified.
- Result1 email queued to the economic buyer, CRM task created.
- EvidenceRecall window 15 minutes. Task deletable. Full input snapshot kept.
If it cannot be proved and undone, it should not be automatic.
In a working session
Bring one decision path and we will show you the architecture running against it.
Technical principles
Non-negotiables.
01
Model-agnostic by design
Models are components, not architecture. Task, cost, latency and risk decide which model runs, and the choice can change without rebuilding the system.
02
Human control where consequence demands it
Autonomy is allocated per action, calibrated to consequence and reversibility rather than applied as a single global setting.
03
Least-privilege tool access
An agent receives the narrowest possible access to the smallest necessary set of tools, scoped to the task in front of it.
04
Traceable actions and evidence
Every consequential action carries its inputs, the policy it matched, the approver and the result. Traceability is produced by execution, not bolted on.
05
Reversible automation where technically possible
Where an action can be undone, the reversal path is designed before the action is permitted.
06
Evaluation before and after deployment
Systems are evaluated before release and monitored after it. Regression is treated as a first-class risk.
07
Context over generic prompting
Performance in production comes from grounded organisational context and retrieval design, not from cleverer instructions.
08
Security and governance in the workflow
Controls live inside the execution path rather than in a parallel review process that runs after the fact.
The thesis
The next generation of software will not wait to be asked. It will understand, decide, act, and prove what it did.
We’re building that generation from Dubai’s DIFC, for organisations that have to answer for what their systems do.