Ten systems that run without us in the room.

Repeat medical-supply orders arrived as WhatsApp photographs of prescriptions, printed, handwritten, creased, badly lit. Every one had to be read by a person and retyped into the ERP. It was slow, it happened outside office hours, and a mistyped NHS number or quantity is a clinical problem, not just an admin one.

The agent reads the script image and extracts patient, NHS number, script number and every line item. It then holds a real conversation about the order: the customer can say "actually make it 6", "that's not aproderm, it's tegaderm film 12x12", or "also add 10 atrauman", and the order updates. It resolves products and account codes against the live CIN7 catalogue, reads the order back, and raises it once the customer confirms.

It handles the awkward cases too: splitting a script when the patient wants more than the prescribed quantity (the extra becomes a separate sales order), recording NHS exemption codes, and tracking whether an electronic script has been returned to the NHS Spine.

Three independent controls, because in a regulated medical context a confident wrong answer is worse than no answer.

• The model is never the last word on a number. NHS numbers carry a Modulus-11 check digit, so a misread is caught arithmetically. The EPS barcode is decoded independently and cross-checked against what the model read.
• Every generated reply passes an output guardrail. The agent may rephrase verified facts naturally, but it is blocked from stating a price, a stock level, an ETA, or anything clinical. A rejected reply never reaches the customer: it falls back to a fixed template or goes to a human.
• It never invents. The vision step is instructed to return null and flag the field as unclear rather than guess, so "I couldn't read this" is a first-class outcome that triggers a follow-up question.

The engine ships with a send-mode ladder: observe processes every message and logs what it would have sent, without sending; approve queues replies in an outbox and a human taps Send on each one; auto is full production.

You watch it work on your real traffic for as long as you like before it is allowed to speak to a customer. Autonomy is earned, not switched on at launch.

Orders arrive the way customers already communicate, no portal, no app, no training, no office hours. Staff stop retyping prescriptions, and the only conversations that reach a person are the ones that genuinely need judgement. Orders are created in CIN7 as drafts, never auto-authorised, so the warehouse still reviews before anything ships.

Vehicle enquiries arrive on WhatsApp at all hours and most of them are the same questions: which models are available, what the spec is, what it costs to get into one. Reps answered them manually during business hours. Enquiries that landed on a Saturday night were answered on Monday, by which time the buyer had messaged three other dealerships.

Handles model, spec and availability questions in natural conversation, qualifies the buyer, captures the lead, and routes it to the right rep with the full thread attached. The rep opens a conversation that already has context instead of a bare phone number and a callback request.

• Message debouncing. People type on WhatsApp the way they think, three short messages in a row. Naively, that is three prompts and three replies. The agent waits a configurable beat, merges the burst into one turn, and answers once, properly.
• Conversation state survives restarts. History, leads and de-duplication live on a persistent disk, so a redeploy in the middle of a conversation doesn't lose the thread.
• A dry-run switch. The same observe-before-you-send discipline: the agent can run against live traffic with sending disabled while you read what it would have said.

A buyer who gets an accurate answer at 11pm on a Sunday is still a buyer on Monday. Deployed in Frankfurt, the closest region to South Africa, behind a health check, so response times stay conversational.

Leads arrive in every format a human can produce: a screenshot of an enquiry, a photo of a business card, a handwritten note, a forwarded email, a web form, a WhatsApp thread. Someone has to read each one and type it into the CRM, and the same person then has to read supplier quotations and pull the numbers out.

You drop in whatever you have and it returns a structured lead: name, email, phone, company, what they want, where they came from, budget if stated, and the notes a salesperson would actually want: deadlines, context, who referred them. It reports which fields it genuinely found rather than silently filling blanks. It also reads quotations and writes a short plain-language brief on any lead so a rep can pick it up cold.

"You read a quotation and report what is on it. You do not do arithmetic and you do not tidy the numbers."

That line exists because of a real bug. In South African formatting, R7 200,00 is seven thousand two hundred rand, but a model that "helpfully" normalises separators reads it as seventy-two thousand. An order of magnitude, on a price, in a quote going to a customer. Stopping the model from reformatting numbers is what fixed it.

It removes the most error-prone step in quoting: a human retyping numbers off a PDF. The errors it removes are the expensive kind. Effort is tuned per route, light for a summary, heavier for extraction, so it stays fast and cheap where accuracy is not at stake.

Onboarding requires checking a photographed South African ID. Image-forensics approaches, does this look edited?, generate false positives on ordinary bad photographs, and you cannot explain a rejection to a real customer with "the model thought it looked wrong".

Extracts the fields from the document image, then tests the document's internal consistency rather than its appearance. A calibrated decision engine combines the vision read with the deterministic checks and returns a score with stated reasons.

• Check digit. The 13-digit SA ID number (YYMMDD SSSS C A Z) carries a Luhn check digit. An invented or tampered number fails deterministically, no judgement involved.
• Embedded date. The first six digits must be a real date and must agree with the date of birth printed elsewhere on the document.
• Barcode cross-check. What the barcode encodes is compared against what the model read off the face of the card.

Vision models are confident when they are wrong. Arithmetic is not. These checks carry far lower false-positive risk than any image-forensics signal, because they test facts about the document rather than opinions about the photograph, and every rejection comes with a reason a compliance officer can read.

Death-benefit and estate claims are submitted as a bundle of scanned documents from different sources, in no particular order. Packs are routinely rejected weeks later for a missing certificate or an inconsistent ID number, and the family waits again.

Ingests the unsorted pile, classifies each document by type, extracts the fields that type carries, validates identity numbers, applies the claim rules, and assembles the pack, with a report naming exactly what is still missing and what contradicts what.

Rules address fields through canonical semantic keys, deceased.id_number, employer.name, rather than the field names on any particular form. A rule written once works on any document that maps a field to that key.

Onboarding a new insurer's forms therefore means writing a field mapping, not rewriting the validation logic. Universal rule packs run against every claim; each document type declares which additional packs apply to it.

Claim packs fail on omissions. Finding the omission before submission costs an email. Finding it after costs a resubmission cycle and, for the family, another month.

The South African used-vehicle market is spread across a dozen listing sites, each with its own naming. The same car is a different string on every one. Without a shared identifier you cannot compare two listings, let alone price against the market.

Continuously scrapes the major listing sources, maps every vehicle to its M&M code, the South African industry standard identifier, so like is compared with like, enriches against TransUnion data, and serves pricing to both a web dashboard and a mobile client.

• Identity resolution is the product. The hard part is not fetching listings, it is deciding that two differently-worded adverts are the same variant. The M&M mapping and backfill pipeline is where most of the engineering sits.
• Pricing decisions are logged and learned from. Assessments are recorded so the pricing model improves against outcomes rather than staying a fixed formula.
• Model routing by task. Cheap models handle bulk classification; stronger ones handle the analysis that justifies a number.

A buyer or a dealer gets a defensible price with the comparable evidence behind it, instead of a gut feel and three browser tabs.

An advisory firm's real knowledge, who introduced whom, what was agreed, which deal a valuation belongs to, lives in individual inboxes. It is invisible to everyone else and it leaves when the advisor does. But mail is also the most access-sensitive asset the firm holds, so "just index it" is not an option.

Extracts entities and relationships from years of correspondence, resolves which mentions refer to the same client, deal or product, and holds the result as a knowledge graph rather than a pile of embeddings. Compliance packs are generated from the same source of truth.

Deals are re-detected from scratch on every processing cycle, so any wobble in a computed key used to spawn a duplicate card. A registry now maps each deal to a stable canonical identity that survives across cycles.

Similarity alone cannot do this. Two different clients who share a surname produce nearly identical text, no similarity threshold separates them. Structure does: different advisor, different account, no shared email thread. The graph gives an answer with a reason attached, which is what a compliance reviewer actually needs.

Institutional memory becomes searchable across the firm without widening who can see what: access is enforced per advisor, so each user queries only their own book, and the model cannot be talked into exceeding that scope.

Deciding where to open a padel venue, or what to charge, needs demand data. Club directories tell you where courts exist. They do not tell you whether anyone is booking them, and no platform publishes utilisation.

Discovers every club in a target country along with its courts, amenities and opening hours, then snapshots bookable availability twice a day across a rolling window, each club in its own local calendar, which matters across a country spanning multiple timezones.

• Availability is not occupancy. Platforms advertise bookable slots at their real durations, 60, 90 and 120 minutes, often several overlapping at the same start time. Counting them gives a meaningless number.
• Normalised into fixed cells. Each court-day is normalised into fixed cells across the club's operating hours, producing an occupancy figure that is comparable between clubs, cities and weekdays.
• Two snapshots a day. A morning reading before play starts and a later one capture how a day fills, which is the difference between "this club is busy" and "this club sells out on Tuesday evenings".

The platform's API began returning 403 Request blocked to all ordinary clients, with or without a proxy. Rather than escalating an arms race, the collector was rebuilt to read the same data the way the public website does. The pipeline kept running; the dead module is still in the tree, documented, so nobody rediscovers the problem.

Client context was split across Outlook, the calendar, a task list and WhatsApp. Generic CRMs handle contacts well and portfolios badly, and reporting on assets under management meant a spreadsheet someone maintained by hand.

Pulls mail, calendar and tasks through Microsoft Graph with delegated and application access, tracks clients and portfolios, and brings WhatsApp conversations into the same inbox as email. Deployed as containers on Azure alongside the intelligence pipeline.

The same holding is recorded three different ways across three systems, so assets under management were being counted more than once. Matching them requires exclusion rules that treat naming variants correctly, down to whether an underscore counts as a word boundary, which was a real bug with a real correction.

An AUM figure is only useful if advisors trust it, and they only trust it if they can see how it was derived.

Reconciling outstanding backorders against pick lists was a manual cross-check between a PDF and the ERP, done by warehouse and sales staff who are not developers and should never need to be.

Reads the pick PDFs, reconciles outstanding backorders against CIN7, and produces the paperwork the warehouse needs, from a desktop application with an icon, installed from a Windows installer.

The people who need it can run it. No terminal, no Python install, no developer on standby, which is the entire difference between a tool that gets used and one that gets abandoned. It carries the most thorough automated test suite in the portfolio, so a change to the pick-list format is caught before it reaches the warehouse floor.