The engineer behind
the systems.

I build the systems businesses run their operations on, so my first question is never which AI model to use. It is what happens at two in the morning when the model is wrong.

That is the whole distance between a demo and something you can put real customers through: retries, idempotency, a database that refuses to hold a broken state, and a human approval gate on anything that leaves your building. Across 114 workflows in production I keep roughly 1,600 error handlers. Nothing publishes, sends or dials until someone presses approve, and every system ships with dry-run as the default.

My deepest work is in fire protection, where an estimate is worthless unless it cites the code it came from. Our US engine classifies hazard to NFPA 13 by the density and area method, sizes standpipes to NFPA 14, pumps to NFPA 20, alarm to NFPA 72, and takes height and sprinkler thresholds from the International Building Code, flagging anything that needs a licensed PE rather than guessing at it. But none of that is really about fire safety. It is about any operation where the same expensive judgement gets made by hand every day: an estimate, a follow-up call, a compliance check, a report three people rebuild from four systems every month.

If you want to test me, ask about the boring part. One of my dial queues had a conflict clause that looked correct and did nothing, so the same customer could be called twice. Catching that is the job. Kratu AI Labs is deliberately small, so you deal with the person who designs your system and is accountable when it breaks. Send me the workflow you dread most and I will tell you what I would automate, what I would leave alone, and whether AI belongs anywhere near it.