Skip to content

Everyone has a demo. Fewer ship.

AI that answers from your live data, respects who may see what, and never acts without approval. Arabic and English, wired into the systems you already run.

Live
your real data
AR+EN
one conversation
Gated
human approval
Open
standards

The hard part is not the model.

Getting a language model to say something impressive takes an afternoon. Getting it to answer correctly from your database, in front of a regulator, without emailing a customer by accident, is the actual work.

8 tools
defined in our agent layer
2 ERPs
connected: Odoo and Dynamics
MCP
open standard, no lock-in
AR + EN
both, in one conversation

Demo versus production

A demo answers a question. Production answers to an auditor.

Most AI pilots die in the same place: the gap between a convincing conversation and a system anyone will let near real customers, real money and real records.

It invents things

A model with no grounding will produce a confident number that does not exist in your data.

It sees everything

If the assistant ignores permissions, one question exposes salaries, margins or a competitor's pricing.

It acts unasked

An agent that can send is an agent that will send, at some point, to the wrong person.

Nobody can explain it

"The AI said so" survives exactly one conversation with a regulator or a board.

  • Start where being wrong is cheap, not where it is catastrophic
  • A narrow assistant that works beats a broad one that impresses
  • If the data is a mess, AI makes the mess faster, not smaller
  • Some problems are a report, not a model — we will say so
The four things we build in first

Grounding, so answers come from your records. Permissions, so the assistant sees only what its user may see. Approval gates, so nothing leaves without a human. And an audit trail, so every answer can be traced back to the query behind it.

The distinction that matters

A chatbot answers. An agent does the work.

This is the whole difference, and most vendors blur it. Ask both the same thing and watch what happens next.

  • Chasing receivables with correct invoice references
  • Qualifying inbound enquiries before a human picks them up
  • Extracting supplier documents into records
  • Compiling the answer to a recurring management question
What an agent needs to be useful

Tools it can call against your real systems, a definition of what it may and may not do, memory of the conversation, and a gate before anything leaves the building. Remove any one of those and you are back to a chatbot with better manners.

Connected, not copy-pasted

It reads your database. Not a copy of it.

  • Natural-language questions over live business data
  • Answers cite the records they came from
  • The assistant runs as a user, with that user's permissions
  • No parallel copy of your data to secure and keep in sync
  • Open standard, so you are not locked to one vendor

Why open standards matter here: the connector is not a proprietary bridge only we can maintain. If you replace us, the wiring stays.

Live
queried at the moment asked
Scoped
runs under user permissions
Cited
answers reference records

The part imported products get wrong

Your team does not speak in one language.

Real Saudi business conversation switches mid-sentence: an Arabic message with an English product code, a WhatsApp reply that starts in one language and finishes in the other. Systems built elsewhere treat that as an error.

  • Understanding that does not break at the language boundary
  • Replies in the language the customer used, not a default
  • Arabic that reads as written by a person, not translated
  • Product codes, numbers and units preserved exactly
  • Right-to-left handled as engineering, throughout

Where this is decisive: customer-facing automation. An assistant that answers Arabic in stilted, obviously-machine phrasing damages the brand more than having no assistant at all.

Both
in a single message
Native
not translated output
Preserved
codes and numerals exact
RTL
engineered, not patched

Where Saudi business already happens

The channel your customers already answer on.

  • Quotations, confirmations and payment reminders with real references
  • Approve and ask buttons that write back into the record
  • Every message logged against the customer, searchable later
  • Arabic and English templates, pre-approved by Meta
  • An agent that drafts; a person who releases
Official
Business API, not a workaround
Logged
every message on the record
Gated
drafted, then approved

The quiet cost centre

Somebody is retyping a PDF right now.

Supplier invoices, delivery notes, purchase orders, contracts. They arrive as documents and leave as data — and in most companies a person is the conversion layer.

  • Bad scans stay hard; we set a confidence threshold, not a promise
  • Low-confidence extractions go to a human, not into the ledger
  • Every extraction keeps a link to its source document
  • Start with your highest-volume supplier, not all of them
Where the value actually is

Not the typing — the checking. A person retyping an invoice is not comparing it to the order. Extraction that also reconciles is what catches the wrong quantity and the price that quietly changed.

What was said, at scale

Nobody listens to a thousand calls.

Sales and support conversations are the richest data a company generates and the least used, because reviewing them costs a manager's week. Transcription and analysis turn them into something readable.

  • Which objections come up repeatedly, and where deals stall
  • Whether the team is actually saying what training said
  • Summaries and next actions written straight into the CRM
  • Sentiment and escalation risk, flagged while it still matters
  • Arabic and English handled in the same pipeline
Say this to your team first

Recording and analysing conversations is a people question before it is a technical one. We build it with disclosure, retention limits and role-based access from the start, because deployments that surprise staff get quietly sabotaged, and rightly so.

AR + EN
one pipeline, both languages
Into CRM
summaries where work happens
Disclosed
built for staff transparency
Retained
with limits, not forever

The part that gets it approved

AI proposes. People decide.

  • Read-only, draft-only, or act-with-approval — chosen per action
  • Outbound messages queue for release, never send silently
  • The assistant inherits the permissions of the user asking
  • Every action logged: who asked, what ran, what was returned
  • A kill switch that a non-technical manager can reach

This is also the compliance answer. When a regulator or auditor asks how a document was produced, the trail is the answer — not a description of how the model works.

Gated
nothing sends unreleased
Scoped
user permissions apply
Logged
query and result retained

Where the data goes, and which model sees it

Two questions your board will ask first.

Before capability, most Saudi buyers want to know where their data physically sits and who the vendor behind the model is. Both answers should be a decision, not a default.

  • Cloud regions inside the Kingdom where the platform offers them
  • Regional hosting where in-Kingdom is not available
  • Self-hosted open models where data must never leave your estate
  • Retention and logging policies set per deployment, in writing
  • Frontier models for reasoning-heavy work and Arabic quality
  • Smaller, cheaper models for high-volume classification
  • Open models when residency or cost dictates it
  • The architecture stays the same; models are swappable
What we will not do

We will not tell you a model is "secure" as though that settles it. The questions that matter are where the data rests, who may read it, how long it is kept, and whether it trains anything. Those get written into the engagement, not assumed.

Written
residency stated per deployment
Swappable
models are not the architecture
Self-host
available where required
Retention
policy set, not default

The unglamorous half that pays for itself

Most of what people want is not an AI problem.

A large share of the work we are asked to solve with AI is a plumbing job: a form that should create a record, a file that should reach a folder, a reminder nobody sends. Deterministic automation does it cheaper, faster and without a probability attached.

  • The rule can be written down completely
  • The same input must always give the same output
  • The step is high-volume and low-judgement
  • An error must be impossible, not merely unlikely
  • The input is unstructured — language, documents, speech
  • The rule exists but nobody can fully articulate it
  • The variety is too wide to enumerate
  • A confident draft for a human beats a blank page
  • Onboarding and offboarding checklists that run themselves
  • Approval routing with escalation when nobody responds
  • Document filing, naming and retention
  • Reminders that reference the actual outstanding item
Our platform doctrine

Make.com for service-to-service flows, Power Automate inside Microsoft estates, self-hosted tooling where volume or data residency requires it, and custom code only when no-code genuinely does not fit. The tool is chosen after the problem, not before.

Our own platform, stated plainly

We built the pattern before we sold it.

Rather than describe an architecture in the abstract, we built one: a multi-tenant conversational agent that answers business questions from a live ERP over WhatsApp. It is our platform, not a client deployment, and we would rather say that than imply otherwise.

  • Proves: the architecture runs, end to end, against real ERPs
  • Proves: multi-tenant separation and tool-calling work as described
  • Does not prove: scale under a large customer's load
  • Does not claim: a named client running it in production today
The detail we are most pleased with

When a backend is not connected, the platform returns clearly flagged sample data and the assistant says so in its reply. It is a small thing that reflects a rule we apply everywhere: a system should never let you mistake a demonstration for the truth.

Tobrecards

Tobrecards · United States · Generative AI

A product where the AI is the product.

Image gen
AI pipeline
Text gen
personalised copy
Layout
print-ready output
Platform
web application
The brief
  • ·Generic cards; no personalisation at the point of purchase
  • ·Design effort required per card, limiting range
  • ·Output needed for both digital delivery and print
What we built
  • ·An image-generation pipeline producing card artwork
  • ·Personalised message generation from the buyer's input
  • ·A layout engine composing print-ready and digital output
  • ·The surrounding web platform and API
What it demonstrates
  • ·Generative AI inside a real product flow, not a demo
  • ·Output quality controlled well enough to print
  • ·A pipeline, not a single model call
Why this matters to you

Generative work is judged by its worst output, not its best. The engineering here is in the constraints — templates, validation and fallbacks — that keep the range acceptable every time, not just in the screenshot.

Setaro · Germany · Process automation

The unglamorous kind that pays for itself.

Workflows
cross-tool automation
Knowledge
structured workspace
Sync
data across systems
No-code
maintainable in-house
The starting point
  • ·Work spread across tools that did not talk to each other
  • ·Information re-entered by hand between systems
  • ·Knowledge held in individuals rather than a shared base
What we built
  • ·Automation workflows connecting the existing toolset
  • ·A structured workspace as the shared source of record
  • ·Cross-tool data synchronisation replacing manual re-entry
  • ·Documentation so the client's own team can extend it
What changed
  • ·Steps that were somebody's routine now run unattended
  • ·One place to look rather than three to reconcile
  • ·The client can maintain and extend the flows themselves
Why this matters to you

No model was involved and none was needed. This is the work that quietly returns hours every week, and it is usually where we suggest starting before anything is pointed at a language model.

Enterprise AI platforms · Anonymised

Two platforms, under agreement.

Chatbot
customer-facing
Knowledge Q&A
over company content
Documents
automated generation
Speech
call analysis
Platform one
  • ·An intelligent assistant handling customer conversation
  • ·Question answering across the company's own knowledge
  • ·Automated generation of proposal documents
  • ·Session capture to see where users actually struggled
Platform two
  • ·Analysis of recorded calls at a volume no manager could review
  • ·Structured scoring of candidate interactions in hiring
  • ·Question-and-answer analysis across conversations
Why they are anonymous
  • ·These engagements are covered by confidentiality
  • ·The website presents them the same way, unnamed
  • ·Scope is verifiable in a reference conversation
Why this matters to you

We would rather show you an unnamed engagement described accurately than a named one described loosely. If a supplier's case studies never carry a constraint, ask what else has been smoothed over.

Small, reversible, measured

Start where being wrong is cheap.

The failed AI projects we are asked to rescue share a shape: too broad, too central, and impossible to evaluate. We deliberately start at the edge and move inward.

011 week
Find the candidate

A task that is repetitive, language-shaped, and where a wrong answer is caught by a human before it costs anything.

02with scoping
Agree the measure

Before building, we write down what "working" means and how it will be judged. If we cannot define that, we do not start.

033–6 weeks
Pilot in the open

Real users, real data, drafting only. They keep the judgement; we watch where it fails and fix what actually breaks.

04at review
Widen or stop

Either the measure moved and we extend, or it did not and we say so. Both are acceptable outcomes; only pretending is not.

What running it costs

AI has a per-use cost that traditional software does not, and it is the part most proposals leave vague. We estimate it per conversation or per document before you commit, and design to keep it predictable — smaller models for volume, larger ones only where judgement is needed.

  • Where does my data rest, and does it train anything?
  • What happens when the model is confidently wrong?
  • Can it act on its own, and who can stop it?
  • What does this cost per use at our volume?
  • What do we own if we replace you?

The next step

Bring the question your team keeps answering by hand.

Send us a message