AI Agent for a Mobile Mechanic: Bookings, Parts and History

An AI agent for a mobile mechanic is a software assistant that handles booking requests, checks parts availability against approved supplier data, and assembles a vehicle's service history before the technician arrives. It works from the memory, tools and permissions the business sets, and it routes any diagnosis, repair recommendation or warranty promise to the technician. Done this way, it removes back-office work from a van-based practice without moving professional judgment out of the driver's seat.

Key takeaways

• The agent should own bookings, parts lookups and history retrieval, the administrative work that piles up between jobs.
• Diagnoses, repair recommendations and warranty promises stay with the technician, and the agent's instructions must say so in plain terms.
• Start with read access to job records and parts catalogs, and grant write access only to calendar holds and draft messages.
• Define one observable success criterion, such as every booking request receiving a confirmed, declined or waitlisted answer on the same working day.
• Review permissions, supplier feeds and the agent's outputs on a fixed schedule rather than after a complaint.

Where a mobile mechanic loses time between jobs

A mobile practice runs on a schedule that keeps moving. The technician spends the working day in customers' driveways, car parks and fleet yards, so administrative tasks arrive in the gaps: a voicemail asking whether a Saturday visit is possible, a photo of a part number that needs checking, or a customer who wants the record of last year's oil change. Each request is small. Together they fill evenings and interrupt jobs already in progress.

Most of this work is retrieval and coordination, not expertise. Finding an open slot, confirming a part number against a supplier list or locating the note from the previous visit are tasks with clear inputs and clear outputs. They are good candidates for an agent. Diagnosis is different. Deciding that a noise comes from a worn bearing rather than a loose heat shield requires inspection, testing and experience, and a written promise about the result carries real liability. The useful question is not whether an agent can attempt a task, but whether the result can be checked and who answers for it.

What the agent owns and what the technician keeps

A clear split makes the rest of the setup easier to design. The agent can own these tasks:

• Answering booking requests inside the service area and proposing windows drawn from the technician's calendar.
• Looking up parts by vehicle identifiers and comparing them with the supplier feed the business has approved.
• Assembling the vehicle and customer history from job records, with the date and source of each entry.
• Drafting reminders, confirmations and status updates for the technician to approve before anything is sent.

The technician keeps these decisions:

• Any statement about the cause of a fault, the urgency of a repair or whether a vehicle is safe to drive.
• Repair recommendations, quotes beyond the approved estimate range and any change to the scope of work.
• Warranty decisions, goodwill promises and exceptions to the shop's policy.
• Fitment confirmation for parts whose compatibility depends on inspection.

Write these lines into the agent's instructions and into its tool permissions, not only into a policy document. An agent that cannot send a warranty statement cannot make one by accident, and that is a stronger control than a reminder in a prompt.

How does a booking request move through the agent?

Illustrative scenario, not a client case: a fleet manager sends a message on a Monday evening saying that one van's brakes make a squealing sound and asks for the earliest visit. The agent checks the technician's calendar, offers two windows inside the coverage area, and saves the customer's words exactly as written in the job note. It does not guess a cause or suggest a repair. The technician reads the note the next morning, calls if the symptom sounds urgent, and confirms the visit.

The same pattern applies to rescheduling. The agent can move a non-urgent visit only within rules the technician has set, such as no moves on the same day and no more than one move per job without a phone call. Every change should leave a record in the job file, so the next person who opens it can see what was promised and by whom.

How do you keep parts lookups accurate?

Wrong parts cost more time than missing ones. A part that arrives on the wrong vehicle means a second visit, a return to the supplier and a customer who has already waited. The agent should query by a vehicle identifier, such as the VIN or the make, model, year and engine, and show each result with the supplier, the stock status and the date of the feed it came from. Catalog data goes stale and equivalent parts do not fit every variant, so the agent must mark uncertain matches instead of presenting them as confirmed.

Before the agent proposes a part, confirm the following:

• The vehicle identifier used in the search matches the job record.
• The supplier feed is current and its source is named in the answer.
• Any alternative is labeled as an equivalent to verify, not as a confirmed fit.
• The technician has approved the part before anything is ordered.

Text from customers, forwarded invoices and supplier notes is data, not instructions. The OWASP guidance on prompt injection explains why an agent that reads outside messages must never treat their contents as commands, even when a message is written to look like one. Shops that already run a fixed bay face a similar estimate and parts workflow, which the AI for an auto repair shop guide covers in more depth.

Vehicle history as memory, with limits

Vehicle history is one of the most useful things an agent can retrieve. Before a visit, it can surface the brake pads fitted two years ago, the tire rotation at the last service, or a warranty repair that was done at another workshop and recorded in the file. A technician who reads that summary in the driveway arrives with better questions.

History is only as good as the records behind it, though. Scope memory to the vehicle and the customer, and limit who can see each record. The OWASP authorization guidance describes the principle that every user and every agent should see only the records its role requires. Keep the agent from storing personal data beyond what the job needs. When the history is incomplete, the agent should say so plainly rather than fill the gap with a plausible guess. Operators who track vehicle histories across many units will recognize this pattern from AI for a car rental company, where the same question of trusted records comes up at every return.

How Be Human runs this for a mobile practice

Be Human designs, implements and operates personalized AI infrastructure for companies, with agents that keep their identity, memory, channels, tools, permissions and operating context under human control. A first engagement defines one useful role, the memory and tools that role needs, the approval boundaries and one observable success criterion. For a mobile mechanic, that usually means starting with booking triage, where the inputs are clear and the technician approves every commitment.

Managed operations can then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. In practice, the booking agent is checked against real request types on a regular schedule, the parts feed permissions are reviewed when a supplier changes, and any incorrect answer is handled as an incident with a recorded fix. Service is remote and available in English and Portuguese.

Choosing the first task

Start with one role, not the whole shop. Booking triage is usually the smallest safe first step because the inputs are clear and the technician controls every commitment. Add parts lookups once the supplier feed has proven reliable, and hold vehicle history for later, when the quality of the job records is known. Before launch, write down the success criterion and the list of tasks the agent must never perform, such as stating a diagnosis or confirming a warranty.

Test the setup on real past requests before any customer sees it. Keep a short log of each disagreement between the agent and the technician, because those cases show where the instructions need tightening. Review the same log at a fixed interval so that changes are deliberate rather than reactive. The free Be Human AI diagnostic can help you find the first task in your practice worth handing to an agent.

Frequently asked questions

Can an AI agent diagnose a vehicle problem from a customer's description? No, and it should not be set up to try. The agent can record the symptoms in the customer's own words and flag signals of urgency for the technician, but the cause of a fault is a judgment made after inspection. Keeping that boundary explicit protects both the customer and the business.

Does the agent need access to the whole customer database or the accounting system? Usually not. A first setup needs read access to the calendar, the job records and an approved parts feed, plus permission to create drafts. Payments, warranty settings and personal data beyond the job record should be opened only when a specific task requires them and a person has reviewed the reason.

How do we stop the agent from recommending an incorrect part? Require it to name the identifier it searched with, the supplier feed it used and the date of that feed, and to label equivalents as candidates to verify. Test it on past jobs before launch and repeat the test on a schedule. A technician should approve every part before it is ordered.

What does a first project with Be Human look like? It starts by defining one useful role, the memory and tools that role needs, the approval boundaries and an observable success criterion. Managed operations can follow with monitoring, recurring evaluations, integration maintenance and permission review. The work is remote and available in English and Portuguese.

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