Senior backend & AI platform engineer.
I build the unglamorous Python that
LLM products actually run on.

The problem

Fleet operators see anomalies — fuel events that don't match GPS distance, repair invoices without supporting photos, the same vendor showing up across suspicious approvals — but investigation is manual, slow, and political. Operators need a co-pilot that surfaces the question and walks them to an answer.

What I built

• React + Anthropic API prototype — structured prompts grounded in fleet-domain context, not a generic chat wrapper.
• Investigation flow — the agent walks operators through fuel events, GPS traces, inspection history, repair records, vendors, and approval evidence in sequence.
• Evidence summarization — pulls supporting documents, OCR'd receipts, and field-captured photos into a single timeline per anomaly.
• Next-action guidance — recommends "approve / investigate further / reject" with explicit reasoning, not vibes.

Why the plumbing matters

The reason this demo worked is the layer beneath it: ingestion, metadata, validation, audit trails, OCR/document capture, async processing, and retrieval-friendly data modeling — RAG foundations in everything but name. LLM products are only as good as the structured ground truth they sit on.

The problem

African fleet operations live in WhatsApp. Drivers, mechanics, and supervisors send voice notes, photos, and casual messages — none of which make it into a system of record. Forcing them into a separate app fails. Meeting them in the channel they already use, but turning chaos into structure, works.

What I built

• Multi-actor flows — distinct conversational paths for drivers, mechanics, and supervisors, each with their own state machine.
• Structured capture — inspections, repair requests, receipt and photo evidence, approval steps, and live status updates routed into Postgres as queryable records.
• Validation layer — reject incomplete submissions, enforce evidence requirements, and escalate edge cases to humans.
• Backend workflow state — Python services with proper idempotency, retry, and audit logging on every state transition.

Why it mattered

It collapsed three SaaS subscriptions (tracker + maintenance log + driver comms) into one operational layer. Field staff didn't change behavior; the data model did the work.

The problem

Operators bleed money on fuel skimming, duplicate repair claims, and vendor collusion — but generic alert systems flag everything and become noise. The signal lives in the joins: fuel events vs GPS distance, inspection history vs current report, vendor frequency vs approval pattern.

What I built

• Cross-domain anomaly logic — joining fuel events, GPS/telematics traces, inspection history, repair records, vendor metadata, and approval evidence.
• Statistical baselines per dimension — vehicle, driver, route, vendor — so an "outlier" is contextual, not global.
• Evidence-backed flags — every alert links to the source records that triggered it, viewable in one click.
• Tunable noise floor — thresholds operators can adjust as they learn what their baseline actually is.