Simplicity Is Overrated
I have become increasingly sensitive to the word “simple.”
It shows up everywhere. A product idea is defended because it is simpler. A pricing model is justified because it is simpler. A user experience is considered better because it is simpler. A strategy wins a meeting because it sounds simpler.
Too often, “simple” wins arguments without being examined. Simple sounds good. Simple sounds usable. Simple sounds easier to buy, easier to explain, and easier to defend.
But I have started to distrust how often the word settles the conversation. Simple for whom? Simple at what layer? Simple because the system is well designed, or simple because the complexity has been hidden from view?
If simplicity can hide the structure needed to understand, inspect, or trust a system, then simplicity alone should not be the goal.
Compression Is Not Clarity
When people say “make it simple,” they often mean different things. They may mean fewer steps, fewer visible options, less cognitive load, less implementation complexity, less explanation burden, or a smaller decision surface.
Those are not the same thing. Sometimes they conflict.
You can reduce visible options by hiding important controls. You can reduce the explanation burden by making the system less honest. You can make the interface feel simple while making the system harder to audit. You can simplify the sales story while making the operating model more opaque.
That is not simplicity. That is compression.
Compression is useful when the underlying system is complete and transparent. It is dangerous when the underlying system is incomplete or poorly understood.
If a system is complete and well structured, you can simplify it later. You can aggregate, summarize, create layers, build different interfaces for different users, and expose only what a specific cohort needs.
But if the system itself is incomplete, hiding complexity does not make it simple. It makes it opaque.
The better objective is not simplicity by itself. It is correctness plus transparency. Once the system is complete and inspectable, simplicity can be earned through layers.
Agentic Software Makes This Urgent
This becomes urgent as software shifts from selling access to delivering work.
Traditional SaaS pricing worked because software was relatively stable. The vendor sold access to a product. The customer paid per seat, license, workflow, API call, or usage tier. The software helped humans do work, but the customer still owned most of the operational execution.
AI agents change that.
If software performs the work, the customer is no longer just buying access to software. The customer is buying an outcome. That creates a pricing problem.
Many AI companies still price based on what is easiest to meter: tokens, messages, minutes, API calls, compute, emails, SMS, phone calls, or model usage. These are real costs. They matter. But they are not the value. They are utility.
The value is the outcome: a lead generated, a customer issue resolved, a debt account worked, an underwriting file prepared, a transaction completed, a compliance review performed, or a business decision supported.
Customers do not care how many tokens were burned unless they are being asked to pay for them. They care whether the work got done.
Utility Is Not Value
A refrigerator is useful because it keeps food cold. That is the value. It also consumes electricity. That is the utility cost.
The manufacturer does not usually bundle your electricity bill into the price of the refrigerator. You buy the appliance for the value it provides, and you pay the utility separately based on consumption.
This separation is useful because it is transparent. If the price of electricity rises, you see it. If the refrigerator is inefficient, you can compare it. If another appliance provides the same outcome with lower consumption, you can choose it. If your usage changes, your utility cost changes.
The appliance and the utility are related, but they are not the same product.
AI pricing should move in this direction. The agent provides the outcome. The underlying utility elements are enablers. The customer should be able to see these separately.
This does not mean vendors should treat costs only as pass-throughs. A vendor may deserve to earn based on the value added. But value should not be hidden inside utility, and utility should not be disguised as value.
A Three-Layer Model
A better pricing architecture separates three layers: utility, work, and value.
The utility layer has the raw pass-through or metered costs required to operate the system: tokens, compute, model calls, telephony, SMS, email, storage, retrieval, third-party data, and workflow infrastructure. This layer should be transparent. Not necessarily simple. Transparent.
The work layer has the unit of work the agent performs: one account worked, one lead qualified, one ticket resolved, one claim reviewed, one underwriting file prepared, one document classified, one compliance review completed, or one customer conversation completed.
The value layer has the economic value of the completed work: recovered dollars, reduced handling time, avoided manual review, improved conversion, faster cycle time, lower error rate, increased throughput, reduced compliance risk, or better margin per transaction.
These layers are related, but not identical. Separating them does not make pricing more complicated for the user. It makes pricing more honest. The customer can still see a simple headline number, but beneath that number the structure is inspectable.
If costs increase, the customer can see why. If a better AI model improves performance, the customer can decide whether the higher utility cost is worth it. If a vendor claims to deliver value, the buyer can compare that claim against the underlying work and utility consumed.
That is the difference between simplicity and opacity.
Transparency Creates Trust
The instinct to simplify is understandable. Buyers do not want to read a technical bill of materials for every workflow. Executives do not want every operational detail on the first screen. Users do not want complexity pushed onto them just because the system is complex underneath.
But hiding the economics of agentic work will create distrust.
As agents become more embedded in operations, customers will want to know what they are paying for. They will want to know when costs are utility-driven and when they are margin. They will want to know which choices affect price and which choices affect outcomes.
A customer may not want every detail all the time. But the structure should exist. A CFO may want cost per completed work unit. An operator may want exceptions and cycle time. An engineer may want model selection and token usage. A business buyer may want to know what outcome was delivered, what it cost, and how it compares to human work.
All of these views can exist on top of the same transparent system. That is the point. Do not make the system artificially simple. Make it complete, correct, and transparent. Then create the right interface for each user.
Earned Simplicity
The best products often feel simple. But they usually feel simple because someone did the hard work of organizing complexity, not because the complexity disappeared.
That is the standard agentic software should aim for. Represent the real work. Show the relevant layers. Let different users inspect the level they need. Keep the default experience clean, but do not make the system opaque.
Simplicity is not wrong. It is just not enough.
As agents perform more work, companies will need to price outcomes. To price outcomes, they will need to understand work units. To understand work units, they will need to separate value from utility. To separate value from utility, they will need transparent systems.
Simplicity is subjective. Transparency is architectural. In the AI agent era, transparency is the foundation for trust, pricing, and real market efficiency.