A person who tests this out quickly discovers life with no limits means that nothing happens. It means never leaving the couch because there are too many possibilities to choose from. It’s scrolling through Netflix for an hour without choosing anything to watch because you can’t decide what you’re in the mood for. I may have done this once or twice.

Life requires structure, form, and constraints.

Animals have skeletal structures that determine and limit their skills. A seal isn’t great at running but is an excellent swimmer. A cheetah can’t peel a banana but can run as fast as a car. I can’t fly but I can sit at my desk for seven hours straight drinking matcha and working on theoretical math problems.

These are physical constraints, and they’re all around us. But other forms of constraint exist as well. Constraints facilitate creation. In the arts, there are countless examples of strict form focusing creativity. Haiku, sonnets. Formal guidelines push the writer to reach a more interesting place by concentrating the thought. There’s a reason we frame artwork, after all.

But not all constraints are created equally.

Some reduce capability. I’ll show you how.

A finance example is multisigs, a technology that uses multiple keys as a security measure, most often in a cryptocurrency context. The constraint here is that more than one signatory must sign off on a transaction before it is approved. This system is good for certain things; when you have an established policy that you want to update, for example. But when you apply multisigs to settlement, to permitting or not permitting a trade to go through, not only does the constraint become less useful, it also provides a false sense of security.

Multisigs are not fail-proof. Signatories can be exploited. It’s possible to swap in a fake user interface for another. So you think you’re approving one thing, but really have agreed to something else.

The approval process is constrained by humans in the least effective way. Coordinating a group of people, one of whom is always on vacation, to approve a time-sensitive trade means you’ll always be playing catch up.

So the constraints in this system cause you to lose capability as well as security.

The right constraints unleash capabilities.

Let’s go back to creativity for a moment. I am both ashamed and unashamed to admit that writing was very difficult for me. Despite the fact I have an intelligence for it. For a long time, I found myself laboring under the wrong constraints: Does the sentence sound smart? Does it sound prestigious? Am I writing about things that people will pay money to read?

These constraints weren’t allowing me to utilize my intelligence. They were hampering me at each turn. When I finally realized this, I knew I had to find a better constraint. Every time I put the pen down, I’d ask myself, “Am I interested in this material?”

And I saw firsthand the difference that changing a constraint can make. Suddenly I was able to access parts of my intuition and intelligence that had previously felt off-limits.

I applied this constraint moment by moment. Action by action. It was the lens through which I viewed every word. It wasn’t something I checked once a week or even once a day. I was checking continuously. Because that’s how you guide behavior.

That’s how you unleash capability.

The problem with AI is not that we don’t have good enough intelligence.

The problem is that this intelligence needs to come with better constraints. David Foster Wallace was a genius. And as we saw, genius can lead to danger. It is tremendously productive and yet also destructive on the same scale. AI is the same way.

AI should be incredibly powerful. The huge amounts of money that have been poured into AI show that people have great expectations of its abilities. But so far this potential has been largely unrealized. AI agents are not used in production systems. Agents have the raw intelligence needed to handle production coding, but instead of being allowed to work they are put in sandboxes because we don’t trust them.

What’s missing is the right constraint to unleash that capability.

Here’s a simple formula that took me a long time to work out:

Intelligence + the right constraint = productivity.

Inherence is the constraint technology we need.

Inherence provides effective constraints that are tailored to the abilities of AI and bring out the best in them. And, crucially, we constrain the model correctly.

There are many ways to constrain an AI agent incorrectly. You can ask, “Did your AI’s inference run correctly?” You can ask, “Were you able to watch your AI run?” You can ask, “Was your AI fake or tampered with?” Or even, “Did another AI think your AI did a good job?”

You can have the right answer to all of these questions and still the AI can go out of bounds.

Because all these things (ZKML, observability, hardware-based trust, LLM-as-judge) have value, but they don’t prove and enforce overall conduct.

The question that needs proving is, “Did your AI do what it was told?”

This is what we do. We designed our system to constrain AI in the ways that matter.

What does that look like? An AI agent that follows the rules that you give them. A purchasing agent that only buys from approved vendors and follows spending limits. That doesn’t give away your trade secrets. That doesn’t hack into other servers.

Inherence gives you peace of mind to let your AI work: It guarantees your agent’s conduct using cryptographic proof. AI is a protean shapeshifter without a body. Inherence provides the skeleton and structure for every role your agent takes on.

If you’re looking for the right constraint, give us a call–see what you can unlock.

I’ve recently developed a passion for policy, so let me take you through the salient points.

The regulations include two exemptions from registration requirements: a one-time exemption for offerings of up to $5 million over four-years, and a second exemption for offerings of up to $75 million during each 12-month period.

It also proposes something potentially more consequential: a safe harbor for crypto assets that were once associated with an investment contract.

The SEC is recognizing that a crypto asset and the investment contract surrounding its original sale are not necessarily the same thing, not forever. So if an issuer has completed the managerial efforts it promised investors—and satisfies the safe harbor’s other conditions—the investment contract can be deemed to have ended. The underlying non-security crypto asset would then no longer be treated as subject to that investment contract under the Securities Act and Exchange Act.

In essence, the crypto asset would then face fewer regulatory obligations. To me, this feels like a long-awaited turning point. Especially because of the regulatory philosophy underlying the change.

To explain the change, and what it means, we are going to have to do some historical analysis.

Cryptocurrency has historically been difficult to regulate.

The SEC’s mission is to protect investors, maintain fair markets, and facilitate capital formation. Because traditional financial regulation was built around institutions, its existing rules accomplish investor protection by placing the monitoring and registration burdens on human and institutional intermediaries.

In the years BCE (before crypto era), human intermediaries–banks, broker-dealers, investment advisers, exchanges, and issuers etc—executed transactions, maintained records, made disclosures, imposed controls.

But in 2008 Satoshi Nakamoto invented bitcoin and we entered the CE (crypto era).

One of its central innovations is that software can perform functions that previously required financial intermediaries. Assets can move through smart contracts. Markets can operate on protocols. Strategies can execute automatically.

This is enormously valuable.

But there’s a consequence: When you remove an intermediary from execution, you can also remove an important source of assurance.

This is why, in the past, crypto-regulation debates got stuck. SEC wants to add the assurance back in; but the industry wants to preserve decentralization.

So do we impose investor-protection policies on crypto, or not?

It’s the wrong question.

The right question is: in the decentralized world with programmable money, assets, and trade, how do you guarantee investor protection?

Our answer: proof.

Subscribe now

Regulation by principles.

This is where we come in. Inherence has technology to give the SEC the ability to ensure that their conditions are fulfilled, even in crypto contexts where the intermediary is missing. We fill the assurance gap.

And the good news is that this SEC is open to regulating by principle, looking at the substance of investor protection.

In Episode 203 of Law of Code podcast, Taylor Lindman, chief counsel of the Crypto Task Force, touches on this when he discusses principles-based regulation versus prescriptive regulation.

“Around technology, prescriptive regulation can get really out of date very quick, and it can become really problematic when you use the prescriptive tool,” says Lindman. “But they come with predictability. And then on the other end of the spectrum, you’ve got principles-based regulation, which is highly flexible and amenable to a lot of different circumstances.”

Regulation Crypto Assets reflects exactly this philosophy. Its disclosure requirements are explicitly principles-based: issuers disclose the material information appropriate to their circumstances. The proposed safe harbor, by contrast, creates a more prescriptive pathway for determining when an investment contract has ended.

During a meeting with the SEC on August 4th, we were able to see further evidence that this SEC is interested in principle-based regulation for vault operators.

If you’re a defi or crypto startup, it’s encouraging news. It means that you’d be able to comply with SEC regulation without the burden of a human intermediary or a return to unwanted centralization.

If you’re a vault operator, you should talk to us.

Verification without surveillance.

There is another reason this matters, and why it pays to be a policy nerd.

At the SEC’s December 2025 roundtable on financial surveillance and privacy, Chairman Paul Atkins explicitly pointed to zero-knowledge proofs as a technology that can allow people to demonstrate compliance without exposing their entire financial history or personal information.

Because we developed a novel implementation of zero-knowledge proof systems, Inherence tech is able to meet this need. Inherence proves that conditions are met without extraneous disclosure by either the party or the counterparty.

You can keep the underlying information private while making the fact that matters verifiable.

For a financial system increasingly built from software, that’s a potent new regulatory primitive.

The New Era.

Regulation Crypto Assets is not a rule yet. It’s still only a proposal. But it points toward a regulatory architecture in which these ideas become possible.

The longstanding crypto-regulation debate has often been framed as a choice between decentralization and investor protection.

It doesn’t have to be.

Removing an intermediary from execution does not require removing assurance from the system.

We can move the assurance somewhere else: into proof.

Maybe–just maybe–the new model will ultimately give regulators something better than the old model. The same level of investor protection, but evidence that is more frequent, less invasive, and machine-verifiable.

We want to help crypto and defi startups gain regulatory legitimacy. We want to help you demonstrate both your value to and your protection of consumers. So let’s talk. Our ears and inboxes are always open.

Regulation tailor-made for the crypto (common) era. That’s a song worth singing.

Share

The first was excitement.

The second was the faint unease that arrives when a technical idea stops being speculative and begins acquiring lawyers, working groups, corporate logos, and a foundation.

Until recently, the idea of an AI agent paying for something sounded like a demonstration you might watch at a conference. The agent would locate a service, send a little stablecoin, retrieve some data. Everyone would applaud. Then someone would close the laptop and the world would return to its ordinary business of subscriptions, credit-card forms, API keys, invoices, procurement departments, and Jenny in accounting who wants to know why you have expensed seventeen dollars to a company called FrogData.

Now it’s here. The x402 protocol takes an old, mostly unused piece of the web—the HTTP status code 402 Payment Required—and makes it functional. A piece of software asks for something. The server responds with a price. The software pays. The resource is delivered.

Unlike you or I, the agent does not have to create an account or choose between a monthly and annual plan. No need to invent a password containing a capital letter, a number, and a punctuation mark. It does not have to decide whether to accept promotional emails. It encounters a price in the course of its work, pays that price, and continues.

And not needing a person opens up new possibilities, as well.

A research agent might buy one current financial data point rather than subscribe to an entire database. A coding agent might rent a specialized model for twenty seconds. The amounts may be too small and the transactions too numerous to make sense inside systems built for human buyers.

Subscribe now

So here we are. Software is beginning to buy things. And not metaphorically. Not because a person clicked a button and the software completed the final step. Agents are beginning to evaluate options, select services, authorize payments, and continue working without a human.

It’s all extremely intriguing, so why did I feel uneasy?

The disappearing person

For years, people have talked about “removing friction” from payments.

Friction is usually depicted as an enemy. It shows up as the extra click, the loading screen, the forgotten password, the card that needs to be retrieved from another room. Companies spend extraordinary amounts of money shaving seconds from checkout because every second gives a customer another opportunity to remember that perhaps she does not need the electric milk frother after all.

But some friction is not accidental. Sometimes delay leaves room for discernment.

A person sees the price. A person notices the vendor. A person wonders why the shipping address is in another country. A person has the vague but useful feeling that something is wrong.

The human being in a transaction is not merely a slow payment processor. She carries context. Jenny remembers that the department budget was reduced last week, that this supplier caused trouble before, that the CEO said not to sign anything until legal reviewed the new terms. She may ignore all of these things, of course. Humans have never been a particularly reliable security system. But many of our existing guarantees assume that one will be present.

The agent economy removes the person because removing the person is, in part, the point. Agents are valuable because they can act while we sleep, compare more options than we can read, and complete a thousand small transactions that no sane employee would want to approve individually.

But when the person leaves, what happens to the guarantee she was shouldering?

A successful payment can still be a wrong action

A payment protocol can tell us that money moved correctly, but it can’t necessarily tell us whether the decision to move the money was correct.

Suppose an agent is told to purchase a dataset for a research project. It finds the data. The seller requests payment through x402. The agent sends the stablecoin. The cryptography works. The payment settles. The server delivers exactly what was promised.

The transaction is flawless.

The dataset may still come from a prohibited vendor. Its license may forbid the intended use. The price may exceed the amount the agent was authorized to spend. The request may have been planted by malicious text. The agent may have disclosed sensitive information while negotiating access.

Nothing about the validity of the payment establishes the validity of the conduct.

This is not a criticism of x402. A road is not defective because it does not decide where you ought to go.

In fact, the problem becomes visible precisely because the payment layer is beginning to work. Once agents can transact easily, we are forced to confront new questions.

Who authorized the action? Which rules applied? Did the agent remain inside its mandate?

How would anyone know?

These questions are easy to answer when there are only a few transactions and a person is watching. They become stranger, and much more difficult, when the agent is making hundreds of decisions across services that have never met one another, each operating on a fragment of the relevant information.

The temptation to record

So the familiar answer is the log. Record every action. Then, should anything go wrong, someone can reconstruct the event.

I understand the appeal. A log feels like a form of honesty. Here is what happened. Here is everything. Look for yourself.

But at machine scale, “everything” becomes impossible to keep track of.

A sufficiently detailed log may contain customer information, internal instructions, trading strategy, proprietary model behavior, credentials, pricing logic, or the private rules by which an institution operates. That is a lot of extremely sensitive information. All stored in one place. Ripe for a data breach.

And the existence of the log does not mean anyone can understand it.

A human auditor can read a dozen transactions. Perhaps a hundred. An agent may generate thousands of actions inside a workflow, with the consequence of one decision depending on the previous forty-seven. The log grows more complete and, in a strange way, less legible.

This is where the subject becomes more interesting to me, because it stops behaving like a problem with a straightforward solution. It becomes a dilemma: the apparent remedy reproduces the condition we were trying to escape. We begin with the desire for trust. We respond by demanding disclosure.The disclosure creates exposure. The exposure creates another trust problem.

A new type of receipt

At Inherence, we’ve been thinking about what should replace the guarantee that disappears when the human leaves. It’s not a better log and it’s not a person reinserted into every decision.

What is needed is proof.

Disclosure says: here is what the agent did. Examine it and decide whether you trust me.

Proof says: the agreed conditions held, and you can verify that fact without seeing the private material underneath it.

So imagine that an institution gives an agent a mandate:

Spend no more than a certain amount. Use only approved counterparties. Do not transact with sanctioned addresses. Do not expose protected information. Seek approval when the transaction crosses a defined threshold.

With Inherence, those rules can be enforced as the agent acts. The system can block a transaction that violates the mandate before the payment leaves. It can also produce a compact cryptographic receipt showing that the rules held, without exposing any sensitive data. The receipt does not explain the agent’s strategy. It answers a narrower and more useful set of questions. Was the seller permitted? Was the amount authorized? Did the transaction remain within policy? Did the rule hold?

Our work at Inherence is to make this kind of proof fast enough to work inside an autonomous system. Speed matters because a proof that arrives several seconds later belongs to a different world, one that is no longer relevant. Markets move. Agents continue. Transactions settle. If governance can’t keep up with the action, the governance is rendered moot.

Our technology works in two parts: an inline enforcer, which blocks a rule-breaking transaction before execution, and a 128-byte zero-knowledge receipt, which allows the conduct to be verified without revealing the underlying orders, sizes, or strategy. Our current proof generation is under 50 milliseconds.

We are interested in proof that arrives in time to matter.

Two pieces, one puzzle

I don’t think the right story is that x402 creates a dangerous future and Inherence arrives to make it safe. x402 solves a real problem. Agents need a way to exchange value that does not force every machine interaction through a checkout process designed for a person sitting at a desk with a credit card.

But payment and permission are different things.

x402 can allow an agent to pay.

The next layer must establish whether the agent was allowed to pay, under the rules that governed that particular action.

Perhaps this is how infrastructure develops. One obstacle disappears and reveals the shape of the obstacle behind.The internet learned how to move information before it learned how to decide which information could be trusted. Blockchains learned how to settle transactions before institutions learned how to express all the messy conditions under which they were willing to transact. Agents are learning how to act before we have finished deciding what an accountable action looks like when no person is there to perform it.

The announcement around x402 definitely deserves attention. It’s bringing the agent economy closer. But it’s also illuminating everything that’s missing.

The guarantee. The trust. The proof.

Before cars, we had no need for stoplights, seatbelts, parking lots, gas stations, snowplows, tow trucks, or the DMV. A transportation system built around horses required hay, tack, horseshoes, and the occasional carrot. A transportation system built around cars required us to rethink the road itself.

What good is a Jiffy Lube to a horse?

Most of the time, our systems evolve alongside our technologies. But sometimes a new technology arrives so quickly that we mistake the absence of infrastructure for an unsolvable problem.

That is where we are with AI agents.

People are asking urgent and reasonable questions. What should an AI agent be allowed to do? Which decisions should remain off-limits? How can a company know whether its agents followed policy? Who is responsible when they do not?

These questions are becoming more important as agents move beyond generating text and begin taking actions.

Imagine an AI procurement agent working on behalf of a manufacturer. It searches for suppliers, compares prices, evaluates delivery times, negotiates terms, and places orders. In the course of a single assignment, it may make thousands of small decisions.

The company needs to know that the agent stayed within budget, avoided prohibited vendors, protected customer information, obtained the required approvals, and did not follow fraudulent payment instructions.

Today, the default answer is usually some form of logging.

Record everything the agent saw. Record every tool it called. Record its prompts, intermediate decisions, outputs, and actions. Then, if something goes wrong, inspect the trail.

This sounds sensible because it follows an old model of trust: one party reveals what it did, and another party watches.

But at the scale and speed of AI agents, that model begins to collapse.

A sufficiently detailed record may contain customer data, proprietary workflows, model behavior, internal prompts, commercial strategy, or security-sensitive information. Storing and sharing those records creates new risks. Reviewing them requires time and expertise. And even when complete logs exist, someone still has to determine whether thousands of individual actions complied with a complicated set of rules.

The solution appears to be more visibility: better logs, more detailed logs, more standardized logs, more people reviewing logs.

But that solution produces another problem. The more information we disclose in order to create trust, the more sensitive information we expose.

That means AI governance is not merely a difficult problem.

It is a dilemma.

Problems can be solved. Dilemmas must be reframed.

There is a distinction from Alan Watt’s The 90-Day Novel that I return to often. A problem can be solved. A dilemma is a problem whose apparent solution creates another problem.

Dilemmas cannot be resolved by applying more force to the original question. They require a shift in perspective.

Writers work with this distinction constantly.

A story may begin with an apparent problem: a woman needs to stop drinking. The obvious solution is for her to stop. But that is rarely the real story, because human beings do not experience their lives as neat sequences of problems and solutions.

The more interesting questions exist underneath the visible one.

When did she stop recognizing her own needs? Why is there a paintbrush beside her bed that she has not touched in seven years? Who is Sally, and why does she refuse to answer Sally’s calls?

The writer’s job is not merely to solve the problem presented at the beginning of the story. It is to discover the question that the apparent problem has been concealing.

Funny enough, AI governance demands the same kind of thinking.

The apparent problem is that we cannot inspect everything an agent does. The conventional response is to improve our ability to inspect it.

But what if inspection is not the real requirement?

What if trust does not require one party to reveal everything it did?

The prestigious problem is not always the necessary one.

Much of the technical work around verifiable AI has concentrated on an extraordinarily ambitious problem: proving the underlying computation itself.

In simplified terms, this can mean reproducing and verifying something like a simulated computer processor—demonstrating that an enormous sequence of computational steps was executed correctly.

It is a difficult, elegant, and prestigious problem.

But it is not always the problem that businesses actually need solved.

A company using a procurement agent may not need a cryptographic reconstruction of every internal computation the model performed. It needs answers to narrower and more consequential questions:

Did the agent purchase from an approved vendor?

Did it remain within its spending limit?

Did it obtain authorization before committing funds?

Did it transmit sensitive information somewhere it was not permitted to go?

Did it follow the rules?

That distinction led us to a different plane of reference.

Instead of attempting to expose or reproduce the agent’s entire internal process, we asked whether the agent could prove specific facts about its conduct.

Trust can come from proof rather than disclosure.

In the old paradigm, trust is earned through disclosure.

One party says: Here is everything I did. You may inspect it.

In the new paradigm, trust can be earned through proof.

One party says: I can prove that I followed the agreed-upon rules. You can verify the proof without seeing everything I did.

Return to the procurement agent.

Rather than handing an auditor a complete record containing vendor information, pricing strategy, model prompts, internal reasoning, and proprietary business rules, the system could produce a cryptographic proof that confirms several facts:

The selected supplier was permitted. The transaction remained below the authorized limit. The proper approval occurred. No restricted data was disclosed.

The verifier learns that the requirements were satisfied without gaining access to the sensitive information underneath them.

This is the essential promise of zero-knowledge technology: proving that a statement is true without revealing the private information used to establish it.

In principle, zero-knowledge proofs are well suited to AI governance. In practice, traditional proof generation has often been too slow or computationally expensive for agents operating in real time.

An agent cannot pause for minutes every time it performs an action. Proof must operate at the speed of the system it is protecting.

That is the problem Inherence was built to address.

We have developed methods that generate proofs on the order of tens of milliseconds. In our benchmarks, this is up to 4,778 times faster than prior approaches.

At that speed, proof no longer has to be an after-the-fact auditing tool. It can become part of the agent’s operating environment.

An agent takes an action. The relevant policy is evaluated. A proof is produced. Another system, company, regulator, or customer can verify that the required conditions were met without receiving the agent’s private data, model internals, or strategic logic.

The result is not merely a better audit trail.

It is a different architecture for trust.

AI needs infrastructure designed for AI.

Cars did not become safe and useful because we invented a better horseshoe.

We developed roads, traffic signals, licenses, brakes, crash tests, insurance, and rules of right-of-way. We built infrastructure around the actual properties of the new technology.

AI agents will require the same kind of conceptual shift. They act too quickly and at too fine-grained a level for human observation to remain the primary basis of trust. Their logs can be too large to interpret and too sensitive to disclose. Their behavior crosses organizational boundaries, software systems, jurisdictions, and chains of responsibility.

Trying to solve this only through greater disclosure assumes that the old model of oversight can survive if we simply collect enough information.

But this is the dilemma: the information needed to create trust can itself create exposure, liability, and risk. The way out is not to inspect everything more aggressively. It is to prove what matters.

Did the agent remain within its authority?

Did it comply with the policy?

Did it do what it claimed?

These questions can be answered without revealing every detail of how the agent arrived there.

That is the shift from observability to verifiability, from trust through disclosure to trust through proof.

Building Inherence

It is also the larger vision behind Inherence.

A few months ago, I sat down to work through what I thought was a narrow technical question and accidentally did a great deal of math. By the time I put my pen down, I was looking at a result that changed the scale of the question in front of me.

I had been thinking about how to make proof generation faster. What I had found suggested something larger: that cryptographic proof could become practical infrastructure for autonomous systems.

That left me with a choice. I could treat the result as an interesting piece of mathematics and walk away, or I could accept the risk, uncertainty, and responsibility of trying to build a company around it.

I chose the latter. I chose the thrill.

I founded Inherence because I believe this technology can do real good in the world. AI will not reach its full potential merely because agents become more capable. They must also become accountable in a way that matches their speed, complexity, and autonomy.

The company began with a mathematical result, but the reason to build it was never the math alone. It was the possibility of creating a new primitive for security, governance, and trust—one designed for the systems now coming into existence, rather than inherited from the systems that came before them.

Horses needed trails. Cars needed highways.

AI agents need a new trust layer.

They need proof.

Building that layer is the work I decided not to walk away from.