A useful way to predict where software is going is to ask who the next user will be. For the last twenty years the user was a person clicking a screen. For the next ten, an increasing share of the work will be done by AI agents acting on a person's behalf - and they do not click screens. They call interfaces.
This shift quietly rewrites the rules for every platform, automotive included. Software designed for humans assumes a human in the loop to interpret a messy UI, fill the gaps, and recover from surprises. Agents have none of that tolerance. They need clean, structured, well-described interfaces to read data and take action. The platforms that provide those interfaces become the platforms agents can actually use. The ones that hide everything behind a human-only UI become invisible to the fastest-growing category of users.
The interface standard emerging for this is MCP - the Model Context Protocol - and it is worth understanding why an MCP layer, sitting on top of versioned APIs, is about to matter a great deal in automotive.
What MCP is, briefly and concretely
Strip the acronym down. MCP is a standard way for an AI agent to discover what a system can do and then do it - safely, with structure, and without bespoke glue for every integration.
Two halves matter. First, MCP exposes resources: structured data the agent can read. For automotive that is the canonical vehicle record - identity, history, valuation, condition, inventory status - described in a way an agent can consume without scraping a webpage or guessing at a schema. Second, MCP exposes tools: actions the agent can take, each with a clear definition of what it does, what it needs, and what it returns. Reprice a vehicle. Generate a valuation. Flag a unit as margin-at-risk. Pull a car's service history.
The point of the standard is that the agent does not need a custom integration for each system. It discovers what is available, understands it from the descriptions, and acts within defined boundaries. One protocol, many capabilities, no bespoke wiring per agent. That is the unlock.
Why the dealership stack is a hard case - and a perfect one
The modern dealership does not run on one system. It runs on a stack: a DMS, a CRM, a valuation tool, listing platforms, financing systems, a workshop scheduler, accounting. Each holds a piece of the truth. Each has its own login, its own model of a vehicle, its own way of doing things.
For a human this is merely annoying. You learn the dance - copy a VIN from here, paste it there, reconcile the valuation by eye, update three systems by hand. The dance is slow and error-prone, but a person can do it.
For an agent, the same fragmentation is a wall. An agent cannot improvise across six incompatible UIs. It needs each capability exposed as something it can call, described well enough to use correctly, with the canonical data underneath consistent enough to trust. Absent that, the agent is as stuck as a new hire on day one with no logins and no map.
This makes automotive both a hard case and a perfect one. Hard, because the stack is genuinely fragmented and the data is genuinely inconsistent across systems. Perfect, because that is exactly the kind of mess agents are good at - if the capabilities are exposed in a form they can operate. An MCP layer over a canonical data foundation is what turns the fragmented stack into something an agent can work across. The mess does not go away. It gets a usable interface.
What agents can actually do once the layer exists
Concrete examples make the case better than abstraction. Picture an MCP layer over a canonical vehicle record and a set of well-defined actions. Now an agent can do real work.
Inventory triage. An agent reads the current inventory, identifies units past their expected days-to-sell, checks each against fresh valuation and demand signal, and proposes price adjustments - with the reasoning and sources attached. A person approves the batch. The tedious part is gone; the judgment stays human.
Valuation on demand. An agent receives a VIN, pulls the canonical record, requests a valuation with its confidence interval and sources, and returns a defensible number with its provenance. No tab-switching, no manual lookup, no stale data.
Cross-system reconciliation. An agent notices a vehicle's status differs between the listing platform and the DMS, surfaces the discrepancy, and proposes the fix. The invisible reconciliation tax that humans pay all day starts getting paid by software.
Lifecycle handoffs. When a car moves from sales to service to resale, an agent carries the context across systems, so the workshop sees the history and the next buyer sees the truth - without a person re-keying it at every boundary.
None of these require the agent to be magic. They require the platform to expose data and actions in a form the agent can use, with the canonical data underneath being trustworthy. The intelligence is increasingly commoditized; the access is not. Access is the moat.
Safety is the whole point, not an afterthought
The instinct when you hear "let an AI agent reprice vehicles and update systems" is to worry. That instinct is correct, and it is exactly why the interface layer matters so much. Done well, an MCP layer over versioned APIs makes agent action safer than the human-improvising-across-six-UIs status quo, not riskier.
Defined tools mean defined boundaries. An agent can only do what the tools expose. There is no tool to delete the inventory, so there is no path to deleting the inventory. The capability surface is deliberate, not whatever the agent can reach by clicking around.
Structure means validation. Every tool call has a defined shape that can be checked before anything happens. Malformed or out-of-bounds requests get rejected at the door, not after they have done damage.
Tenant isolation still holds. The agent operates within the same row-level isolation as everything else. It sees and touches only its tenant's data, by construction. An agent does not get a backdoor around the platform's guarantees; it inherits them.
Actions can be logged and reversible. Because actions go through defined tools, every one can be recorded - what the agent did, why, and what resulted. That audit trail is also the outcome data that makes the system smarter over time. Sensitive actions can require human approval, gated as a property of the tool itself.
Compare this to the alternative - agents driving human UIs by simulating clicks, with no boundaries, no validation, and no audit. That is the genuinely dangerous version, and it is what you get when there is no proper interface layer and people bolt agents on anyway. The MCP layer is not the risk. It is the control.
Why versioning is non-negotiable
One detail separates a platform agents can rely on from one they cannot: versioned APIs.
Agents are written against an interface. If that interface changes silently, every agent built on it breaks silently - and worse, may keep running while doing the wrong thing. For a human-facing UI, a surprise change is a support ticket. For an agent-facing API, a surprise change is a fleet of agents quietly making mistakes.
So the contract has to be explicit and stable. Versioned REST with OpenAPI definitions, an MCP layer on top, and a clear policy on how changes are introduced and old versions retired. Developers and partners need to know the ground will not shift under them. This is unglamorous infrastructure discipline, and it is precisely what makes a platform something serious builders will commit to.
The winners are the platforms agents plug into
Here is the conclusion the rest of this builds toward. As agents become a real share of how work gets done in automotive, value concentrates in the platforms agents can plug into - the ones with canonical data, defined actions, safety built in, and a stable, versioned, agent-ready interface.
Closed apps, however polished for human users, become dead ends for agents. You cannot easily build an agent against a UI with no API and no protocol, and the few who try produce the brittle, dangerous version nobody should trust. The open, agent-ready platform becomes the default surface - the thing the ecosystem builds on, because it is the thing that can actually be built on.
This is the same lesson every prior platform shift taught, arriving on schedule for automotive: the layer that exposes capability through a clean, stable, open interface wins the long game, because everyone else ends up building on top of it.
How VehIQ approaches it
VehIQ is built to be that surface. Canonical European vehicle data and a set of defined actions, exposed through versioned REST and OpenAPI and an MCP layer - so AI agents can read vehicle data and take action across the dealership stack, safely, within tenant isolation, with outcomes logged.
The goal is not to replace the people who run dealerships. It is to give the agents working alongside them a layer they can actually, safely use - and to make sure the platform doing the connecting is open enough that the whole ecosystem can build on it. The agents are coming either way. The platforms worth having are the ones they can plug into.