Taabi's alerting agent compiles an English sentence into a rule document a plain engine executes

The document the model produces is where the whole safety property lives. In a dev.to write-up of the build, the platform's engineer says the LLM's only job is translating a manager's sentence into a rule document, and a plain engine executes that document ^[4]. The example printed in the post carries five top-level keys, trigger, where, aggregate, actions and throttle, against the six the text describes ^[5]. In plain words that example means drowsy above 60 km/h twice in ten minutes, tell the manager, and if still drowsy ten minutes later, call the truck ^[6]. Throttling is a one-hour cooldown keyed on the vehicle number ^[7]. The schema is a Pydantic v2 model exported as JSON Schema and as TypeScript types, so the engine, the simulator, the plain-words summary in the UI and the evals all point at the same definition ^[8].

The first attempt was to let the model read the sentence and act. "That's a chatbot with side effects, and nobody is going to let one ring their drivers," the engineer wrote ^[9]. What replaced it is a LangGraph graph with two interrupts, which stops and asks when the sentence is missing a threshold or a channel ^[10]. A draft has to clear the schema and about thirty semantic checks written in code, with errors fed back to the model for up to three repair attempts ^[11].

Then the draft is replayed over the tenant's last seven days and comes back with a count: "would have fired 27 times, 58 held back by the throttle" ^[12]. Add those up: 85 candidate firings, of which the throttle suppressed 68 percent ^[21]. The same replay caught a rule that would have fired four thousand times ^[13]. By construction that number describes one fleet's last week, so it does not transfer anywhere; what carries over to another fleet is a tenant history long enough to replay against.

Approval leaves the rule sitting as a draft. Activating is a separate button in a separate service behind a role check, and the authoring agent has no tool that can press it ^[14]. The engineer stopped calling it human in the loop and started saying "this is where the state machine stops" ^[16]. Calls follow the same shape: only the notifier places a call step, uncertain calls wait in a queue for a manager, and every call ends with follow-ups a person closes ^[15]. The activation service behind a role check is the part I would copy first.

The most instructive bug was in the prose. "At most one call per vehicle per hour" came out of the composer as a cap per rule, which in this schema means one call per hour for the entire fleet ^[17]. The schema was fine; the English summary a manager approves allowed both readings, and it now says exactly what the schema means, because that summary is what people read ^[18].

Latency forced the second architecture. A yes-or-no decision inside a live phone call went through the full agent subprocess and took 18 to 30 seconds, most of the call; one direct Messages API call with a tight output schema took 1.2 seconds ^[19]. The gap is 15x to 25x ^[20]. For the 1.2 seconds to hold on someone else's stack you would need the same shape: one request that skips the tool loop and the memory fetch, with an output schema narrow enough that one pass validates.

On real trucks there is engine noise under every word the driver says, Hindi speech recognition that is fine on the agent's own lines and shaky on the driver's, and no way for the agent to see that the belt actually went on ^[22]. So the agent asks yes-or-no questions, treats an unclear answer as unconfirmed, and re-checks the alert stream after the call ^[23].