Most AI maintenance tooling is sold on how much it does without you. That is a strange pitch for a work order, because a work order is not a convenience — under 49 CFR 396.3 a motor carrier has to keep a record of inspections, repairs and maintenance showing their date and nature, held for a year and for six months after the vehicle leaves its control. So an agent that creates work is writing into a regulated record. The interesting question was never whether it is clever enough to skip the approval. It is whose name is on the entry when somebody asks. Watch an agent draft a job and stop.
The Agent Drafts the Work Order. Then It Stops.
For maintenance managers and fleet compliance leads: why the approval gate is a records requirement rather than a training-wheels phase, why rejections are worth more than approvals, and why the list of things our agents may do alone is deliberately empty.
A Work Order Is a Record Before It Is a Task
This is the part that gets skipped in demos of automated work order creation. The output is not a to-do item in a productivity app. It is an entry in a file a federal auditor can ask to see.
Records must include "a record of inspection, repairs, and maintenance indicating their date and nature", and be "retained where the vehicle is either housed or maintained for a period of 1 year and for 6 months after the motor vehicle leaves the motor carrier's control."
— 49 CFR 396.3(b) and (c)
Read that as a design constraint rather than a compliance chore and it settles the architecture question immediately. If the agent writes and nobody signs, the record shows work that appeared on its own. That is not a gap an auditor will find interesting — it is a gap they will find confusing, and confusion in a records review is expensive. The approval is not there to babysit the model. It is there so the entry has an author.
Oversight Is Not Optional in the Frameworks Either
The governance standards that maintenance software will eventually be measured against say the same thing in more general language.
"Processes for human oversight are defined, assessed, and documented in accordance with organizational policies."
"Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use."
Both from the NIST AI Risk Management Framework. Note what MANAGE 2.4 actually asks for: not just an off switch, but assigned responsibility for using it. An agent nobody is named against is an agent nobody can turn off on the day it starts being wrong — and that day arrives for every model eventually.
What the Agent Has to Show You Before You Can Decide
An approval gate is only meaningful if the person at it has enough to judge with. A proposal that says "recommended: service unit 418" is not a decision you can make, it is a decision you are being asked to rubber-stamp, and a gate that produces rubber stamps is worse than no gate at all — it manufactures an author for a record nobody actually reviewed.
Unit number, not a database ID. If the approver has to look something up to know which truck this is, the gate has become admin.
"Air leak, front service line" rather than a code or a confidence score. The approver is a maintenance person, not a data scientist.
Not the model's internal logic — the observable trigger. A failed inspection item, twice running, is a reason. "Anomaly detected" is not.
The actual inspection records, readings or photographs it read. If the evidence cannot be opened from the proposal, the approver is trusting the summary rather than checking it.
The work order as it will be written, editable before it is committed, so approval means agreeing to a specific thing rather than to a direction.
An uncertain reading is never quietly rounded into a suggestion. It appears held, with the reason attached, and cannot be selected — because a guess in a system of record is worse than a gap.
Where Our Agents Actually Sit
Autonomy is a ladder, not a switch, and honest software tells you which rung it is on.
Rung one is the whole product today. Nothing runs unattended, and the list of actions any agent may take alone is empty — not as a staged rollout narrative, but because the evidence for unlocking an action is a record of that agent being right about that action, and that record has to be accumulated before it can be read. The screen shows how often each agent was right, computed from approvals and rejections rather than claimed in a brochure.
The Six Agents, and Which Ones Real Events Reach
Two of six are wired to live events. The other four propose against the record. Stating that is more useful than implying all six are equivalent. Swipe on mobile.
| Agent | What it drafts | Status today |
|---|---|---|
| Maintenance | Drafts a work order with the fault, the asset and the reason | Triggered by real events |
| Dispatch | Proposes a plan against trucks in the yard and drivers verified | Triggered by real events |
| Battery | Flags batteries heading for failure before a no-start | Proposed, not yet event-triggered |
| Audit | Reads documents and raises what does not reconcile | Proposed, not yet event-triggered |
| Safety | Surfaces patterns across defects, inspections and incidents | Proposed, not yet event-triggered |
| Executive Copilot | Answers questions against the record rather than a dashboard | Proposed, not yet event-triggered |
The four marked as proposed are on the build list rather than in the product, and a page that blurred that line would be doing exactly what this one argues against. If you are evaluating vendors, the question worth asking is which agents fire on an event versus which run when somebody opens a screen — the answer changes what the feature is worth entirely.
In thirty minutes: the agent reads the inspection record, drafts the job with its reasoning attached, and stops. You approve or reject it and we show you what the record then says — including the rejection log, which is the screen most demos skip.
How FleetRabbit Handles This
Four moments, and the second one is the design decision everything else follows from.
A work order with the fault, the asset, the reason and the evidence it read. Nothing is created yet.
Not a countdown, not a default-yes after ten minutes. It waits. A form that fills itself silently is one nobody trusts twice.
Approve creates the work. Reject does not. Either way it took a human action and the record knows which.
Who approved, when, and what the agent had proposed. That is the part an auditor asks for.
Why the Rejections Are the Valuable Half
Approvals tell you the agent agreed with a person. Rejections tell you where it is wrong, which is the only information that improves anything.
Free, specific, and generated by the person best placed to judge it. Most software throws this away by treating a decline as a dismissed notification.
An agent rejected 40% of the time overall is less interesting than an agent rejected almost every time on trailers and almost never on tractors. The second is a fixable scope problem.
You cannot responsibly let an agent act alone on an action without a record of its judgement on that action. The rejection log is that record. No log, no unlock.
An accuracy figure read out of approvals and rejections can be checked. One that arrives in a sales deck cannot. Ask any vendor where their number comes from.
The Failure Modes Worth Asking a Vendor About
Every approval workflow degrades in one of a few predictable ways. Knowing which one a product is vulnerable to tells you more than a feature list.
Volume rises until approving becomes clicking. The defence is precision, not throughput — an agent that proposes eight good jobs a day survives review; one that proposes eighty does not, and the rejection rate is the early warning.
A proposal that applies itself after a timeout is not gated, it is delayed. If unattended time can create a record, the design has an unattended mode whatever the marketing says.
A shared login, a service account, or a queue approved on someone else's behalf all produce a record with no accountable person. The regulation asks what was done; a reviewer asks who decided.
If declining a proposal dismisses a notification rather than writing a record, the product has thrown away the only data that could ever justify giving the agent more room.
None of these are hypothetical and none are hard to test. Ask to reject a proposal in a demo, then ask to see what the system now knows. The answer separates software built around a gate from software that added an approval button to an automation pipeline.
Questions Maintenance Teams Ask
Does the agent create the work order by itself?
No. It drafts one, with the fault, the asset, the reason and the evidence it read, and then stops. Approval creates the work and records who approved it; rejection creates nothing but is kept. Nothing is applied until a person presses the button. Try it on one asset.
Why not let it act on the obvious cases?
Because "obvious" has to be defined as a specific list of actions before it means anything, and the evidence for putting an action on that list is a history of the agent judging it correctly. That history comes from running the gate first. The sequence is not negotiable — you cannot earn the trust before you collect the record. See how the unlock works.
What happens to rejected proposals?
They are kept, with the reason if one is given. They are the clearest signal available about where the agent is wrong, and discarding them means you are running a model you cannot evaluate. They also feed the accuracy figure, which is read from the record rather than asserted. Open the rejection log.
Does the approval gate slow maintenance down?
It adds a decision, and that decision is usually seconds because the reasoning and the evidence are already attached. Compare it to the current state in most fleets, where a defect on a paper inspection reaches a planner some hours later and a work order gets typed from memory. The gate is not the slow part of that chain. Time it against your process.
What does the audit trail actually contain?
What the agent proposed, the evidence it cited, who decided, what they decided, and when. That maps onto what 49 CFR 396.3 asks a maintenance record to show — date and nature of the work — with the addition of an identifiable decision-maker, which the regulation does not require but an auditor will always look for. Take your own compliance advice on your specific obligations. Inspect a trail yourself.
Can we see how often the agent is right?
Yes, and it is computed from your own approvals and rejections rather than from a benchmark. Which means it starts empty and becomes meaningful after you have used it — less impressive on day one than a vendor-supplied percentage, and considerably more useful by month three. Ask us where the number comes from.
How is this different from alert rules we already have?
A rule fires on a threshold you wrote. An agent reads the record — inspections, defects, history, open work orders — and proposes something with a stated reason, including cases you did not think to write a rule for. The gate is what makes that difference safe rather than alarming. Compare it on your data.
Automation You Can Put a Name Against
FleetRabbit's agents draft the work, cite what they read, and wait. You decide, and the record shows that you did.
