The Future Belongs to Technologies We Can Tolerate

What if the biggest obstacle to a powerful technology is not whether it works, but whether anyone can tolerate using it?

A sports scientist studying sodium bicarbonate faces a deceptively simple problem. The substance can improve performance under certain conditions, but the obvious delivery method is so unpleasant, and so likely to cause gastrointestinal distress, that the intervention may fail before its biological effect has a chance to matter.

A financial technologist faces a parallel problem with programmable money. Digital dollars that move instantly and allow software to execute transactions could transform commerce. Yet the promise of autonomous financial software depends on an equally important question: can ordinary people, companies, and machines use the system safely, reliably, and without absorbing intolerable complexity?

These examples point to a broader principle:

A technology is not useful when it merely possesses power. It becomes useful when its power can cross an interface without creating more friction than value.

This is the overlooked connection between sports supplementation and the agentic economy. Both are less about the active ingredient than about delivery. The future belongs to systems that do not simply contain capability, but package capability in a form that bodies, people, and software can actually absorb.

The Active Ingredient Is Not the Product

It is tempting to evaluate an innovation by asking whether it works in principle. Does sodium bicarbonate buffer acidity during intense exercise? Can stablecoins move dollars globally and cheaply? Can autonomous software make payments on behalf of a user?

Those are important questions, but they are incomplete. A better evaluation asks four questions:

1. What is the active mechanism?
2. How is it delivered?
3. What friction does delivery impose?
4. Does the user receive enough net value to continue using it?

The distinction between mechanism and delivery is easy to miss because successful technologies make the delivery layer feel invisible. A smartphone is not merely a powerful computer. It is a computer translated into a screen, gestures, notifications, battery management, and a familiar social object. The internet did not become transformative because data could theoretically move between computers. It became transformative because browsers, search engines, and simple protocols made that movement accessible.

Sodium bicarbonate offers a miniature version of the same lesson. The traditional approach is straightforward: dissolve a large amount in fluid and drink it. Yet the experience can be intensely unpleasant, with gastrointestinal side effects that undermine the very performance the supplement is supposed to improve. The molecule may be effective, but the product is poorly matched to the human body.

This is not a minor inconvenience. It changes the economics of adoption. If the cost of consuming an intervention is nausea, bloating, uncertainty, or an unpleasant ritual, then the theoretical benefit must be unusually large to justify repeated use. A small improvement in exercise capacity may not compensate for an experience that makes the athlete feel ill before the event begins.

The same calculation applies to financial technology. A payment system may settle instantly, but if users must understand private keys, network fees, wallet security, transaction permissions, and unfamiliar interfaces, the system has transferred its operational burden to them. It may be technically frictionless for the ledger while remaining psychologically and administratively painful for the user.

The ledger can be fast while the experience is slow. The molecule can be effective while the routine is intolerable.

Friction Is a Design Variable, Not an Accident

People often describe friction as if it were an unfortunate residue of innovation, something that will disappear naturally as technology improves. In practice, friction is a design variable. It can be reduced, relocated, hidden, or amplified. It never simply vanishes.

Consider the difference between two delivery systems. In one, a user swallows a concentrated substance in an unpleasant liquid and hopes their stomach cooperates. In another, the same active ingredient is divided into a more manageable form, perhaps using a different oral delivery method designed to reduce discomfort. The underlying chemistry may remain similar, but the adoption profile changes dramatically.

This suggests a useful distinction between functional friction and incidental friction.

Functional friction is the unavoidable cost of achieving the desired outcome. An athlete may need to consume a certain quantity at a carefully timed interval. A payment may require authentication to prevent fraud. Some costs exist because the system must perform real work or manage real risk.

Incidental friction is the cost created by an immature interface, poor packaging, or an arbitrary legacy process. Drinking an unpleasant solution may be incidental if another delivery method can provide the same substance more comfortably. Manually copying wallet addresses, managing multiple network environments, or approving every tiny machine transaction may be incidental if better infrastructure can automate those steps safely.

The strategic mistake is to treat both types of friction as equally necessary. That leads organizations to defend bad experiences as if they were proof of seriousness. In reality, the best systems preserve the friction that protects users and eliminate the friction that merely exposes machinery.

This becomes especially important when software agents enter the financial system. A person can tolerate a complicated process occasionally. An autonomous agent cannot operate effectively if every transaction requires a human to interpret technical details. The purpose of an agent is not simply to act faster. It is to compress a complex objective into a series of reliable actions.

Imagine telling an agent: “Find the cheapest available software service, subscribe for one month, remain under a budget, and cancel if the service stops meeting our requirements.” For that instruction to work, the agent needs more than intelligence. It needs a payment rail, clear permissions, predictable settlement, identity, fraud controls, and a way to handle small transactions without excessive overhead.

Programmable money supplies part of this foundation. Internet native dollars can potentially move at any hour, across borders, through software controlled by explicit rules. But the existence of such money does not automatically create a usable agentic economy. It creates the biochemical equivalent of an active ingredient. The delivery system still determines whether the capability reaches the user.

The Agentic Economy Needs a Tolerability Layer

The phrase “agentic economy” can sound abstract, even futuristic. Its practical meaning is simpler: software will increasingly make decisions and execute transactions on behalf of people and organizations.

An agent might book travel, purchase computing resources, pay a contractor, rebalance a budget, or acquire data. These actions are not fundamentally different from existing commerce, except that the decision maker is software operating within constraints rather than a person clicking through a checkout page.

That shift creates a new design requirement: financial actions must become tolerable for machines.

Human financial systems were built around human rhythms. A person can wait for a bank transfer, tolerate business hours, read a contract, and make a payment large enough to justify a fixed processing cost. Software agents operate differently. They may need to make thousands of low value decisions, transact globally, respond within seconds, and continuously evaluate whether a purchase remains worthwhile.

A payment rail designed for this world needs properties such as:

• Low marginal cost, so small transactions are economically viable.
• Fast settlement, so agents can act on current information rather than stale balances.
• Programmable permissions, so an agent can spend within a defined scope.
• Global availability, so software is not trapped by local banking hours or borders.
• Readable transaction states, so agents can verify what happened and recover from errors.
• Strong reversibility and dispute mechanisms, because autonomous action increases the chance of mistakes at scale.

Stable digital dollars can help with the first four. They do not, by themselves, solve the last two. A machine needs to know not only that money moved, but why it moved, under which authorization, to whom, with what recourse, and whether the result matched the original instruction.

This is where the supplement analogy becomes more revealing. A delivery system is not judged only by whether it transports a substance into the body. It is judged by timing, dosage, side effects, consistency, and user confidence. Financial agents need the same categories of support.

Timing means settlement occurs when the decision is still relevant. Dosage means spending authority is limited to what the agent needs. Side effect management means erroneous or malicious behavior can be contained. Consistency means the same instruction behaves predictably across environments. User confidence means people can understand and audit what the software did.

Without these properties, autonomous finance may become powerful but unusable. Agents will be able to act, but organizations will not trust them with meaningful authority. The result would be a paradox: increasingly intelligent software constrained by primitive financial interfaces.

The Real Unit of Innovation Is the Interface Between Systems

The deepest lesson is that innovation often happens between domains rather than inside them.

Sodium bicarbonate is not new. Digital dollars are not new. Artificial intelligence is not new in the broad historical sense. What changes outcomes is the interface between a capability and the environment in which it must function.

A useful mental model is the capability to friction ratio:

Adoption potential equals perceived capability divided by total user friction.

Perceived capability includes the benefit a user expects to receive. Total friction includes financial cost, physical discomfort, cognitive load, setup time, risk, uncertainty, and the likelihood of failure.

The ratio explains why technically inferior products can win. A less powerful tool with a clean interface may deliver more practical value than a superior tool that demands expertise. It also explains why a small improvement in delivery can create a large increase in adoption. If friction falls from high to moderate, the same underlying capability becomes available to an entirely different population.

For example, an elite athlete may tolerate a difficult supplementation protocol because the expected performance benefit matters enormously in a competition. A recreational athlete may not. Change the delivery method, and the intervention may move from a niche practice to a mainstream option.

Likewise, a large financial institution may maintain specialized teams to manage complex digital asset infrastructure. A small business cannot. If programmable money is wrapped in tools that handle compliance, permissions, accounting, and recovery, its potential market expands. The technology has not necessarily become more powerful. It has become more absorbable.

This is why the future of autonomous finance will not be determined only by model intelligence or blockchain throughput. It will be determined by the quality of the interfaces connecting intention to action.

A user says, “Keep my cloud expenses below this amount.” The interface must translate that intention into a policy. The policy must authorize an agent. The agent must discover a service, pay it, verify delivery, and report the result. If any link is ambiguous, the user is forced back into manual supervision.

The winning systems will make this chain feel less like issuing a command to a robot and more like delegating to a trusted employee. That requires transparency without overwhelming detail. It requires controls that are precise enough for safety but simple enough for ordinary users. It requires defaults that reduce effort without silently expanding authority.

Designing for Safe Absorption

The practical question is not whether we should eliminate all friction. That would be dangerous. A system with no resistance can also be a system with no protection.

The goal is safe absorption: make beneficial actions easy while making harmful or irreversible actions appropriately difficult.

For product designers, this leads to a five part test:

1. Identify the active value. What benefit is the system actually providing, apart from its technical novelty?
2. Map every point of discomfort. Include physical, cognitive, financial, legal, and emotional costs.
3. Separate protection from residue. Which obstacles reduce real risk, and which merely reflect outdated infrastructure?
4. Move complexity to the layer best equipped to handle it. Machines should handle repetitive technical operations; humans should retain control over goals, boundaries, and exceptional decisions.
5. Test repeated use, not first use. A system that works once may still fail as a habit, business process, or autonomous loop.

For users, the same framework offers a way to evaluate new technology more intelligently. Do not ask only, “Can this work?” Ask, “Can I use it repeatedly, under stress, with clear recovery when it fails?” The answer often matters more than a demonstration of peak performance.

For builders of agentic financial systems, this means treating permissions and recovery as core product features, not compliance afterthoughts. An agent should have a spending ceiling, a purpose boundary, an expiration date, and a clear record of its decisions. It should be possible to pause it instantly, inspect its reasoning at the level needed for accountability, and distinguish an authorized mistake from an unauthorized action.

The same principle applies to physical interventions. A supplement protocol should account for tolerance, timing, preparation, and individual response. The objective is not to force the user to endure the raw form of a capability. It is to deliver the benefit in a form compatible with sustained use.

Key Takeaways

• Judge technologies by net value, not theoretical power. Subtract discomfort, complexity, risk, and maintenance from the headline benefit.
• Treat delivery as part of the invention. A new interface, wrapper, or protocol can unlock more value than a marginal improvement to the underlying mechanism.
• Distinguish necessary friction from accidental friction. Preserve safeguards, remove inconvenience that exists only because systems are immature.
• Design autonomous agents with bounded authority. Use spending limits, explicit purposes, expiration rules, audit trails, and rapid shutdown mechanisms.
• Evaluate repeated use. The best system is not the one that produces an impressive demonstration. It is the one people and machines can use reliably as a habit.

The connection between an unpleasant sports supplement and internet native money may initially seem incidental. It is not. Both reveal the same law of innovation: capability must be delivered in a form that the intended user can tolerate, understand, and trust.

The next era of technology will therefore be won less by whoever invents the most potent ingredient than by whoever builds the best delivery system. Artificial intelligence may supply the decision making. Programmable money may supply the movement of value. But adoption will depend on the interfaces that translate intention into safe, repeatable action.

The question is no longer merely, “What can this technology do?” The more important question is: What must be redesigned so that its power can enter ordinary life without making ordinary life harder?