At TMC's AI Summit, I kept hearing versions of the same sentence: "I want the AI to just… know… and do." Know our repair history. Schedule the work. Update the customer. The opportunities for AI to impact operations were everywhere.
Compared with the previous iteration of AI discussion at TMC, this was a night-and-day difference. The vision is moving forward, but there are still a few key terms worth defining as we dive head-first into building AI to solve the problems discussed at TMC.
This article offers a framework and shared language for turning the ideas discussed at the summit into practical systems.
How does a chatbot work?
One topic that came up repeatedly was AI in the context of ChatGPT, Claude, and other chat interfaces. They are easy to use, intuitive, and everywhere, but are often surprisingly sophisticated, carefully engineered systems.
To take a brief look behind the curtain, the language models underneath these systems cannot inherently tell you the weather in Dallas right now or the exact time on your watch. That's because they don't have up-to-date knowledge of the current state of the world. What they can do, however, is break a request into a series of logical steps required to reach an answer for the user.
So, when you ask, "What's the weather in Dallas right now?" the system decomposes that request into several steps:
- Determine what the user is asking for → A weather report
- Determine what variables are relevant to the request → Dallas, now
- Compose requirements into a relevant tool call:
weather(dallas, now)→80 deg F - Turn the result into a sentence for the user → "The weather is 80 deg F in Dallas right now."
An AI agent is a system that breaks a request into steps, takes actions using tools, checks the results, and decides what to do next until the task is done. Step 3 is a tool call, which can be defined as a granular function an AI system can call to complete a larger task.
Because of this decomposition, the system can swap weather() for any other available function the request needs. Accessing functions in this way, the system is able to retrieve knowledge or perform actions that it would not be able to on its own through a raw language interface. The same basic pattern holds for more complicated tasks.
These systems have improved significantly, gaining more tools, more integrations, and access to more kinds of data. But their usefulness still depends on what they are equipped to access and do.
Where general-purpose AI hits a wall
It may come as no surprise that those with the most on their plate are the first to sign up and delegate work to AI, quickly becoming the power users of these systems. From the conversations at TMC, it was clear that this held true. Maintenance admins are finding ways to create and enhance operations in ways previously not possible.
Maintenance admins can pull analytics from their software, give the data to an AI system, and generate useful graphics and dashboards customized to a presentation, operational review, or customer conversation. That is extremely powerful. They can put data in and get the exact analysis or visual they need.
Unfortunately, this workflow also highlights the boundary between today's general-purpose AI products and a trucking-specific system of intelligence: a general-purpose agent does not have direct access to the context in which the user created the export. The term context describes any bit of operational or industry knowledge necessary to produce useful results from an AI agent.
The maintenance admin still has to retrieve the data, upload it, explain what it means, and repeat the process whenever the information changes. Each new session can require the user to rebuild the context, re-upload cost sheets, VMRS data, repair orders (ROs), and prior insights, then re-establish what they were working toward.
These systems also remain fundamentally separate from traditional industry platforms. Even if the agent can analyze a problem, it may not be able to take the next action inside the system where the work actually happens.
This defines the central limitation: the playbook may be good, but the environment is incomplete.
The industry gap: a suitable AI harness
Think of a technician in a shop. They're extremely knowledgeable and capable of performing many repairs. If this technician were at home sitting on their couch, they would still be extremely knowledgeable, but their ability to perform a repair would be severely limited. The shop provides all the resources necessary for a repair; the technician brings their innate experience and skill.
The LLM is like the technician; its tools are the tools in its toolbox, and its data are the parts available in the shop. Without both, the LLM can offer advice, but it can't complete the repair (or desired task).
The right data
Part of the discussion at TMC focused on data quality and the familiar idea of "garbage in, garbage out." Building useful AI systems does require good data, but the issue has two different sides.
If you are training an AI model, high-quality, unbiased data is essential. If you are training a VMRS benchmark or a specialized VMRS coding model, you need accurate and representative examples.
If you are asking an agent to build a custom dashboard or support an operational decision, miscoded VMRS will produce wrong dashboards and wrong outcomes. For most users, the biggest blocker is data access. Without access to the data, good or bad, an agent can't begin to extract value from it. Beyond access, the agent needs the right information for the task, an understanding of what that information means, and an environment where it can use the result.
Consider a data sandbox containing all of your business's work orders, asset data, repair history, invoices, estimates, and costs. With enough context, you could extract a wide range of insights. You can create a temporary version of this today by uploading your data to Claude or ChatGPT.
But several questions immediately follow:
- Who governs access to that data, how long it's retained, and who can see it?
- Will the information update automatically when a new repair is completed or a new bill is paid?
- Will you need to export and upload everything again?
- Can the system trace a conclusion back to the operational records that informed it?
If the agent were built natively into the harness of the repair software, or as an integrated extension with reliable data access, the user would not have to recreate that sandbox every time. The relevant context would already be available, current, abundant.
The right tools
Even a complete data sandbox solves only part of the problem.
What if the agent identifies the need for an RO? In a general-purpose chatbot, the user may still have to leave the conversation, open the maintenance software, and enter the RO manually. The data problem has been addressed, but the tools live in another system.
The reverse is also true. An agent may have a tool for creating an RO, but without repair history, inspection details, costs, or other context, it has no reliable reason to use that tool.
A useful environment must allow AI not only to generate insights, but also to take appropriate action. In a shop, those actions could include:
- Filling out an RO
- Generating or recommending a VMRS code
- Scheduling and notifying a technician about a repair
- Processing an invoice against an open RO
- Reviewing technician efficiency
Each action is a specific tool call that must be built into the system and made available to the agent.
The right environment
A harness is not simply unrestricted access to tools and data. The platform also provides the controlled environment in which the agent operates.
The agent should have access to the data it needs, but that access should remain secure, and governed by explicit system permissions. The available tools should be clearly defined. Important changes may require human review. Actions and source data should remain traceable so users can understand what the system did and why.
The goal is not autonomy for its own sake. The goal is to make an agent capable, intuitive, and useful while keeping its work inside known boundaries.
This is another reason the data environment and architecture matter. Safety is not only a property of the model or the prompt. It comes from the environment: the data the agent can access, the actions it can take, the approvals it must request, and the audit trail it leaves behind.
The vision
Imagine a repair and maintenance platform that is the data sandbox and harness.
These platforms should contain the context of repair and maintenance: repair histories, asset histories, parts usage, line-item costs, historical costs, estimates, invoices, and operational activity. That data can be made available privately and securely within the platform rather than recreated through repeated uploads to a general-purpose chatbot.
They should also include granular AI-ready tools needed to take meaningful action on that data.
Take, for example, the tricky task of reconciling an inbound service invoice from an externally completed repair. A specialized AI agent would be able to:
- Read the invoice
- Find open ROs against that invoice
- Find the correct match
- Audit the invoice charges against the RO's work description
- Ex. brake repair that took 1.5 hours over the estimate
- Ex. part that was billed at 3x the typical market rate
From there, the messy and time-consuming work of finding and reconciling an invoice to an RO is done. This gives the maintenance admin clear audit findings to inform their ultimate decision to either approve or dispute charges.
Where we can take this
AI systems like those in this article should be built specifically for the work maintenance admins already perform. When they are, the actions performed by an AI agent act as an extension of the maintenance admin, not in place of them.
The discussions at TMC made it clear that the industry has moved beyond asking whether AI will matter. The next challenge is describing and building the systems that can make it useful.
The model provides language and reasoning. The agent decomposes and pursues the task. Tools make operational actions possible and repeatable. Data provides the context. The harness connects those pieces inside a controlled environment. It's what turns "I want the AI to just… know… and do" into something we can actually build.