Every renter agrees to keep the car within 100 miles of the depot. Drive further and the company carries a risk it never agreed to, and mileage it never charged for. Sixty-odd cars were out on hire, every one reporting its position to a screen nobody had time to open. TDR opens it — 144 times a day, for every car — and acts on what it finds.
TDR is an AfriversalAI Action Bot. Live since 5 October 2026.
Two and a half minutes, with sound.
Every car in the fleet had GPS. That was never the gap. The gap was that a tracker is a reporting tool: it waits on a screen until a human logs in, picks a vehicle, reads a position, works out how far that is from the yard, and remembers whether that particular renter had permission to be there.
One car, once, is a two-minute job. Sixty cars, continuously, is not a job at all — it is a thing that quietly stops happening. So the fleet found out a car had crossed three state lines the way most fleets do: afterwards. When it came back with the mileage on it, or when it didn't come back.
The brief was one sentence: monitor the radius, catch the breaches, and switch off anyone who does not have approval to be out there.
Every ten minutes, the agent wakes up and runs this chain for every car currently out on rent. It is not a dashboard. Nobody reads its output.
One call per fleet account to the tracker network, not one per car, so sixty vehicles cost the same as six.
Distance is always taken from the depot. Past 100 miles is outside the service area. Inside it, nothing happens and nothing is logged as a problem.
A renter who asked to take a car to Atlanta and had that trip approved is left completely alone. The agent knows the difference between a breach and a plan.
One position outside the line is not enough to act on. The agent waits for the next cycle and only moves if the car is still out there. A single GPS glitch can never switch a paying customer's car off.
On a confirmed breach it places an office hold — so a rent payment or an extension cannot quietly switch the car back on — sends the disconnection signal, alerts the office, and writes to the renter immediately: what happened, how to be reinstated, and their own one-tap sign-in link.
The charge is not guessed from where the car was spotted. The agent waits until the vehicle actually stops, then works the road miles there and back from the yard, subtracts the 200 miles the rental already includes, and prices the rest at the rate on file. The office is handed a finished number.
An agent that can immobilise a customer's car is only worth having if it is harder to fire by accident than it is to fire correctly. Four rules make that true.
Nothing happens on a single position. A tracker that drops a bad fix is ignored by the next cycle ten minutes later.
If more than five cars appear to breach in one run, none of them are acted on. Five runaway vehicles at once is far more likely to be a data fault than a crime wave, and the agent knows it.
A car already under an office hold is skipped. A renter cannot be disconnected, notified and charged repeatedly for the same trip.
The whole chain can be run in report-only mode before anything is switched on. Every crossing — approved, breached or returned — is written to a permanent record.
A car can cross the line at two in the morning on a Sunday. Catching that while it is happening — rather than reading about it on Monday — means somebody awake and watching, around the clock.
In practice that is a rostered monitoring desk: two to three people covering 168 hours a week between them, nights and weekends included. That is what this job costs if a person does it, and it is the only way a person could do it at all.
So the saving is not time clawed back from somebody's afternoon. It is roles that were never created. The fleet grew past sixty cars without putting a single new name on the payroll to watch them, and the overhead stayed exactly where it was.
| A 24-hour monitoring desk | TDR | |
|---|---|---|
| People on shift | 2–3, rotating | None |
| Hours of cover a week | 168 | 168 |
| Nights, weekends, public holidays | Rostered — the hardest shifts to fill | No different to a Tuesday |
| Checks per car, per day | A handful, realistically | 144 |
| Time before a breach is acted on | Depends who is on, and what is on screen | Under 20 minutes, every time |
| Added to monthly overhead | 2–3 salaries | Nothing |
And a staffed desk still would not match it. Nobody sits watching sixty vehicles and recalculates each one's distance from the yard every ten minutes, all night, against a list of who has an approved trip. A person would catch the obvious one. TDR catches the quiet one — the car that goes out, stays out, and comes back before anyone thinks to look.
Where these figures come from. The two-to-three people is the owner's own estimate of what a 24-hour monitoring desk would take, and it is the only estimate on this page. The 168 hours is simply what round-the-clock cover means. Everything else — the ten-minute cycle, the 100-mile radius, the two-reading confirmation, the five-breach brake, the 200 included miles — is what the system is configured to do, and the three breaches are what it actually caught in its first week of working days.
The three breaches in week one are the headline, and they matter. But they are not the reason this was worth building.
A fleet grows by adding cars. Oversight does not grow the same way — a person watching sixty vehicles is watching each one less closely than when there were twenty, and there is a fleet size at which informal supervision silently becomes no supervision at all. Most operators discover where that line was only after they have crossed it.
A hundred-mile fence that checks itself every ten minutes does not get thinner when you add cars to the fleet.
That is the real return. Not the hours it saves this week — the growth it makes safe next year.
It can work out exactly what a breach is worth and hand the office a finished invoice amount. It will not send that invoice on its own. Automatic invoicing exists, it is tested, and it is switched off — it stays off until the owner turns it on deliberately, twice.
That is not an unfinished feature. It is the line we draw on every agent we build: a system may gather the facts, do the arithmetic and prepare the action, but a human signs anything that takes money from a customer. An agent you cannot leave running unsupervised is not finished. An agent that charges people unsupervised was never safe.
A system that already knows something useful, and nobody with the hours to look at it. That is what an Action Bot is for.
Let's build your agent →