Your AI Agent Has the Keys. Now What?

If you have been anywhere near the enterprise AI conversation this year, you have heard some version of this. Models are getting good enough that you connect an agent to your systems, give it access through something like MCP, and let it work. The platform layer underneath starts to look redundant. Why pay for infrastructure when the model can reach into your tools and figure things out for itself?

I understand the appeal. I have spent twenty years building businesses on enterprise platforms, and I have watched a lot of expensive software get displaced by something simpler. But that misses context on what really matters. Connecting an agent to your systems is something almost anyone can do now. What decides whether it works, or delivers any value, is far more complex.

You do not have to take my word for it. Over a few days this May, Anthropic and OpenAI each stood up a dedicated enterprise unit to go and do this work inside companies. OpenAI’s launched with more than $4 billion in committed capital, built around forward deployed engineers who sit inside the customer and wire the models into their systems, processes and governance. Anthropic’s is a $1.5 billion venture with Blackstone, Goldman Sachs and others, aimed at mid-sized companies that want AI in production without building a large team to do it.

Two of the biggest model companies in the world just put billions of dollars into this. They built the models, and they still concluded that the model alone does not make AI work inside a real company.

Access is not the bottleneck

APIs have been around for decades. SAP, Salesforce, and your billing system have all had them for years. MCP is a cleaner, model-friendly protocol for exposing those kinds of tools and data sources to agents, and it is useful, but it does not make system integration a new capability. If wiring software together solved the problem, we would have solved it years ago.

An agent can reach into all of those systems and still not know what it is looking at.

Giving an agent access to your systems is like handing someone the keys to a warehouse where nothing is labelled, there is no list of what is on the shelves, and no one has told them which boxes they are allowed to open. They can get in, and if they look long enough, they will find things. They will also get a fair amount wrong, and the things they get wrong change from one visit to the next.

A connection gives the agent reach, and nothing more. It has to work the meaning out for itself, and that is fine until a real decision depends on the answer. The reason it gets things wrong is not the connection. It is what the connection leaves out.

What the connectors leave behind

An agent reaching inside a real enterprise runs into three problems, and a connection solves none of them.

First, meaning. Take one client: SAP calls it a customer, Salesforce an account, the billing system a payer. Someone who has worked there a year knows those are the same company, and the handful of places where they are not. An agent reading from all three has no way to know that on its own. It infers the connections, and it can infer them wrong.

Second, memory, or the lack of it. An agent wired up through a set of tools usually reads the data fresh when it is called, and carries little of your business over between requests. It might read things one way on Monday and slightly differently on Wednesday, and the drift can go unnoticed on both sides. It can come across as inconsistent, even forgetful, starting from scratch more often than you might expect.

Third, action. Reading data is one thing, but acting on it is where a mistake does real damage. An action has to land correctly across the systems it touches, with the right sign-off, a record of who did what, and a way to reverse it. A bank cannot run on an agent that happened to get the permissions right this once. Neither can a hospital, a government department, or a manufacturer with a regulator watching.

None of this gets fixed by a better connector. It gets fixed by a layer that holds the meaning of your business in one place, consistently, with the rules attached. Palantir calls that layer the ontology. The name matters less than the idea behind it. It is the difference between an agent that can reach your data and an agent that understands your business.

In practice it stacks up in layers. Your data becomes objects, the things your business runs on. An airline stops looking at rows in a table and starts working with flights, aircraft and crew. The decisions people make get attached to those objects as actions: rerouting a flight, rescheduling a shift. When someone takes one, the change is written back to the systems it came from. Models and agents then work on top of the objects rather than the raw tables. They reason over the real thing instead of guessing at what a column means. Permissions ride along at the object level, so if a person cannot see a salary field, an agent working for them cannot see it either.

A different category of software

For twenty years, enterprise software asked you to fit your business into its shape. Salesforce had a model of how sales works. ServiceNow had a model of how IT operations run. SAP had a model of how a company handles its money and its supply chain. You bought the model and you bent your business to fit it. That was not laziness on anyone’s part. Building software from scratch was slow and expensive, so a ready-made shape that was roughly right was a sensible trade. Most of the time it fit well enough, and the gap was worth living with.

AI changes the maths on that trade. The cost of building software to fit your business is falling fast. The cost of forcing your business into someone else’s shape has not moved at all. There is also a new reason the generic shape works against you. When an agent reasons over a model that does not quite match how you operate, it inherits the places that model is wrong, and repeats those errors across the work it touches.

So, the platform that matters now holds the real shape of your business and gives your agents a consistent, governed picture to work from. It is a different category of software, and people keep mistaking it for a better Salesforce. The two are not competing for the same job.

The rest of the industry is arriving at the same place, and quickly. The forward deployed engineer that OpenAI and Anthropic built their ventures around is one Palantir pioneered years ago. It sent its own engineers inside institutions to make the software work. But the engineers are only part of the answer. What lets that hands-on work hold up is the platform underneath it, and that is what the startups now pitching themselves as Palantir for X tend to miss. As Marc Andrusko of a16z put it in The Palantirization of Everything, “Palantir works because there is a real platform underneath the bespoke work.”

At Build this June, Microsoft launched Fabric IQ, a shared semantic layer that grounds agents in governed business objects and relationships. It is even calling that layer an ontology. Microsoft reaching for that word tells you the idea has gone mainstream. For Microsoft, though, this is day one. Palantir's ontology has been running in production for years, across government and industry. It was never an announcement for them. It is how the platform already works.

You can see what that looks like in production. At AIPCon 10, the USDA showed how Palantir’s ontology now underpins national food supply security. Their warning about the alternative was blunt:

When a platform is overkill

I would be making the very mistake I am warning about if I told you this was the answer for everyone.

If your problem sits inside one function, and the specialist software for that function already solves it, buy the specialist software. If you need a better CRM, go and get one. The ready-made shape exists because it fits a great many businesses well, and rebuilding it for a problem that is already solved is a waste of money. Commodity work stays commodity work, and that is fine.

A platform like Palantir's earns its place on the other kind of problem: one that runs across systems, where a decision needs your finance data, your operational data, and what is happening in the field at once, and needs them to agree. These are the problems where the way you operate is itself a source of advantage, and where getting the decision right is worth enough to justify building for it properly. Force a problem like that into a generic box and the advantage is gone. You need both

The model itself is turning into a commodity, and fast. Lindy, one of the better-known AI agent companies, recently switched its traffic to an open weight model. The move cut their costs by millions, and performance went up rather than down. For all but the most complex edge cases, you can swap the model out and barely feel it.

There is a tell in how the companies building the models run their own AI. On Lenny’s Podcast, Dan Shipper, CEO of Every, described how one of the big AI labs handles data questions inside the company. Rather than hand their people an agent with raw access to the warehouse, they built a single agent wired into it, one that knows who each person is and what they are allowed to see, with a team whose job is keeping it accurate. They do not trust raw access on its own. They put a governed layer in front of it.

The model supplies the reasoning. What it reasons over still has to be accurate, and that is what the platform holds: a working picture of how your business fits together. On its own, the model is a very capable guess. Give it that picture, and the guessing stops. The companies that get real value out of AI over the next few years will put the two together. The layer underneath the agent only gets more important from here.