Two systems we run look nothing alike on the surface. One posts jobs and screens candidates for a national brand. The other schedules field ambassadors for a beverage company. Underneath, they share the same rule, applied without exception: the model explains, scores, extracts, or drafts, and something deterministic decides. Not because the model is weak. Because operational software has to be designed for the day any component is wrong, and a model is the component most likely to be wrong on any given day.
We did not arrive at this rule from a framework or a safety paper. We arrived at it from building two production systems that would have failed differently, and worse, if we had let the model touch the parts it should not touch.
The state machine is the system; the AI is staff
The recruiting operation runs on a thirteen-status candidate state machine kept in Google Sheets, deliberately boring, deliberately auditable by a team with no engineering background. A Claude coordinator reads that state, scores candidates, drafts outreach messages, and answers questions from the operations team over Telegram. But state only changes through defined transitions in the sheet, never through anything the model writes directly. The model is staff. It proposes. It does not get to move a candidate from screened to hired on its own authority.
Every irreversible action in that system, posting a job, sending outreach, extending an offer, stops at a human approval gate in Telegram with the message shown inline for editing before anything leaves the building. There is no code path around the gate. Approval takes seconds. A bad automated message sent to an entire candidate pool cannot be recalled once it lands. We chose the seconds every time.
Explaining a schedule is not the same job as writing one
The field operations platform draws the same line in a different place. Shift assignment for ambassadors runs on a deterministic scheduling engine: a pure function over six documented signals, availability, performance, distance, reliability, fairness, and familiarity, producing a reproducible score for every candidate shift. Claude's job is to explain the draft schedule the engine already produced, in prose an operations lead can skim, under a fifteen-second hard timeout with a deterministic fallback if it does not answer in time.
That timeout is the detail that tells you the design is serious. If the model is slow, or down, or simply wrong that day, scheduling does not even slow down. The shifts still publish. The only thing that degrades is the prose explaining them. We built it this way because we wanted a specific property: a component failure in the AI layer should never be able to become a component failure in the operation itself.
Why explaining is the durable role
Explaining, scoring, extracting, and drafting share a property that deciding does not: they are all checkable against something else before they cause an effect in the world. A drafted outreach message can be read before it sends. A relevance score can be shown with its evidence. A schedule explanation can be wrong without changing who works which shift. A decision that fires directly, a job posted, a message sent, a shift silently reassigned, has already had its effect by the time anyone notices it was wrong.
This is not a claim that today's models are unreliable in some special way ours are not. It is a claim about operational software generally: every component in a system that runs unattended will be wrong sometimes, whether it is a model, a script, or a person having a bad day. The systems that survive are the ones designed around that fact rather than around the hope that it will not happen. Gates and deterministic fallbacks are cheap to build. Recalling a hire, an outreach blast, or a week of wrong shifts is not.
What this means for the AI you are adding next
Before letting a model touch a workflow, ask where its output lands. If it lands as a draft, a score, an extracted field, or an explanation that a person or a downstream deterministic system reviews before anything irreversible happens, the model is doing the job it is reliably good at. If its output can directly cause a hire, a payment, a public post, or a schedule change with nobody in the loop, the question is not whether the model is good enough yet. The question is why the irreversible step has no gate at all.
The two systems behind this essay are documented in full, architecture diagrams included, at /work/recruiting-agent and /work/field-operations.
Talk this through with the author
A Systems Strategy Session is thirty minutes on the architecture of your operation, with the engineer who wrote this.