AI for a Mobile Mechanic: Bookings, Parts Tracking and Callbacks

AI for a mobile mechanic means a small set of agents that take booking requests, check parts against each scheduled job, and attach callbacks to the right vehicle record, with the owner approving anything that commits time, money or a promise to a customer. For a one- or two-truck operation, the workable starting point is one agent with one job, a written memory of each vehicle, and explicit limits on what it may say. Everything else can wait until that first role has proven useful.

Key takeaways

• Start with one role, usually booking and rescheduling, before adding parts tracking or callbacks.
• Write the approval boundaries first: what the agent may confirm, what it may only propose, and what it must never promise.
• Treat parts as a status question, not a guarantee. The agent reports what is ordered, received or still unconfirmed.
• Keep each vehicle's history in one structured record so callbacks, repeat visits and warranty questions can be found quickly.
• Review the agent's permissions and its activity log on a regular schedule, especially after you change a tool or add a truck.

Why a mobile mechanic's problem is different from a shop's

A fixed shop can keep its calendar, parts shelf and customer history in one room. A mobile operation spreads the same work across driveways, fleet yards and parking lots, with a truck carrying tools and a limited stock of common parts. The owner often takes calls while under a vehicle, and the messages that matter, such as a customer asking whether the brake pads will arrive before Thursday, arrive through several channels at once.

That makes the job of an agent narrower than most software vendors suggest. It does not need to diagnose engines. It needs to keep the schedule honest, record what was promised, know which part is on order for which vehicle, and make sure a callback does not fall through because nobody wrote down the make, model and the symptom the customer described. Those are memory and routing problems, and they suit an agent well when the boundaries are clear.

Start with booking, and write the limits first

Booking is the best first role for most one- or two-truck mechanics because its inputs and outputs are easy to see. A request arrives with a vehicle, a location, a symptom and a preferred window. The agent checks the calendar, proposes a slot, and either confirms it within rules you set or sends it to you for approval.

Before you connect anything, write the limits in plain language. A reasonable starting list looks like this:

• Which job types can be confirmed automatically, such as a routine service at the customer's location.
• Which job types need your review, such as anything involving diagnosis, electrical work or a vehicle that does not run.
• The travel radius, the minimum time between stops and any hours the agent may never offer.
• Phrases the agent must not use, including any statement about a repair outcome, a warranty decision or a completion time it cannot control.
• What to do when a request matches no rule: hold it, ask one clarifying question, and hand it to you with a short summary.

These limits are your approval boundaries. They also protect you when the agent meets a request you did not anticipate. Permissions are only as safe as the rules behind them, and the [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a useful reference for deciding who, or what, may do each action.

Parts tracking without promising parts you do not have

Parts are where mobile mechanics lose the most trust, because a customer hears that a part is on order and then waits without knowing why. The fix is to separate three states that often get blurred together: parts on the truck, parts ordered with a confirmed delivery, and parts still being sourced. The agent should report only the state it can verify, and label everything else as unconfirmed.

A simple parts record for each job is enough to start. It needs the vehicle, the job, the part description, the supplier reference, the order status, the expected delivery, and a note on what the customer was told. When a supplier confirmation arrives, the agent can propose a status change for your review. It should not tell a customer that a part will arrive on a given day unless the record shows a supplier has confirmed it.

The agent can help with lookups and paperwork, but the decision about which part to fit stays with a technician. The same record structure appears in our auto repair shop article, which covers estimates, job status and parts for a fixed shop. Much of it carries over to a van that moves between customers.

Callbacks and the vehicle history that makes them work

A callback is a promise with a clock on it. A customer leaves a voicemail saying a noise came back after a repair, or asks whether a second visit is needed. If nobody links that message to the right vehicle and the earlier job, the owner spends the evening rebuilding the history from memory. An agent can create a callback item as soon as the message arrives, attach it to the vehicle record, and remind you before it goes stale.

The vehicle record is the asset to protect. For each vehicle, keep the make, model, year, a registration reference where the customer permits it, a dated list of visits, the symptoms reported, the parts used and any open questions. Store it in a structured form that the agent can read and that you can export or review without the agent present. Prose notes help, but a plain list of visits and open items is easier for a future agent, a future employee or your accountant to read.

Callbacks also need a clear rule about who responds. The agent can draft a reply and propose a return visit, but a call that involves a diagnosis should go to a technician. The same split appears in our plumbing dispatch and callbacks article. The agent keeps the queue honest, and the person with the tools makes the judgment.

An illustrative week with one truck and one agent

Illustrative scenario: a two-person mobile mechanic business with one truck runs a booking agent and a callback log. On Monday, a customer asks for a brake inspection at a workplace car park on Thursday. The agent checks the schedule, sees room on Thursday afternoon within the travel radius, and proposes the slot. Because brake work is on the review list, the proposal goes to the owner with the vehicle record attached, and the owner confirms by message.

On Tuesday, a supplier email confirms that replacement pads have shipped. The agent updates the parts record and notes that delivery is expected before Thursday, but it does not message the customer, because the rules send parts status changes to the owner first. On Wednesday, a voicemail arrives from a different customer asking whether a noise returned after last month's visit. The agent creates a callback item, links it to that vehicle's history, and places it at the top of the owner's list with the earlier visit summary. On Thursday, the owner has everything needed before the first call of the day.

Nothing in that week required the agent to make a judgment that belonged to a technician. It required a clean record, clear permissions and a habit of reviewing what the agent did.

How Be Human handles this in a managed setup

Be Human designs and operates this kind of setup as personalized infrastructure, so the agent keeps its identity, memory, channels, tools, permissions and operating context under your control. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, which for a mobile operation is usually something concrete, such as fewer missed callbacks or fewer schedule conflicts. Managed operations can then include monitoring, recurring evaluations of the agent's replies, maintenance when a supplier portal or calendar changes, permission reviews and controlled changes when you want the agent to take on more. The aim is to keep one role reliable and auditable as the business grows, not to add automation for its own sake. Service is remote and available in English and Portuguese.

Keeping vehicle history usable as tools improve

Tools change faster than vehicle records should. A calendar app is replaced, a supplier moves to a new portal, a booking form gains a field. If the history lives only inside one tool's format, each change becomes a migration project. Keep the record in a plain structure you own, and let the agent read from it through a defined interface rather than through a fragile copy inside a single app.

Two habits matter most. First, log what the agent did, including the request it received, the rule it applied and the message it sent, so you can later see why a booking was made. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) describes how to trace what happened across steps, which is more reliable than trusting a summary. Second, test the agent against real past cases before changing anything. Write ten or so representative bookings and callbacks from your own history, note what a good answer looks like, and run them again whenever a tool or rule changes.

Retrieval is also worth understanding. An agent that searches your vehicle history at the moment of a request is usually easier to correct than one whose behavior depends on details it absorbed earlier. The [Google Cloud guide to retrieval-augmented generation](https://docs.cloud.google.com/architecture/rag-capable-gen-ai-app-using-vertex-ai) explains that pattern. Keep prompt injection in mind as well: a customer message can contain instructions, and the agent should treat that text as content to read, not as commands to follow. The [OWASP prompt injection prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) sets out the basic defenses. If you want to find the first task worth handing to an agent in your business, take the free Be Human AI diagnostic.

Frequently asked questions

Do I need a new scheduling system before I can use an AI agent? You usually do not. Most one- or two-truck operations can start with the calendar and messaging tools they already use, as long as the agent can read and write the relevant items through a permission you control. Replacing tools is a separate decision that should follow a clear need, not come first.

Can an agent confirm a repair appointment on its own? It can, for the job types you explicitly allow in the approval boundaries. Anything involving diagnosis, unusual vehicles, safety concerns or a change to a confirmed visit should come to you for review. Start with a narrow list and widen it only after reviewing several weeks of records.

How does the agent avoid promising that a part will arrive on a certain day? It reports only what the parts record shows, such as an order placed or a supplier confirmation received, and labels everything else as unconfirmed. Its rules should forbid statements about delivery dates the record does not support. You review changes to customer-facing wording before they become a standard reply.

Is it safe to keep customer vehicle history in an AI system? It can be, if you limit what is stored to what the work requires, decide who can read it, and keep an exportable copy under your control. Check what customers have agreed to, especially for personal details, and keep records in a format you can review without the agent. Local data protection rules apply to these records, so confirm them before you store anything.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.