Investor brief · 6 November 2026
A governed process layer for the organisations that cannot use the cloud.
Rygor is a customer-hosted agentic process platform for regulated organisations in the Gulf and Egypt. This brief states the opportunity, the company, the edge, the model and the honest status. It is written to survive diligence.
1. The opportunity
Process automation is changing in kind, not degree. For twenty years the category connected systems with scripts and forms; now it is beginning to coordinate agents that read, draft and propose. The organisations with the most to gain are public bodies, banks and operators whose work is undocumented, approval-heavy and regulated. They are also the organisations least able to adopt hosted AI: the data cannot leave, the decision cannot be unexplained, and the vendor cannot be a dependency.
The resulting segment, governed agentic process automation that the customer hosts and operates, is under-served because it is hard: it requires durable execution, an authority model that sits outside the AI, offline operation, and bilingual work as a first-class concern. We believe that difficulty is the moat.
We do not publish a top-down market size. The buyers we target procure through enterprise security and procurement processes, and the honest unit of opportunity is one operational team with one process, inside one installation, expanding from there.
2. What Rygor is
Rygor takes undocumented business work through guided discovery, a reviewed executable process and a generated workspace, then coordinates people, rules, governed agents and admitted system actions to an evidenced outcome. It runs as one compact installation inside a customer-controlled boundary, on premises or in the customer's own cloud account, and is designed to operate fully disconnected, in Arabic, English and mixed-language work.
Three design decisions define it:
- One authority. Every consequential step, whether proposed by a person, a rule, an agent or an external system, passes through the same command boundary with the same permission check. A model's output is a proposal or evidence, never an action.
- Honest effects. Recorded, applied and verified are kept as separate facts. An uncertain external write is held and reconciled, never blindly retried.
- Evidence that outlives the platform. Each case closes with a signed evidence pack designed to be verified offline, without access to Rygor.
3. Why we can win
Our edge is a set of positions on trade-offs that most of the category has made the other way. We never name competitors; we describe the trade-offs.
| Where the category usually lands | Where Rygor stands |
|---|---|
| The model calls tools directly; guardrails are added around it. | Authority sits outside the model, enforced at every read, search, export and action. |
| "On-premises" runtime with design, AI or updates depending on a vendor cloud. | The whole lifecycle is designed to work disconnected, operated by the customer's IT, with signed offline updates. |
| Arabic as a translation layer on an English product. | Modern Standard Arabic, English and mixed work, right-to-left layout and Hijri dates in the design from discovery to evidence. |
| Business users describe; integrators build; change is a project. | Business users describe, review, rehearse and publish; customer IT installs and operates. No customer-specific code. |
| Usage-metered pricing per token, per step or per seat. | A customer-hosted licence with maintained releases. No metering, no phone-home, no runtime expiry. |
None of these is unique on its own. The position we are building is the complete, customer-operated lifecycle, and we treat "faster, cheaper or better than the category" as a claim to be earned with measurement, not asserted.
4. Business model (hypothesis)
A proprietary, customer-hosted licence or subscription with maintained releases, signed offline updates and business-hours vendor support, with the customer's IT as first responder. The charging unit, price points, term and renewal are deliberately unselected until a design partner tells us how they buy. Two positions are already fixed: no charge per token or per agent step, and no charge for occasional participants such as approvers.
Go-to-market is sequential and narrow: one flagship team and one process; a second process in the same installation; then adjacent teams, sectors and countries. The product code is proprietary; delivered third-party components are open source.
5. Where we are, honestly
Rygor is an early engineering build with a complete product design and a single founder operating it. As of 6 November 2026:
| Area | Status |
|---|---|
| Product design | Complete baseline: 39 requirements, 10 bounded process families, 3 reference processes (access requests, supplier onboarding, invoice exceptions). Architecture, contracts and security model decided. |
| Built | Durable execution core (admission, interpreter, approval, correction, dispatch, closure, restore); bilingual workspace with right-to-left layout; model roles, document ingestion and permission-filtered retrieval; a first bounded insight agent. |
| Running | One development installation on synthetic data, operated by the founder. A hand-checked pass on 6 November covered sign-in, starting, closing and cancelling cases, Arabic layout and a mobile view. Upgrades are admitted only after open cases replay without failure (247 replayed, 0 failed, on the current build). |
| Not yet | No customer, revenue or production deployment. 0 of 39 requirements formally accepted; no measured quality, latency or capacity figures. Case-step agents and the coordinating agent are not built. Arabic text is machine-written and not yet reviewed by native speakers. No continuous integration pipeline. |
| Team | Founder-led. Background and references are shared in the briefing. |
We publish this because our customers will be asked the same questions by their regulators, and because a company that claims more than it has measured cannot credibly sell a platform whose promise is that claims and evidence are kept apart.
6. What the next twelve months must prove
- One design partner. An operational team with a real process, shaping the product in exchange for early access and influence.
- One controlled pilot inside a customer boundary. On the customer's hardware, with acceptance criteria agreed in advance. Our aim is early 2027; it is an aim, not a commitment.
- Measured bilingual quality. Arabic and English discovery and document reading scored against a published standard, including native-speaker review.
- Independent acceptance. The requirements register accepted by someone other than the people who built the platform.
A seed conversation with us is a conversation about funding those four results, and about the team that delivers them.
7. Contact
- bono@abuelnour.com
- Diligence
- On request we share the product requirements, architecture overview, current-state record and the test and replay evidence behind every figure on this site.
- Status date
- 6 November 2026. This brief is updated when the status changes, not before.