Oracle Will Sell You a Database Column for Ten Grand
Every application vendor shipped the same feature this year. Open Salesforce, Netsuite, Workday, Zendesk or any other software, and you’ll find a panel on the right labeled “agent”, waiting for someone to ask it something.
They all reached the same conclusion, because they are making the same bet as incumbents: software is for people to do work, and this might be a useful interface element for them to do it with. This will be the right bet if agents never prove capable of doing real work, independently. But if they do, then this is completely the wrong bet, because it is building for a user who won’t be there to use it.
Some of them ship an agent that only does lookups. The more ambitious ones let it read across other systems too, combining sources for more insight. But even with the integrations, they have a problem of state. When combining information, they can only hold it ephemerally, because their data model is tied to their product.
The in-app agent is tied to a schema shared with hundreds of thousands of other tenants, mediated by custom objects, priced by tier. They could attempt to change this, but they won’t. The charging by module business is the business, and free arbitrary tables created by an agent would destroy it. Their agent is handcuffed.
Lock in
Most software vendors have some combination of four lock ins to hold customers in place, and three of them will get eroded by agents:
Habit. The habit relied on the user, and agents don’t care about the users’ habits. Somebody at your company has “NetSuite” on their LinkedIn. That was the lock in.
Configuration. Tied to user habits, so when user habits erode, then configuration lock in erodes too. Ten years of custom fields, validation rules, and one workflow nobody dares touch because the guy who built it left in 2019.
Data. Once horizontal agents are reading and writing across apps, the data lock in erodes. Technically yours. Practically theirs, because only their screens can read it.
Network. The lock in that persists - a new class of agents will not erode the quality of network advantage that ex. Salesforce has
SaaS software sells a CRUD database with a UI on top, and the database schema is a fossilized shape of the UI. This is what makes changes so hard. When your schema is Department, Class, and Location, and your customer wants to track product line, channel, and region, that change requires a multi month development cycle, and you will price it accordingly. Oracle partner quotes put a single add-on module at $6k - $12k. Which means you never owned the shape of your own data - you rented it. It’s schema rent: the price of being able to record a field.
This is why, with Netsuite, when you have subsidiaries, you need to buy the right edition for subsidiaries.
And when you want to track your fixed assets, that’s Fixed Assets Management. A list of assets, a depreciation rate, and a journal entry once a month. A table, a formula, and a cron job, licensed on a three year contract.
And when you want to write down your square footage, so you can allocate rent across departments, that’s Advanced Financials. Because square footage is not money, and recording a number that isn’t money requires a statistical account, and statistical accounts belong to a module you have not bought. Oracle’s documentation specifically calls this out; they will unabashedly sell you a database column for ten grand. That is schema rent.
What happens when you kill the UI? You free the schema.
Agents without UIs
The kind of agent that will win will be one not tied to a UI or a schema. Agents need APIs not UIs, and once the UI is gone there’s nothing pinning the schema. Department, Class, and Location were never accounting facts, they were just arbitrary dropdowns.
The winning product is a harness that does the work and keeps its own books about the work. It doesn’t ask NetSuite for a new field, because it doesn’t need one. You want to track square footage? It makes the table, in its own store. You want to see it by cost center, which was never one of your three dimensions? It makes the view. You want to know when an allocation drifts by five percent? It makes the job. And when something has to hit the ledger, it does the only thing the ledger has ever accepted from anyone: it posts an entry, which the ledger will reverse on request, because that is what ledgers have done since 1494.
Nobody sent a quote. Nobody booked time with a CSM. Nobody sat through an upgrade conversation. Nobody scheduled a change window. Nobody signed anything. No rent.
The intermediary step is that the system of record gets demoted into a system of recording. In the long term, it stops being where anyone looks, and in the longer term it is simply forgotten.
But the agent needs to get smarter
Agents in 2026 aren’t good enough to bring about this reality, because they still need humans for too much of the work. This part is binary - either a human with a UI is needed, or it’s not. If the agent does eighty percent of the work, we still need the UI. Which means we still need the schema, which means the harness can only be a cache.
Caches have no lock in.
It’s discontinuous, once the agent can do every part of the job, then it can own the data too. So the agent that wins is one that can master an entire domain, and then wipe the schema+UI from that domain.
The two things holding agents back are a) non-rotten context window for a model, and b) what harnesses themselves can do. For example, it’s hard to currently trust a model to have a broad enough view to have the judgment of when to create scratch tables vs what needs to be persisting for the long term. Both models and harnesses aren’t yet great at creating standardizations in specs and in the persistent layer. Long running agents are still not yet a solved problem.
No one wants a decision trace
The idea of a persisted decision trace has become the fashionable-but-incorrect answer to where the lock in is. Yes, agents generate decision traces. Yes, agents show their work, and that is more than can be said of humans. However, the trace is just scratch paper that no one needs to actually look at. The trace gets compressed into configuration and metadata: a set of policies and context on how to keep doing the work, and that’s what anyone cares about.
Not that traces are useless, but rather that all the useful stuff should get extracted and compressed from them anyway. So, ultimately, continuing to own the traces doesn’t give you lock in; it just gives you a bunch of exhaust to carry around.
The new lock ins
This will be the end of schema rent, but it won’t be the end of lock in. Software built its lock ins on habit, configuration, data, and networks. In an agent era, many of those will no longer be available. People form habits, agents don’t. It’ll take time for the right network structures to develop that lock ins can be built around.
But, the configuration lock in that eroded from software because the users go missing will be a stronger lock in than ever when the agents arrive. The configuration is no longer guardrails for the people using the product, the configuration now does the work itself. The configuration is the product. And in theory the configuration could walk. Nobody moves a system because copying was easy. The blast radius is your payroll run.
And while it’ll be hard to build a data lock in since agents can transfer data out pretty easily, the configuration ties itself to the data, and improves the overall lock in.
I should mention I’m building one of these harnesses. I work with a lot of finance teams, which is why every example in this essay is an ERP module. Discount accordingly.
The ledger will be fine - it survived paper, mainframes, client-server, cloud, and now agents. That’s because it was never software, it was a data structure. What will go is everything that got bolted on to it: the dropdowns, modules and tiers. Five hundred years from now an agent will post debits and credits, and nobody will remember that there was once a year when you had to buy a license to write down how many square feet you had.