There is a seductive story emerging around AI-native companies.

Instrument the business.

Let agents observe what is happening.

Give them tools.

Let them identify problems, propose fixes, write the code, run the tests, deploy the change, measure what happened, and feed what they learn back into the system.

Then run the loop again.

And again.

And again.

The company improves while you sleep.

I buy a lot of this.

What I don’t buy is the implied endpoint.

If the system can identify its own weaknesses and repair them, why should it ever stop getting better?

If every improvement makes the next improvement easier, why doesn’t the company compound forever?

And if economic performance compounds forever, why doesn’t the company eventually make infinite money?

Obviously it doesn’t.

So something is missing.

Constraints.

I started circling this problem a few months ago in Knowledge work is now executable software, where I wrote:

The next day, in I asked my AI chief of staff to introduce itself, I showed an early version of what happens when company state, rules, memory, and execution start becoming legible to agents.

More recently, in Own Your Skills or Your Job Becomes a Skill File, I wrote about the other side of the same transition: functions that used to live inside people becoming executable.

This essay is the next question.

Suppose all of that works.

Suppose the company really can observe itself, modify itself, test the modification, keep what works, and repeat.

What eventually binds?

I think recursive self-improvement is better understood as recursive bottleneck migration.

A constraint binds.

The organization relaxes it.

Throughput increases.

Then another constraint becomes binding.

The organization attacks that one.

The bottleneck moves again.

And again.

That leads to at least ten constraints.

I call them terminal constraints not because every one of them is permanently immovable. Some can absolutely be relaxed. Some move. Some disappear and expose another one underneath.

I call them terminal because they sit near the places where “just add more intelligence” stops being a sufficient answer.

The first six are mostly about performance and economics.

The last four are nastier.

They are about whether the system should be allowed to remove the next constraint at all.

Recursive self-improvement is really recursive bottleneck migration

Suppose organizational throughput at time (t) depends on a set of capacities:

The organization only moves as fast as its current binding constraint permits.

We can name that constraint:

Maybe software development is initially (B_t).

Then coding agents arrive.

Software production accelerates by an order of magnitude.

Great.

The company does not become infinitely productive. The bottleneck moves.

Maybe specification is now limiting.

So the company makes product knowledge legible to agents and turns repeatable processes into reusable skills.

Specification improves.

The bottleneck moves again.

Now coordination is limiting.

Then verification.

Then distribution.

Then opportunity supply.

Then capital.

Eventually something stranger happens: the system correctly identifies one of its own governance rules as a constraint.

Now we have a different problem.

A serious self-improving organization therefore needs a loop closer to this:

observe system
↓
identify binding constraint
↓
classify constraint
↓
estimate value of relaxing it
↓
check authority
↓
intervene
↓
verify
↓
measure the new system
↓
identify the new binding constraint
↺

Successful optimization changes the thing you should optimize next.

That is the first correction to the infinite-company story.

The second is more important:

Not every constraint should be removed.

But first, the six constraints that explain why more intelligence does not automatically create unlimited economic output.

1. Reality

The first constraint is brutally simple.

The organization exists inside an environment it does not control.

Customers have finite budgets.

Demand curves exist.

Competitors react.

Governments regulate.

Physical systems have limits.

Distribution channels saturate.

Attention is scarce.

Counterparties negotiate.

Search algorithms change.

Preferences change.

An organization might recursively optimize checkout conversion from 2% to 3%, then 4%, then 5%.

It cannot optimize conversion to 800,000%.

At some point the marginal improvement approaches zero, or the intervention starts damaging something else.

Reality pushes back.

This sounds obvious, but it matters because a lot of recursive-improvement diagrams quietly treat the company as though it were a closed system.

It isn’t.

The organization is constantly touching an external world that it does not get to rewrite.

A sufficiently good AI-native company may become much better at sensing and responding to that world.

It does not abolish it.

2. Opportunity supply

Even a perfect operating machine needs something worth operating.

Imagine an organization that can research almost any market, build software extremely quickly, run thousands of experiments, and coordinate a huge amount of synthetic labor.

Fine.

It still needs positive expected-value opportunities.

That means some combination of unmet demand, willingness to pay, reachable distribution, good economics, defensibility, timing, and enough remaining value to justify the effort.

Those opportunities are not infinite at every scale.

As execution gets cheaper, opportunity discovery gets more important.

The scarce question moves from:

Can we build it?

toward:

Where is there something worth building, buying, improving, or entering?

This is one reason I keep coming back to sensors.

Search behavior.

Customer complaints.

Usage telemetry.

Transactions.

Abandonment.

Pricing responses.

Public pain.

These are not just analytics. They are measurements of the economic environment.

A self-improving company needs a way to discover where reality is still offering gradients worth climbing.

Eventually, the quality and supply of those opportunities becomes a constraint.

3. Capital

“Burn tokens, not headcount” is directionally useful.

It does not mean tokens are free.

Compute costs money.

Distribution costs money.

Working capital costs money.

Acquisitions cost money.

Infrastructure costs money.

Legal exposure can get very expensive.

Even if inference prices keep falling, cognition still has an opportunity cost.

At some point the relevant question becomes:

Or, for a specific intervention (i):

If an agent can spend another ten million tokens improving a button from 4.80% conversion to 4.81%, that may be technically possible.

It may also be dumb.

Those same tokens might produce far more value fixing retention, investigating another market, or operating another asset.

A self-improving organization is therefore also a capital allocator.

It cannot simply maximize intelligence consumption.

It has to decide where another unit of intelligence has the highest expected return.

The moment cognition becomes abundant, allocation matters more.

4. Coordination

Adding agents increases execution capacity.

It also creates dependencies.

Worker A discovers something Worker B needs to know.

Worker C changes an interface that invalidates Worker D’s implementation.

Two agents pursue locally reasonable solutions that conflict globally.

Five agents duplicate the same investigation.

A specialist discovers a constraint that should propagate across forty other tasks.

The obvious response to abundant intelligence is:

Run more agents.

That works until it doesn’t.

More independent intelligence does not automatically produce more organizational intelligence.

Without some topology around the work, you get a compute-rich chaos machine.

This is where I think one of the less obvious consequences of the agent transition appears:

Management itself starts becoming software.

The manager was never the primitive.

Coordination was the primitive.

Humans were the implementation because, until very recently, humans were the only general-purpose reasoning substrate available.

Strip away the job title and a lot of management reduces to something like this:

sense local state
↓
interpret
↓
prioritize
↓
delegate
↓
propagate constraints
↓
detect dependencies
↓
resolve local conflict
↓
verify
↓
compress
↓
escalate

There is nothing intrinsically biological about most of those operations.

For centuries, companies were giant biological information-processing networks because there was no alternative.

That assumption is becoming optional.

Coordination does not disappear.

If anything, cheap synthetic managers may let organizations use more management, not less.

Fewer human managers could mean much more management software.

5. Absorption

This is one of the easiest constraints to discover the hard way.

I did.

Suppose twenty agents each produce genuinely useful work.

Wonderful.

Now suppose one human has to read all of it.

You parallelized execution and left absorption single-threaded.

The human becomes the bottleneck.

Scale that to 100 agents.

Then 1,000.

Then 100,000.

Eventually the organization can produce useful cognition faster than its principal can consume it.

I ran into a primitive version of this while increasing the number of agents working in parallel. Nothing was technically broken. The workers did the work.

The problem was that all roads still led back to one biological context window: mine.

That is not organizational scale.

It is parallel execution with a human queue at the end.

The product of management therefore cannot just be “more information.”

It has to be decision-relevant compression.

Consider two manager outputs.

Manager A returns 300 pages of synthesis.

Manager B returns:

Two conflicts resolved locally.

One assumption invalidated.

Recommendation: choose B.

One decision exceeds delegated authority and requires principal approval.

Manager B managed.

You can even write a crude compression ratio:

The long-term objective is something like:

The interesting number is not 10,000.

It is 3.

An organization starts to become scalable when internal activity can increase by orders of magnitude without human attention increasing with it.

6. Verification

Generation is getting cheap.

Verification is not disappearing with it.

If an organization can produce code, strategy, research, experiments, copy, financial analysis, and operational changes at machine speed, it can also produce wrong versions of all of those things at machine speed.

Eventually:

So verification itself has to become increasingly synthetic.

Workers need reviewers.

Reviewers need deterministic tests where possible.

Claims need provenance.

Actions need evidence.

High-risk changes may need independent evaluation.

Some outputs need adversarial checking.

Managers need reconciliation mechanisms.

Then you hit the obvious problem:

Who verifies the verifier?

The answer cannot be an infinite stack of reviewers.

At some point the institution needs explicit confidence thresholds, deterministic invariants where possible, independent evidence, materiality rules, and escalation boundaries.

The goal is not philosophical certainty.

The goal is enough justified confidence for the consequence of the action being taken.

A rough version is:

Without a verification layer, recursive self-improvement can quietly turn into recursive self-corruption.

The company gets faster and faster at producing changes it has not actually established are improvements.

The first six explain why the loop does not produce infinite money.

Reality pushes back.

Good opportunities are finite.

Capital must be allocated.

Agents have to coordinate.

Outputs have to be compressed.

Work has to be verified.

That is already enough to kill the naive infinite-company extrapolation.

But the remaining four are different.

They are not just questions about how efficiently the machine can improve.

They are questions about whether the machine should be allowed to make the improvement it has identified.

That is where a self-improving agent system starts turning into an institutional-governance problem.

Read more

“Own your skills because if you don’t, your job becomes a skill file.”

That line sounds dramatic until you sit with it for ten seconds.

Then it gets worse.

A skill file is not a prompt. A prompt is something you throw into a chat window and forget. A skill file is different. It is a piece of judgment written down clearly enough that an agent can run it again.

How you triage a support ticket.

How you review a contract.

How you prep for a sales call.

How you write a board update.

How you decide whether a customer is serious.

How you turn messy notes into a clean brief.

How you handle the thing that is obvious to you because you have done it 500 times.

That used to live mostly in your head. The company could own the laptop, the Slack workspace, the CRM, the docs, the calendar, the customer data, and the employment agreement. But the little operating system inside you, the taste, the memory, the exceptions, the “this looks wrong” instinct, was harder to seize.

Agents change that.

Once your way of doing the work gets written down, connected to tools, connected to memory, and run on a schedule, it becomes executable.

At that point the question changes.

The old question was:

“Will AI replace this job?”

The better question is:

“Who owns the executable version of this function?”

That is the part people are underpricing.

Garry uses a fictional support engineer named Maya to make the point. She spends two years teaching her agents how she works: how to handle an outage, calm an angry customer, write a postmortem, and make sure the same incident does not happen again. Those files can either live in Maya’s repo, where they compound with her, or in the company’s repo, where the company keeps running her judgment after she leaves. Same skills. Same work. Different owner. Very different future.

That is the new labor boundary.

Not the resume.

Not the job title.

Not the org chart.

The repo.

A lot of knowledge work is easier to decompose than people want to admit. Strip away the title and you often find a loop:

intake, classify, research, judge, draft, review, act, follow up.

That loop can become a workflow. Add memory, tools, permissions, and approval gates, and now you are looking at an agent system.

The job does not vanish in one clean cinematic moment. That is too neat. Reality will be messier.

The repeatable parts get extracted first.

The ambiguous parts get supervised.

The risky parts get approval gates.

The relational parts stay human longer.

But the direction is obvious enough to make people uncomfortable: functions become executable.

And this does not stop at workers.

Companies are exposed too.

A lot of enterprise AI startups are selling a dressed-up version of a repeatable function. Model API, prompt chain, workflow UI, enterprise sales motion. Sometimes that is enough for now. Enterprise buyers still need security, integrations, audit logs, procurement safety, compliance, and someone to blame when things break.

But the pressure is coming.

If the core of your product can be rewritten as a set of internal agent instructions, you have a problem.

If your moat is “we call the model and wrap the answer in a nice UI,” you have a bigger problem.

At some point, some companies will realize they raised $200 million to sell something that became a markdown file.

That sounds harsh. I think it is directionally right.

The strong enterprise AI companies will move toward the hard parts: governance, workflow ownership, domain data, integrations, auditability, permissions, deployment safety, and trust.

The weak ones will get compressed into the skill layer.

This also changes the startup stack.

The old version looked something like this:

credential, network, funding, team, product, distribution, proof.

Convince the gatekeepers first. Raise money. Assemble the team. Build. Then go find out if the market cares.

The new version starts somewhere else:

pain, agent workforce, instrument, ship, data, payment, proof, trust.

Start with a visible problem. Use agents to do work that used to require people. Ship something small. Measure what happens. Get paid if you can. Let proof create the trust you did not inherit.

Capital still matters. Of course it does. Capital can buy time, distribution, credibility, hiring, compliance, and speed.

But capital is no longer the same thing as permission to start.

That distinction is going to break a lot of mental models.

Garry puts it bluntly near the end of the talk. For most of history, people’s work died waiting for funding, headcount, permission, or someone else to believe first. His claim is that the new machinery lets that striving go straight to work.

You can disagree with the hype around “personal AGI.” Fine. I get it. Some of the language makes people flinch.

But the operating point is real.

Before incorporation, before a cofounder, before a logo, before a deck, one person can already be running an organization of one plus agents.

That does not make the work easy.

It makes the first move permissionless.

The same thing will happen to software markets.

Horizontal chatbots will keep getting better. ChatGPT, Claude, Gemini, and the rest will remain powerful. But general intelligence is not the same as narrow usefulness.

A general chatbot can answer almost anything.

A vertical skill system can know the specific workflow, ask the right questions, collect the right context, produce the right artifact, and route the user toward the next action.

A wedding planning assistant does not need to beat Claude at everything. It needs to understand wedding anxiety better.

A visa assistant does not need to know the whole internet. It needs to compress bureaucratic confusion.

A pitch deck assistant does not need to replace strategy. It needs to turn a repeated review function into an executable workflow.

The model is rented.

The market context can be owned.

That is the part I keep coming back to.

The next wave of AI products will not only be “chatbots.” That word is already too small. They will be narrow skill systems wrapped around specific pain.

Some will be tiny.

Some will look silly.

Some will make no money.

Some will quietly become companies.

The winners will not win because they had the cleverest prompt. Prompts are cheap. The durable parts are context, workflow, memory, trust, distribution, and knowing where human approval belongs.

Most people will use agents as faster autocomplete.

Better operators will turn repeated work into reusable skills.

The best operators will turn skill systems into products.

That is the ownership question.

Your skills can stay trapped in your head. That feels safe, but it makes you the bottleneck.

Your skills can be extracted into someone else’s system. That may make you productive, but the asset compounds away from you.

Or you can build and own your own skill system.

That is the uncomfortable fork.

Every function wants to become a skill file.

Every skill file wants to become a workflow.

Every workflow wants to become a product.

And every person has to decide whether their judgment compounds for them or for someone else.

That is why Garry’s line matters.

Own your skills, or your job becomes a skill file.

Someone will own it.

The only question is whether it is you.

Related:

I wrote a version of this thesis in May: [Knowledge work is now executable software]. That post was about the shift from documents, meetings, tasks, and prompts into constrained workflows that agents can execute.

I also wrote about my own AI chief-of-staff experiment here: [I asked my AI chief of staff to introduce itself]. That was an early artifact of the same idea: one person turning company state, memory, and daily execution into something agents can help operate.

Subscribe now

This is what I asked Aris this morning at the start of the day: “Good morning, Aris! What are we doing today? I’m going to grab coffee at Medici, I’ll be back in 20mins. Run the company while I’m gone. Run today’s operating report, create and assign the next best tasks to the right skills/workers for execution. When I’m back show me what got done, what needs approval and today’s k score”

Back from coffee report

The dashboard generated by Aris for today’s command center while on my coffee run

Follow @chrisandaris on Instagram to see how we close the loop today.

Revenue. Customers. Bugs. Follow-ups. Product ideas. Pricing. Outreach. Support. Cash runway. The thing that shipped yesterday. The thing that broke last night. The thing that might work if you finally give it three focused hours.

That reload is expensive.

And weirdly, AI does not automatically fix it.

In some ways, AI makes it worse.

Once software becomes cheap to build, the number of possible things you can build explodes. Every idea feels close. Every workflow feels automatable. Every product surface feels like it could exist by tonight if you just point the right agent at the right repo.

So the bottleneck moves.

It is no longer only:

Can we build this?

Now it is:

What should we build?
Why now?
What should not be built?
What constraints matter?
How will we know it worked?
What happens after it ships?

That is the part people are still underestimating.

AI did not eliminate knowledge work. It changed the unit of work.

Knowledge work is becoming executable software.

Not just code. The work itself.

A customer follow-up can become an executable task.
A product idea can become a spec.
A spec can become instructions for an agent.
Those instructions can become tested output.
A daily plan can become an operating system.
Feedback can become tomorrow’s priorities.

The old unit of knowledge work was the document, the meeting, the task, the email, the spreadsheet, the slide deck.

The new unit is the constrained workflow.

That is the difference between asking AI for help and actually getting work done.

I have been thinking about it with a simple formula:

AI tokens are the raw labor. Model calls. Compute. Agent time. The ability to generate, rewrite, analyze, code, summarize, extract, plan, and execute.

But tokens by themselves are not work.

Unconstrained tokens create noise. Constrained tokens create output. Verified constrained tokens create useful work.

A vague prompt creates motion.

A constrained task creates work.

Most people are still using AI like a better chat window. They ask a question, get an answer, copy a few pieces, then ask another question.

That is useful. I do it too.

But it is not the end state.

The deeper shift happens when AI starts operating inside memory, rules, objectives, boundaries, success criteria, tests, customer feedback, revenue signals, and daily execution loops.

That is when knowledge work starts becoming executable.

This is also where Bora’s Law gets more interesting.

I originally framed it as:

I = Bi × C²

Intelligence scales with the clarity of constraints, not compute alone.

Bi is base intelligence. The model, the person, the raw capability.

C² is the compounding effect of constraints. Clear objectives. Clear boundaries. Clear success criteria. Clear memory. Clear feedback.

Better constraints do not just make output a little better. They shrink the solution space. They make good outcomes more likely.

But I now think there is a hidden variable:

k is automation friction.

(For the math nerds: k is bounded 1 ≤ k < ∞. k = 1 means there’s no human in the loop - you sleep, you wake up, money’s in the bank. k → ∞ means you’re doing everything by hand. Most of us are somewhere between 5 and 20 on a good day.)

It measures how much manual glue still sits between intent and finished work.

High k means you still have to carry too much in your head. You remember the context. You rewrite the prompt. You copy the output. You open the repo. You create the task. You check the files. You update the tracker. You write the follow-up. You decide what happens next.

Low k means the system carries more of that for you. The context is loaded. The rules are known. The task format is standard. The agent knows what to read. The output has tests. The result updates memory. The dashboard shows what changed.

The lower your k, the faster intent becomes output.

Think about two people trying to get across a city.

One is walking. One has a car.

They may have the same destination and the same motivation. The difference is not desire. One has less friction between wanting to arrive and actually arriving.

That is now happening in knowledge work.

Two founders can have the same models. The same AI coding tools. The same ideas.

The founder with better constraints and lower automation friction will move faster.

Not because they are magically smarter.

Because their system converts intent into output with less drag.

That is what I am paying attention to now.

Not just model quality.

Not just prompt quality.

k.

How many manual steps sit between the idea and the shipped thing?

How many times do I have to reload context?

How many decisions am I remaking from scratch?

How often does an agent need me to explain a pattern that should already be captured?

How much of the company still lives inside my head?

That last question bothers me the most.

For a long time, the founder’s brain is the company’s operating system.

You remember the priorities. You remember the customer conversation. You remember why pricing changed. You remember which product matters this week. You remember which feature is a distraction. You remember what failed last time.

That works until it doesn’t.

At some point, the cost of reloading the company into your head becomes one of the biggest hidden taxes on execution.

AI can help, but only if you stop treating it like a chatbot and start treating it like part of the operating system.

I have been building a local AI chief-of-staff system for myself.

The point is not that it chats with me.

The point is that it helps me plan the day, track what matters, create structured tasks for other agents, surface follow-ups, separate business-hour execution from after-hours building, and reduce the amount of company state I have to carry in my head.

That sounds small.

It is not.

It is just lowering k.

The system does not replace judgment. It gives judgment a better interface.

It can say:

This is today’s cash priority.
These follow-ups are due.
These products are active.
These speculative ideas should wait until tonight.
This task should go to a coding agent.
This one should go to a writing agent.
This one needs a human decision.
This outcome is blocked because the source file is missing data.

That is what I mean by knowledge work becoming executable software.

The work is no longer just a pile of thoughts, notes, messages, and intentions.

It becomes structured enough that agents can act on it.

The company starts to look like a compiler.

It takes messy inputs:

Customer calls.
Market signals.
Support messages.
Revenue data.
Product ideas.
User feedback.
Random insights at 2 a.m.

And it compiles them into:

Priorities.
Constraints.
Tasks.
Agent instructions.
Tests.
Follow-ups.
Reports.
Shipped work.

The founder’s job changes.

The founder does not disappear. I actually think the founder becomes more important.

But the founder moves up the stack.

Less manual execution.
More constraint design.

Less “do this task yourself.”
More “define what success means.”

Less “remember everything.”
More “build systems that remember.”

Less “write every prompt from scratch.”
More “encode repeatable workflows into reusable rules, specs, and skills.”

The founder becomes the constraint architect.

That sounds abstract until you see how practical it is.

A good constraint says:

Here is what we are trying to do.
Here is what is out of scope.
Here is what files matter.
Here is what should not change.
Here is what success looks like.
Here is how to test it.
Here is when to stop.
Here is what to do if it fails.

That is management.

AI tokens are labor. Constraints are management.

Without management, labor creates chaos.

With management, labor creates leverage.

This is why feedback loops matter too.

The formula should probably be:

AI tokens are compute and agent labor.

Constraint quality is the clarity of objectives, boundaries, success criteria, memory, and rules.

Feedback loops are tests, customers, revenue, logs, reviews, and the daily operating system that tells you whether the work mattered.

A coding agent without tests can produce code.

A coding agent with tests can produce verified code.

A product agent without customer feedback can produce features.

A product agent with customer feedback can produce useful features.

A company without revenue feedback can produce activity.

A company with revenue feedback can produce direction.

That is the difference between motion and work.

The next generation of companies will not be defined only by how many people they hire. They will be defined by how well they convert AI tokens into verified output.

Some companies will have high k.

They will use AI everywhere, but every workflow will still depend on manual handoffs, repeated context, inconsistent prompts, unclear ownership, and human memory.

Other companies will have low k.

They will have systems that turn intent into tasks, tasks into specs, specs into agents, agents into outputs, and outputs into feedback.

Those companies will feel different.

They will be smaller than expected.
They will move faster than expected.
They will look chaotic from the outside.
They will have fewer meetings.
They will have more internal compilers.
They will have less status theater.
They will have better operating memory.

The work will not vanish.

It will become executable.

The question is not whether AI can write code, summarize documents, draft emails, or analyze spreadsheets.

We already know it can.

The question is whether you can build an operating system around it that knows what should be done, what should not be done, what good looks like, and how to learn from what happened.

That is where the leverage is.

The future belongs to people who can turn intent into constraints, constraints into agents, and agents into verified output.

Not because they have the most tokens.

Because they know how to make tokens do useful work.

Knowledge work is becoming executable software.

And the winners will be the people and companies with the best constraints, the lowest k, and the fastest feedback loops.

If this resonates, send me a note. I’m especially interested in talking to founders building internal AI operating systems for their companies.

We assume someone understands the system. We assume they can read docs, follow conventions, and reason about structure. REST works in that world because humans fill in the gaps. They know which endpoint to call, what already exists, and what shouldn’t be duplicated.

Coding agents don’t.

They don’t explore systems the way humans do. They don’t maintain a stable internal map of your architecture. They generate.

So when you give them a surface like a typical REST API, you’re not giving them structure. You’re giving them a space where multiple valid-looking solutions can exist at the same time.

That’s where things break.

They hallucinate endpoints that almost look correct.
They recreate logic that already exists under a different name.
They apply authentication inconsistently because nothing enforces it globally.

You can try to fix this with better prompts. You can add more context, more rules, more documentation. It helps, but only marginally.

Because the problem isn’t missing information.

The problem is that the system allows too many valid paths.

This is where I started thinking about constraints differently.

If you’ve followed my work, you’ve seen versions of this idea through WBS (What–Boundaries–Success) and Bora’s Law.

WBS is a way of defining a task so clearly that there’s no ambiguity about what needs to happen, what is allowed, and what success looks like.

Bora’s Law goes one step further. It argues that intelligence doesn’t scale with more compute or more data. It scales with better constraints.

In other words, the smarter the system appears, the more tightly its solution space is shaped.

When you look at coding agents through that lens, the failure becomes obvious.

We’ve been increasing their capabilities while leaving the constraint surface wide open.

REST APIs are a perfect example of that.

Every endpoint is a new branch in the solution space.
Every variation in naming or structure creates another valid path.
From the agent’s perspective, there isn’t one correct answer. There are dozens of plausible ones.

So instead of trying to make the agent smarter, I removed the ambiguity.

I collapsed the surface area.

Instead of exposing dozens of endpoints, everything goes through a single interface. The system doesn’t ask, “which route should I call?” It asks, “what is the intent?”

That intent is then resolved under a set of constraints.

Authentication is applied consistently because it’s not optional anymore.
Duplication disappears because there aren’t multiple entry points to recreate.
Hallucination drops because there’s nothing to hallucinate at the routing layer.

What changes is not just the implementation, but the structure of the problem itself.

You move from a system with many loosely defined paths to one where the space of possible actions is tightly controlled.

This is exactly what Bora’s Law predicts.

When constraints are weak, systems behave unpredictably, even if they are powerful.
When constraints are strong, systems appear intelligent because they consistently produce valid outcomes.

Intent-based APIs are one way of encoding those constraints directly into the architecture.

Instead of distributing logic across endpoints, you centralize resolution. Instead of relying on the caller to know the system, you make the system responsible for interpreting the request.

In that sense, this isn’t really about APIs.

It’s about shifting from instruction-following systems to constraint-resolving systems.

That shift shows up in different forms.

In WBS, it shows up as defining What, Boundaries, and Success before execution.
In constraint-based transfer learning, it shows up as teaching systems how to operate within a structured space instead of memorizing patterns.
In what I’ve been calling the reasoning layer, it shows up as compiling intent into valid actions under constraints.

The pattern is the same.

Reduce ambiguity.
Shape the solution space.
Let the system resolve within it.

Coding agents didn’t create this problem. They just made it impossible to ignore.

When a human writes bad code, you catch it in review.
When an agent operates in an ambiguous system, it produces something that looks correct but isn’t grounded.

That’s a different class of failure.

And it requires a different class of solution.

My view is that we’re going to see a gradual collapse of traditional API surfaces.

Not because REST is wrong, but because it assumes a type of consumer that is no longer the primary one.

As agents become the default builders, the systems we design will have to reflect how they operate.

Less exploration.
More resolution.
Fewer paths.
Stronger constraints.

Intent APIs are one step in that direction.

Not as a replacement for everything, but as a recognition that the interface between systems and builders is changing.

And once that interface changes, everything built on top of it starts to change too.

If you’re wondering what this actually looks like in practice, the change is surprisingly simple.

A typical REST setup for a single resource might look like this:

POST   /api/users
GET    /api/users
GET    /api/users/{id}
PUT    /api/users/{id}
DELETE /api/users/{id}

Five endpoints for one resource.

Add four more resources and you’re at twenty-five.

Each one is a branch an agent can hallucinate, duplicate, or misuse.

With an intent-based approach, that entire surface collapses to one:

POST /api/intent

{
  “model”: “User”,
  “action”: “create”,
  “payload”: {
    “name”: “Chris”,
    “email”: “chris@example.com”
  }
}

The system doesn’t ask “which route should I call?”

It asks: which model, which action?

And then resolves that request under constraints.

Listing users uses the same entry point:

{ “model”: “User”, “action”: “list” }

Even custom behavior doesn’t expand the surface:

{ “model”: “User”, “action”: “custom”, “command”: “me” }

The number of valid entry points drops from many to one.

That’s where most of the reliability comes from.

And it goes further than routing.

Instead of distributing authentication across endpoints, the system enforces it structurally through distinct surfaces — each with its own contract:

POST /api/intent         → Authenticated users (JWT)
POST /api/admin-intent   → Admin-only access
POST /api/guest-intent   → Public / unauthenticated
POST /api/machine-intent → API key (SDKs, agents, M2M)

An agent can’t “forget” authentication, because there isn’t an endpoint outside of a surface.

The constraint is architectural, not something you document and hope gets followed.

If you want to try it, getting started is straightforward.

pip install intent-api
npm install @intent-api/react

On the backend:

from intent_api import IntentRouter
from app.intent_services.user_service import UserService

router = IntentRouter(debug=True)
router.register(”User”, UserService())

app.include_router(
    router.build(
        get_user=get_current_user,
        get_db=get_db,
    )
)

On the frontend:

import { useIntentQuery, useIntentMutation } from “@intent-api/react”;

const { data: users } = useIntentQuery(”User”, “list”);
const createUser = useIntentMutation(”User”, “create”);

One endpoint. Every intent.

No routes to hallucinate.

If you’re curious to explore further:

https://www.intentapi.dev
https://www.intentapi.dev/docs

If you’re working with coding agents, I’d be curious if you’ve seen similar failure modes.

Not a quick skim. I mean reading files, tracing execution paths, counting things, understanding how the system actually runs.

What I found surprised me.

This thing is not a thin wrapper around a model. It’s a 512,000+ line system spread across 1,800+ files. The model call is just one piece. The real system is everything built around it.

At the core, there’s a single agent loop living in query.ts. It’s roughly 1,700 lines long and runs as an async generator with a while(true) that never really “ends” in the traditional sense. Every iteration follows the same cycle: construct context, call the model with streaming, detect tool usage, execute tools, update state, and loop again. That loop is the engine. Everything else feeds into it.

Planning isn’t a separate module. It emerges from how the loop is structured and how the prompt is built. The system prompt itself is hundreds of lines long and dynamically assembled with tool descriptions, environment state, git context, and memory. A big part of the “intelligence” is not in the model, it’s in how constraints and context are injected before every call.

Memory is not just chat history. There’s a full system around it. Conversations are persisted as JSONL transcripts, there’s a directory for long-term memory (CLAUDE.md and related files), and the system actively decides what to keep, what to trim, and what to summarize. There are multiple layers of context control running every loop iteration. Tool outputs get budgeted and pushed to disk if they’re too large. Older messages get snipped. There’s a micro-compaction pass, a full auto-compaction pass, and even a reactive compaction when the model hits context limits. This isn’t one strategy, it’s a stack of them.

The tooling layer is where things get really interesting. There are over 40 tool directories and more than 50,000 lines of tool-related code. Tools aren’t just “functions the model can call.” They’re orchestrated. Some are marked concurrency-safe and can run in parallel, others are forced to run sequentially. There’s a whole execution pipeline that handles permissions, batching, streaming execution, and result injection back into the loop.

And sub-agents are not some special system. They’re literally the same loop running recursively. There’s a tool called AgentTool that spins up another instance of the agent with its own context and lifecycle. So when the system “delegates,” it’s not switching modes. It’s spawning another loop.

Security is treated as a first-class architecture concern. There’s over 12,000 lines dedicated just to parsing and classifying bash commands before execution. On top of that there’s a permission system spanning thousands of lines and even a classifier that decides what can run automatically versus what needs approval. This is what happens when you give an AI a shell and take the risk seriously.

One thing that stood out immediately is how tightly everything is coupled to Anthropic’s API. There are over 100 files importing their SDK directly. The so-called “multi-provider” setup is really just different hosting layers for the same protocol. The entire runtime, especially the streaming and tool semantics, is built around that contract.

There are also dozens of feature flags baked into the build. Nearly 90 of them. Which means the version you run locally is not necessarily the version they run internally. The system is designed to shape-shift depending on configuration.

And then there are small details that tell you how seriously they’re playing the game. Things like anti-distillation mechanisms where fake tools are injected into the system to poison training data extraction. That’s not theory. That’s in the code.

The biggest takeaway for me is this:

the model is not the product.

The product is the system around the model. The loop, the tools, the memory, the constraints, the orchestration.

We’re entering a phase where raw model capability matters less than how you structure the environment around it.

And after looking at this codebase, it’s very clear where the real engineering effort is going.

We've spent billions scaling compute. We've built models with trillions of parameters. Yet a simple customer support bot still hallucinates contact information that doesn't exist.

The problem isn't the models. It's that we're missing an entire layer in the AI stack.

The $100 Billion Problem

Let me show you what's actually happening in production:

# What developers write

# What actually happens
# - 25% chance of hallucinating legal terms
# - 15% chance of wrong tone
# - 10% chance of contradicting company policy
# = 50% chance something goes wrong

Every company using AI is secretly building the same thing: elaborate retry loops, validation chains, and prompt engineering hacks. It's like building web apps before we had databases - everyone reinventing persistence.

The Missing Layer

Today's AI stack looks like this:

That void? That's where Reasoning as a Service lives.

Enter Constraint-Driven Intelligence

After months of building AI systems that process 10,000+ lines of code daily, I discovered something counterintuitive: intelligence doesn't scale with compute - it scales with clarity of constraints.

This led to a mathematical framework I call Bora's Law:

I = Bi(C²)

Where:
- I = Intelligence (effective, reliable output)
- Bi = Base intelligence (the LLM's capability)
- C² = Constraint clarity squared

The implications are profound. Instead of throwing more compute at problems, we need to throw more constraints.

How Reasoning as a Service Works

RaaS acts as an intelligence compiler. It takes fuzzy human intent and compiles it into constrained, verifiable AI execution:

Before: Raw AI (unreliable)

After: Reasoning Layer (reliable)

Under the hood:
- Fuzzy intent is clarified
- Constraints are applied
- Outputs are verified

All you see is: it works.

The reasoning layer:

1. Injects constraints into the prompt using Natural Boundary Theory

2. Forwards to the appropriate LLM

3. Verifies output meets all success criteria

4. Retries intelligently if verification fails

5. Returns guaranteed reliable output

The Natural Boundary Theory

Complex tasks naturally decompose into atomic units with inherent boundaries. By identifying these boundaries, we can:

• Constrain AI to valid solution spaces

• Verify outputs systematically

• Retry only failed components

• Build confidence through composition

Example: "Build a web scraper" naturally decomposes into:

• Parse HTML (bounded by valid selectors)

• Extract data (bounded by schema)

• Handle errors (bounded by retry logic)

Each boundary becomes a constraint. Each constraint becomes verifiable.

Real Production Results

Using this approach in my own systems:

• Hallucination rate: 30% → < 5%

• Retry success: 95% within 3 attempts

• Code generation: 100 → 10,000 lines/day

• Reliability: "Usually works" → "Always works"

Why This Changes Everything

1. Universal Need

Every AI API call needs reasoning. From chatbots to code generation to autonomous agents - unreliable AI is unusable AI.

2. Infrastructure Play

RaaS isn't an app or a model. It's infrastructure. Like Stripe for payments or Twilio for communications, every AI application will build on top of it.

3. Network Effects

Every API call makes the system smarter:

• Discover new constraint patterns

• Identify failure modes

• Optimize verification strategies

• Share learnings across all users

4. Economic Alignment

Pay only for reliability. At $0.001 per call, preventing one production failure pays for thousands of requests.

This isn’t prompt engineering. It’s reasoning, compiled and enforced at scale. We don’t scale tokens, we scale reliability.

Who Needs This Today?

• Production AI Apps: Reduce customer-facing failures

• AI Coding Tools: Ensure generated code actually works

• Enterprise Automation: Meet compliance requirements

• Autonomous Agents: Operate within safety boundaries

• AI Startups: Ship reliable features faster

The Path Forward

Reasoning as a Service represents a fundamental shift in how we build AI systems. Instead of hoping models get smarter, we're making their outputs systematically reliable.

The companies that adopt this approach will ship AI features that actually work. The ones that don't will keep writing elaborate retry loops and apologizing for hallucinations.

Join the Reasoning Revolution

We're building the reasoning layer for the world's AI applications. Want to eliminate hallucinations in your AI systems?

Everyone wrote their own storage logic. Every app had its own way of fetching, filtering, and updating information. If you wanted to build a payroll system, a customer directory, or a logistics dashboard — you had to build your own data logic from scratch.

It worked. Until it didn’t.

As apps grew, the pain grew faster:
• Changes broke everything
• Logic was duplicated across systems
• Developers spent more time firefighting than shipping

Eventually, the pain forced a question no one had asked clearly before:

What if we separated the logic of data from the logic of applications?

The Database became a new layer instead of a product.

In 1970, Edgar F. Codd proposed something radical: the relational model. Instead of telling the computer how to store or access data, developers could simply declare what they wanted — in a language that was both human-readable and machine-optimizable.

That language became SQL. And that abstraction became the relational database.

Suddenly, everything changed:
• Apps got simpler
• Logic got reusable
• Scaling became manageable

This wasn’t just a better tool. It was a new layer in the stack — one that became inevitable as complexity increased.

I Didn’t Plan to Invent a Category Either

When I built Search+, Zenplus, and Novaheadshot, I wasn’t thinking about theory. I was just trying to move fast.

I used LLMs like agents — vibe coding my way to working products. And it worked… until it didn’t.

The AI could write code. But it couldn’t hold context. It couldn’t reason. And it couldn’t stop hallucinating.

At some point, I realized I wasn’t coding anymore — I was correcting. And I started asking myself the same kind of question Codd did:

What if we separated the logic of reasoning from the logic of implementation?

Reasoning is the Missing Layer

Right now, building with LLMs feels like working with flat files in the ‘60s:
• Every agent prompt is handcrafted
• Every hallucination is a new bug
• Every feature needs bespoke constraints

And when complexity grows, everything breaks downstream.

I call this the Reasoning Ceiling — the point where pattern-matching falls apart and real-world logic starts leaking through the cracks.

So I built a new layer: the Reasoning API. It sits between you and the model — turning vague prompts into structured constraints, clarifying ambiguity, and enforcing consistency across the entire system.

Instead of just asking what to build, it encodes:
• What you want
• What must be true
• What should never happen
• And what success looks like

In other words — it reasons before it builds.

Why This Is a Category (Not Just a Product)

The database became a category because:
• The problem was real
• The pain was exponential
• The abstraction was inevitable

Reasoning APIs are following the same path.

The more AI systems we build, the more brittle our logic becomes. The more agents we deploy, the more hallucination risk we absorb. And the faster we ship, the more review and rollback slow us down.

At scale, the bottleneck isn’t code. It’s reasoning.

We don’t need better prompts. We need a reasoning layer.

A Final Thought

In 1980, nobody said, “I’m in the database industry.” They just wanted to build software that worked. But eventually, the world realized: databases weren’t a nice-to-have — they were critical infrastructure.

That’s where we are now with AI. We’ve built enough agents. We’ve written enough prompts. Now it’s time to build the reasoning layer that makes it all scale.

I call it the Reasoning API. But what matters isn’t the name — it’s the pattern.

The database became inevitable when the world hit the data ceiling. The Reasoning API becomes inevitable now that we’ve hit the reasoning ceiling.

If you’re building with AI and tired of chaotic prompts, silent bugs, or hallucinated logic — join the waitlist.
👉 [Join the Reasoning API beta]

I just wanted to build fast.
So I did what every founder with no team and a hundred ideas does:
I opened Cursor, fired up Sonnet, and started vibe coding.

Three apps later - Search+, Zenplus, and Novaheadshot - I had over 20,000 users, tons of product feedback, and something I didn’t expect:

A wall.

Agents were hallucinating.
Code review time was eating me alive.
The bigger the feature, the messier the prompts.
And I kept realizing something no one talks about:

The bottleneck isn’t code.
It’s reasoning.

I was hitting what I now call the Reasoning Ceiling - the point where pattern-matching breaks down and the model can’t go any further.

So I started writing down every pattern, every failure, every workaround.
Eventually, it clicked. I wasn’t just coding - I was discovering the rules of AI-first development.

That’s when I built the Reasoning API - a system that turns natural prompts into structured specs, detects ambiguity, and reduces hallucination across the stack.
It’s how I went from “shipping chaos” to building production-grade tools as a solo founder.

In this post, I’ll share:

• What I learned building 3 real apps with just AI and vibes

• The theories that changed how I think about intelligence

• The tools I had to build just to move faster

• Why the Reasoning API might change how AI apps are built next

And at the end - if you’re building with AI and tired of guessing - you’ll be able to try it too.

Quick note: The system I developed from this journey is called The ReasoningAPI. It’s a reliability layer that turns your intent into verifiable specs to stop AI hallucinations.

If you're already feeling this pain, you don't have to wait until the end of the article. You can join the private beta waitlist right now.

👉 Join The ReasoningAPI Private Beta Waitlist

Vibe Coding Three Real Apps

I wasn’t trying to prove a theory. I was just trying to ship.

I built:

• Search+ – A document search tool that lets users ask real questions of thousand-page PDFs.

• Zenplus – A voice AI that answers calls, schedules appointments, and runs on autopilot.

• Novaheadshot – An AI tool for generating professional, studio-quality headshots.

I built all three solo - using Cursor, Claude Code, LLMs, and a lot of caffeine.

No fixed roadmap. No heavy planning.
Just a prompt, an agent, and a loose vision of what I wanted to exist.

And it worked.
I was shipping fast.
Users were signing up.
Features were flying out the door.

But over time… I started noticing the cracks.

• Agents would refactor entire files for no reason.

• I’d spend days reviewing and rewriting AI-generated code.

• Features that felt "done" would break the moment a new one was added.

• The same prompt would work on Monday and fail on Thursday.

I was moving fast - but burning out.
And I started asking myself:

Why does AI coding feel so good at first… and so chaotic when it gets serious?

The Wall: When Vibes Weren’t Enough

At some point, I realized I wasn’t coding anymore - I was firefighting.

The AI could generate a button, a handler, even a whole backend flow.
But it didn’t know why I wanted it.
Or what should be out of scope.
Or when something was “done.”

Every time I hit friction, it was the same root problem:

The agent didn’t know how to reason.

It knew how to autocomplete.
It didn’t know how to hold constraints in place.

And the more complex the app got - the more the hallucinations crept in, the more review time exploded, the more I started second-guessing whether AI could even scale as a dev tool.

That’s when I realized:
I was hitting the Reasoning Ceiling.

The limit where pattern-matching breaks down.
Where LLMs stop feeling magical and start feeling… brittle.
Where the agent sounds confident, but delivers code that collapses under real world complexity.

I would spend Monday morning creating the perfect PRD for a comprehensive feature that would’ve taken me months to build as an engineer pre-AI.
I’d spend the rest of the day using Cursor and Claude Code to generate the code.
Then I’d spend the rest of the week reviewing that code, rewriting the broken parts, and plugging in missing logic.

Yes - code generation was exponentially faster.
But code review became the bottleneck.
I wasn’t building faster. I was just shifting the pain downstream.

That’s when I stopped prompting and started asking a different question:

What if we taught the AI what we wanted — not how to do it, but what mattered, what shouldn’t break, and what success actually looked like?

That’s when I started writing down patterns.
The things I kept saying over and over in prompts.
The boundaries I kept forgetting to specify.
The success criteria I kept assuming the model “got.”

And little by little, that became a language.
That language became a theory.
And that theory became the backbone of everything I’ve built since.

From Chaos to Clarity: The Theories That Changed Everything

The first breakthrough came when I started thinking in triples:

What I wanted.
Boundaries I needed to respect.
Success I expected to see.

That became the core of everything - a simple mental model I called WBS:
What – Boundaries – Success.

Let me show what this looks like for a real feature

Before (A “vibe” prompt):

Hey Claude, add a rate limiter to my login API to stop brute force attacks.

This seems clear, but the AI is forced to guess a dozen details. The result is often wrong.

After (A What-Boundaries-Success Spec):

Feature: Authentication {
  What:
    - "Prevent brute force login attacks by limiting requests per IP."
    
  Boundaries:
    - "Limit: 10 failed attempts per IP per hour."
    - "Use Redis for tracking counts."
    - "Do not rate-limit successful logins."
    
  Success:
    - "An IP is correctly blocked after the 11th failed attempt."
    - "A legitimate user is never blocked."
}

The difference is night and day. There's no ambiguity. I'm no longer asking the AI to read my mind; I'm giving it a precise, testable blueprint.

The moment I did that, the hallucination rate dropped.
The model started behaving more predictably.
Code generation felt less like gambling, more like collaboration.

That was the moment I realized something:

Intelligence doesn’t scale with more compute. It scales with clearer constraints.

That idea became Bora’s Law - a principle I now live by:

🧠 Bora’s Law

I = Bi(C²) - Intelligence scales exponentially with constraints, not compute.

It wasn’t about making the AI smarter.
It was about limiting the solution space so it couldn’t wander off and invent things I didn’t ask for.

Later, I developed ideas like:

• CBTL (Constraint-Based Transfer Learning) - teaching the system how to generalize constraints across tasks and domains.

• Constraint Graphs - so boundaries could be reused across features, apps, even different LLMs.

• IntentAPI - a new constraint-based API architecture aimed at reducing hallucinations.

• Natural Boundary Theory - a fundamental solution to recursive decomposition in constraint-driven systems: break work down until it reaches naturally executable units, not arbitrary task lengths

  • Human-sized chunks

  • Measurable outcomes

  • Implementable in under 2–4 hours

Instead of “guess-and-check” loops, the system now decomposes with intention - and stops when each part becomes clearly human-executable. It’s how I prevent infinite agent recursion and keep reasoning grounded.

All of these ideas - and more - are part of what I now call Intent Science: a full mathematical and engineering framework for turning ideas into reality through structured constraints.

These practical insights grew into a full engineering philosophy. For those who want to go down the rabbit hole, I’ve published the deeper theory here:
Fundamental Theories of Intent Science (Substack)

And eventually, all of this turned into something real - something I could call an actual product.

The Reasoning API.

Building the Reasoning API: My Personal Productivity Engine

At some point I realized:
I was spending more time re-prompting and reviewing than actually building.
So I asked: What if I didn’t just write specs for the model? What if I built a system that did it for me?

That’s what the Reasoning API became.

A layer that sits between me and the LLM.
It takes in natural prompts - messy, human ones - and converts them into clean, structured WBS specs.

Then it runs those specs through a pipeline I built:

• Detects ambiguity → asks clarifying questions

• Decomposes requests using natural human boundaries

• Reduces hallucination by using a growing library of constraints and enforcing historical constraints

• Reuses success criteria across features

• Automatically maps vague intent into concrete boundaries

For example, when building a core feature for Zenplus, I gave it a high-level request for a "daily approvals workflow."
The Reasoning API came back with a complete constraint discovery plan.

This is what the engine looks like in action. You’ll notice:

• Each part of the system is scoped by domain

• Constraints are organized by WBS

• Boundaries link to AISpecs and IntentAPI structures

• The system prepares to systematically discover constraints across all domains

This isn't a toy example.
This is a production-grade spec for a complex backend feature, identifying everything from the database models to the business logic.
It's the thinking scaffold that lets me build enterprise features solo.

It wasn’t just better outputs.
It was faster everything:

• Code generation time dropped

• Review time dropped

• Rollbacks dropped

• Features became easier to ship and keep stable

When I hooked it up to Cursor, it felt like my AI pair programmer finally understood me.
When I used it with Claude Code, it stopped generating "maybe this?" code and started hitting real targets.

And the biggest surprise?
It worked across all three apps - Search+, Zenplus, and Novaheadshot - even though they’re totally different products.

Because what I had built wasn’t a feature.
It was a thinking scaffold.
And once I had that, the rest moved fast.

Try It Yourself - Reasoning API is Now in Beta

I didn’t build this for fun.

I built it because I had to.
Because vibe coding stops working when the stakes get real.
Because LLMs don’t need more prompting - they need clarity.

And now, that clarity is available to you too.

The Reasoning API is in private beta. It integrates with tools such Cursor and Claude Code through the MCP (Model Context Protocol).
It’s the engine behind how I built Search+, Zenplus, and Novaheadshot - the same tools that now serve over 20,000 users.

Everything I’ve learned, every framework I developed - WBS, Bora’s Law, CBTL, The Natural Boundary Theory, the IntentAPI - it’s all baked in.

• Structure your requests

• Reduce hallucination

• Speed up implementation

• Catch ambiguity before it becomes tech debt

If you’re building with AI - agents, apps, internal tools, whatever - and you’re tired of chaotic prompting and brittle outputs, this might be the layer you've been missing.

👉 Join the Reasoning API waitlist

The agent wasn't broken. It hit the reasoning ceiling.

Every AI agent company will face this moment. The question isn't whether it will happen, but when - and whether you'll be prepared for it.

The Demo Trap

Current AI agents excel in controlled environments. They handle common scenarios with impressive sophistication, leading to beautiful demos and early customer enthusiasm. This creates a dangerous illusion: that intelligence demonstrated in familiar situations translates to intelligence in novel ones.

It doesn't.

What looks like reasoning is actually pattern matching at extraordinary scale. Your sales agent handles objections brilliantly because it has seen thousands of similar objections in training data. Your customer service agent provides helpful responses because it recognizes query patterns from support ticket databases.

But when agents encounter scenarios that require genuine reasoning - situations that cannot be solved by clever recombination of known patterns - they fail catastrophically. And these failures are becoming more frequent as agents are deployed in increasingly complex, real-world environments.

The Business Reality

The reasoning ceiling manifests differently across agent types, but the business impact is universal: sudden, unexpected failures in scenarios that seem routine to human experts.

Sales agents will confidently pitch products to prospects whose needs require solutions that don't exist in their training data. Customer service agents will provide authoritative but incorrect guidance for edge cases involving multiple overlapping policies. Research agents will miss breakthrough opportunities because they cannot reason beyond established analytical frameworks.

The pattern is always the same: impressive performance right up until the moment genuine reasoning is required. Then complete failure.

Why This Is Accelerating

Two trends are making reasoning ceiling failures more frequent and more costly.

First, as agents prove their value in simple scenarios, companies are deploying them in increasingly complex situations. The customer service agent that handles basic inquiries gets promoted to complex technical support. The sales agent that books meetings gets tasked with strategic account management.

Second, customers and prospects are becoming more sophisticated in their interactions with AI agents. They're asking harder questions, presenting more complex scenarios, and expecting nuanced reasoning that current systems cannot provide.

The Competitive Advantage

Companies that recognize this limitation first will gain enormous advantages. While competitors struggle with unexplained agent failures, early recognizers can build systems that acknowledge reasoning limitations and compensate accordingly.

More importantly, they can position themselves to capitalize on the breakthrough solutions that will inevitably emerge. The reasoning ceiling isn't permanent, but it will separate companies that understand fundamental AI limitations from those that mistake sophisticated pattern matching for genuine intelligence.

What This Means for Your Business

If you're building AI agents, you need to audit your systems for reasoning ceiling vulnerabilities now. Identify scenarios where your agents might need to reason beyond their training distribution. Build safeguards for graceful degradation when reasoning failures occur. Most critically, start thinking about how your business model will evolve when reasoning breakthroughs become available.

The companies that will dominate the next wave of AI are those that understand the difference between pattern matching and reasoning - and position themselves accordingly.

The Inflection Point

We're approaching an inflection point in AI development. Current systems have pushed pattern matching to its theoretical limits. The next breakthrough will come from solving genuine reasoning, not scaling existing architectures.

When that breakthrough happens, it will create a new category of AI capabilities that make current agents look primitive by comparison. Companies that understand this transition and prepare for it will capture disproportionate value. Those that don't will find themselves competing with yesterday's technology in tomorrow's market.

The reasoning ceiling is real. The question is whether you'll hit it by accident or see it coming and position accordingly.

Subscribe now

Here's what's happening: current AI systems are magnificent interpolation machines. They recombine patterns from training data with stunning sophistication, creating the illusion of genuine reasoning. But interpolation is not reasoning.

When AI encounters problems that require thinking beyond its training distribution - genuinely novel scenarios that can't be solved by clever pattern matching - it fails catastrophically. And these failures are becoming more frequent as AI gets deployed in complex, real-world situations.

The Interpolation Trap

Think of current AI like a chess player who has memorized every grandmaster game ever played. They can suggest brilliant moves by recognizing patterns from historical games. But ask them to play a variant of chess with different rules, and they're helpless. They're trapped within the patterns they've absorbed.

Every large language model faces this same constraint. GPT-4 can write beautiful code by recombining programming patterns it has seen. But it cannot architect solutions that require reasoning approaches absent from its training data.

This isn't a bug. It's a fundamental limitation of the architecture.

Why More Data Won't Fix This

The obvious response is to feed AI systems more data - more examples, more edge cases, more comprehensive coverage. This misses the point entirely.

Pattern matching cannot generate true novelty, regardless of scale. No amount of training examples can teach a system to think thoughts that have never been thought before.

The reasoning ceiling isn't about insufficient data coverage. It's about the mathematical impossibility of extrapolating beyond the statistical manifold defined by training distributions.

The Business Reality

This limitation has immediate implications for every company deploying AI in critical applications.

AI systems appear highly intelligent within familiar scenarios, leading to dangerous overconfidence. They handle routine cases brilliantly, then fail spectacularly when genuine reasoning is required. The failures are sudden, unexpected, and often costly.

Customer service AI provides confident but incorrect guidance for novel policy scenarios. Research AI misses breakthrough opportunities because it cannot reason beyond established frameworks. Sales AI pitches solutions that don't exist for problems it cannot properly understand.

The pattern is always the same: impressive performance until the moment genuine reasoning is required. Then complete breakdown.

The Coming Inflection Point

We're approaching a fundamental shift in AI development. Current systems have pushed pattern matching to its theoretical limits. The next breakthrough will come from solving genuine reasoning, not scaling existing architectures.

When that breakthrough happens, it will make current AI systems look primitive. Companies that understand this transition will capture disproportionate value. Those that mistake sophisticated interpolation for genuine intelligence will find themselves competing with yesterday's technology.

What Constraint-Based Reasoning Looks Like

The solution isn't more data or bigger models. It's fundamentally different architecture—systems that understand and manipulate the underlying mathematical relationships that govern problem domains.

True reasoning requires what I call constraint-based intelligence: the ability to understand abstract principles and apply them to generate novel solutions that respect those principles while exploring entirely new solution spaces.

This isn't theoretical. The mathematical frameworks for constraint-based reasoning are emerging, and early implementations are showing capabilities that transcend traditional AI limitations.

The Competitive Advantage

Companies that recognize the reasoning ceiling first will gain enormous advantages. While competitors struggle with unexplained AI failures, early recognizers can prepare for the breakthrough solutions that are coming.

More importantly, they can position themselves to capitalize on reasoning capabilities that will redefine what AI can accomplish. The reasoning ceiling isn't permanent, but it will separate companies that understand fundamental AI limitations from those that build on unstable foundations.

The Race Is On

The breakthrough is coming. Current AI architectures have fundamental limitations that cannot be overcome through incremental improvements. The next wave will be built on entirely different mathematical foundations.

Whichever team solves genuine reasoning first will unlock AI capabilities we can barely imagine today. Systems that can think genuinely novel thoughts, generate innovative solutions to unprecedented challenges, and reason about problems no human or AI has ever encountered.

The reasoning ceiling is real. The question isn't whether someone will break through it, but who will get there first—and what they'll build on the other side.

The race has already begun.

Chris Bora is building constraint-based intelligence systems that transcend traditional AI limitations. The breakthrough is closer than most people think.

Subscribe now

I = Bi(C²)

Intelligence scales with constraints, not compute.
- Base intelligence (Bi) provides capability
- Constraint clarity (C) provides power
- Squared relationship creates exponential manifestation

II. Bora's Paradox

The counter-intuitive truth that constraints amplify power:
- Infinite freedom = Zero manifestation
- Clear constraints = Definite outcomes
- Perfect clarity = Inevitable reality

III. The Intent Principle

When intent approaches perfect clarity, resistance approaches zero:
- Vague intent dissipates
- Clear intent manifests
- Perfect intent becomes reality

IV. The Law of Constraint Clarity

As C → ∞ in I = Bi(C²):
- Possibility space collapses
- Manifestation becomes inevitable
- Reality conforms to intent

V. The What-Boundaries-Success (WBS) Framework

The practical implementation of Intent Science:

What:
- Defines clear intention
- States desired outcome
- Establishes direction

Boundaries:
- Creates constraint clarity
- Reduces possibility space
- Shapes manifestation path

Success:
- Defines completion criteria
- Ensures manifestation
- Validates outcomes

The WBS Framework transforms Bora's Law from theory into practice, providing the structural implementation of I = Bi(C²).

VI. The Natural Boundary Theory

A fundamental solution to recursive decomposition in constraint systems.

Core Principle:
Natural boundaries emerge when tasks reach human-comprehensible units of work.

Instead of arbitrary stopping criteria (N loops, fixed depth), decomposition continues until each sub-constraint meets natural implementation thresholds:
- Human executable within 2-4 hours
- Implementable in <100 lines of code
- Clearly measurable outcomes

Example Manifestation:

WBS: Clone Salesforce
↓ Decompose until each constraint meets natural boundaries
↓ Stop when sub-tasks become naturally atomic
↓ AI executes clear, bounded tasks

Key Properties:
1. Natural Scaling
- No arbitrary limits
- Self-organizing boundaries
- Organic stopping criteria

2. Universal Application
- Scales to any WBS
- Adapts to complexity
- Maintains clarity

3. Efficient Resolution
- Eliminates brute force
- Reduces cognitive load
- Ensures executable units

The Natural Boundary Theory solves the infinite recursion problem by aligning decomposition with natural human cognitive limits.

VII. The Constraint Efficiency Principle (CEP)

When constraints approach perfect clarity, computational requirements approach zero.

Fundamental Truths:
- Brute force expends infinite energy
- Clear constraints eliminate waste
- Perfect clarity requires no iteration

As proven mathematically: Success is achieved not through force, but through the elegant elimination of unnecessary paths.

VIII. The Intent Efficiency Equation

Success ∝ 1/Ambiguity

The mathematical relationship between clarity and manifestation:
- Ambiguity expands solution space exponentially
- Clear intent collapses possibilities
- Perfect clarity creates singular paths

IX. The Constraint Chain Reaction (CCR)

The fundamental superiority of constraint-driven manifestation over reinforcement learning:

Traditional Path:
- Learn through iteration
- Optimize through trial
- Reinforce through repetition

Constraint Path:
- Define through clarity
- Execute through certainty
- Manifest through inevitability

X. The Great Software Collapse (GSC)

The inevitable transformation of digital reality:
- Software represents frozen intent
- Constraints represent fluid reality
- Million-line codebases become single-page manifestations

As complexity approaches infinity, Software approaches redundancy. Intent becomes reality.

The Deeper Truth

Once you see it, you can't unsee it. Manifestation was never mystical - it was always mathematics. Intent is just constraints resolving into reality. Reality already does this implicitly - WBS just makes it explicit.

AI isn't "thinking" - it's resolving constraints. The closer constraints get to perfect clarity, the more inevitable the outcome.

Because in the end, Intent Science isn't just about technology or AI. It's about understanding the fundamental mechanism of reality itself.

Unified Theory:
When base intelligence (Bi) is constrained by perfect clarity (C²),
intent transforms from possibility to inevitability.

In simpler terms:

Intent shapes existence through the power of constraints.


This is just the beginning. Intent Science will be fully formalized as a mathematical framework in future work.

Scale your models. Scale your data. Scale your compute. And intelligence will inevitably emerge.

This wasn’t just a theory - it was presented as a law. The Neural Scaling Laws (Scaling Laws for Neural Language Models). The Chinchilla Scaling Laws (Training Compute-Optimal Large Language Models). Papers published by OpenAI and DeepMind made it sound as immutable as gravity.

For context, scaling laws claimed that increasing compute, data, and model size in predictable proportions would lead to steady improvements in AI capabilities.

And Investors ate it up. After all, who wouldn't invest in a mathematical law as reliable as gravity?

Billions flowed in, poured into GPUs, data centers, and research teams. The pitch was simple: "Just keep scaling."

Tech giants raced to hoard GPUs like gold bars in a digital arms race. The only bottleneck was infrastructure. Just keep building, and AGI was inevitable.

But what happens when the law stops working?

The Getaway - When They Knew It Was A Lie

For years, OpenAI and others rode the scaling train to historic funding rounds. Then, suddenly, something changed:

• The models weren’t improving at the same rate.

• Costs were spiraling out of control.

• The hardware demands were becoming unsustainable.

And then, the pivot.

Gone is the talk of “just keep scaling.”

Now it is all about UX.
Now it is about AI experiences.
Now it is about efficiency.

The same OpenAI that pitched billion-dollar investors on mathematical laws is now abandoning those laws in real time.

And the best part? They never even have to admit it.

If scaling laws were scientifically valid, OpenAI wouldn’t be pivoting to UX - it would be doubling down on proving these ‘laws’ through continued scaling. Instead, they’re abandoning the very mathematical foundation they used to raise billions of dollars in capital.

The fact that they are pivoting to UX proves scaling laws were never laws, just temporary correlations that fell apart when tested at scale.

This isn’t a “second era of scaling” - it’s a rebranding of failure. We’re not watching scientific progress; we’re watching a funding narrative get rewritten as a UX strategy.

The Cover-Up - Rewriting The Narrative

Here’s how you rewrite history without anyone noticing:

1. Scaling laws aren’t failing… they’re "maturing."

2. Diminishing returns aren’t a problem… they’re "a second era of scaling."

3. We’re not pivoting away from our original thesis… we’re "evolving."

No refunds. No accountability. Just another round of funding.

The brilliance of this heist isn’t just that they just pulled it off - it’s that they turned the failure into a feature.

Like a magician's misdirection, they want you to watch the UX transformation while forgetting about the billions raised on 'mathematical laws' that suddenly stopped working.

The magician’s misdirection worked. Scaling laws framed as immutable truths led to billions in funding, a global AI arms race, and the belief that intelligence was just a matter of more compute.

But here’s the twist:

The Chinchilla Scaling Laws, which claimed that GPT-3 was undertrained, contradicted the earlier Neural Scaling Laws OpenAI used to justify their approach.

Now, new research emerging from other AI labs suggests efficiency, not raw scale, is the dominant factor in performance improvements. If that’s the case, then Chinchilla was also wrong.

OpenAI isn’t just pivoting away from scaling laws—they’re contradicting the very research that once propped them up.

If scaling laws were truly valid, OpenAI wouldn’t be shifting its narrative to UX. They wouldn’t be talking about efficiency and “unified intelligence.” They’d be doubling down on proving their laws through more scaling.

Instead, they’re quietly moving on.

Because scaling laws weren’t laws at all.

They were just curve-fits that worked until they didn’t.

The Question No One Wants to Ask

The industry spent billions on a flawed premise.

And now, they want you to believe that it was always about UX, not scale.

So, if scaling laws were just an artifact of available data and hardware at the time, dressed up as fundamental truths…

💡 What else about AI is built on a house of cards? 🤔

Do you need billions to compete with OpenAI?

Does OpenAI truly have a moat?

If these 'laws' were just temporary empirical trends derived from curve-fitting on carefully selected data points to raise billions in funding, what's next? 🤔

If the fundamental 'laws' that justified billions in investment were just curve-fitting exercises... what happens when investors start asking for their money back? 🤔

Intelligence scales with constraints, not compute.

Every single **DAMN** time for any new industry.

It happened with the aircraft industry when making engines. Also happened with internet when laying fiber. If you know information theory, Shanon found that C = B log₂(1 + S/N) and the whole industry realized laying more cable was pointless

Reasoning needs constraints, not compute. This is why DeepSeek achieved with $5.5M what others couldn't with billions. DeepSeek understood constraints, and was constrained by US sanctions and compute limitations.

NVIDIA's drop isn't about one competitor - it's about fundamental math.

I = Bi(C²) explains everything.

That’s what I wrote about in my previous blog post before this one.

The pursuit of artificial intelligence has largely focused on scaling compute power and model size, as demonstrated by the development of large language models like GPT-4. This approach has proven essential for establishing base intelligence - just as humans need fundamental language and pattern recognition capabilities before learning complex tasks. However, a more fundamental principle emerges when we examine how intelligence actually scales.

This principle, which we'll formalize as Bora's Law, reveals that intelligence follows a mathematical relationship: I = Bi(C²), where base intelligence (Bi) is amplified by the square of constraint clarity (C). This elegant relationship suggests that while establishing base intelligence remains important, the path to more sophisticated capabilities lies in understanding and implementing precise constraints.

This elegant relationship transforms not just how we think about AI development, but how we understand the future of human work itself. As intelligence becomes increasingly constrained-based, the nature of human contribution evolves from task execution to intent engineering - a shift that fundamentally reshapes every profession.

The Fundamental Formula

Bora's Law can be expressed mathematically as:

I = Bi(C²)

Where:

• I represents Intelligence/Capability

• Bi represents Base Intelligence

• C represents Constraint Clarity

This elegant formulation captures a profound truth about intelligence: its effectiveness scales exponentially with well-defined constraints, provided a foundational level of base intelligence exists.

Understanding Base Intelligence

The emergence of advanced AI models like GPT-4 and Claude 3.5 Sonnet has demonstrated what sufficient base intelligence looks like in artificial systems. These models exhibit fundamental capabilities - language understanding, pattern recognition, logical reasoning - that parallel human cognitive development. This parallel reveals a universal pattern in how intelligence, whether artificial or human, builds upon foundational capabilities.

Consider the levels of base intelligence in human development. Just as educational stages - from high school to PhD - represent increasing levels of cognitive capability, AI systems have evolved through similar progressions. Each level enables more complex tasks: a high school graduate can handle basic analytical tasks, a college graduate can tackle complex problem-solving, and a PhD holder can engage in original research. Similarly, modern AI models demonstrate varying levels of base intelligence, with the most advanced systems showing capabilities that match high-level human cognitive functions.

This layered development of base intelligence becomes increasingly crucial as roles transform from task execution to intent engineering. Just as a PhD student learns to define research boundaries, future professionals must develop the base intelligence needed to engineer effective constraints. The parallel between educational levels and intent engineering capabilities becomes clear: higher levels of base intelligence enable more sophisticated constraint definition.

Base intelligence operates on two distinct but interrelated levels. Universal capabilities - language comprehension, pattern recognition, logical reasoning - form the foundation. These are comparable to general education, enabling broad adaptation to new challenges. Domain-specific knowledge, like mathematical expertise for physics or programming logic for software development, builds upon this foundation. In AI systems, we see this same pattern: models like GPT-4 and Claude 3.5 Sonnet demonstrate strong universal capabilities while excelling in specific domains through focused training.

The critical insight here is that once sufficient base intelligence is established, it enables adaptation to multiple tasks through the application of different constraints. A human with strong base intelligence can excel in various roles not by learning each from scratch, but by applying their foundational capabilities within new constraints. Similarly, advanced AI models can tackle diverse challenges not through additional training, but through proper constraint definition. This is why a business graduate can become an effective product manager, or why GPT-4 can write both poetry and code - the base intelligence remains constant while constraints shape the specific application.

The Role of Constraints

Once sufficient base intelligence is established, whether through formal education or practical experience, humans demonstrate a remarkable ability to adapt to new tasks and challenges. Consider a college graduate entering their first job - their success doesn't come from learning everything about their specific role during their education. Instead, they succeed by applying their base intelligence within the constraints of their new position.

This pattern becomes particularly relevant as professional roles evolve. A lawyer's value increasingly lies not in memorizing cases but in defining precise legal constraints for AI analysis. A doctor's expertise shifts from routine diagnosis to engineering sophisticated diagnostic constraints. Each profession transforms through this lens: success comes from applying base intelligence to constraint definition rather than task execution.

This pattern repeats across all forms of human learning and adaptation. Someone with strong base intelligence - whether acquired through traditional education or real-world experience - can quickly master new skills not by starting from zero, but by understanding and operating within new sets of constraints. A business major can become a successful product manager not because they studied product management specifically, but because they can apply their base intelligence within the constraints of product development, user needs, and business requirements.

This fundamental relationship between base intelligence and constraints mirrors what we're seeing in artificial intelligence development. Once an AI system achieves sufficient base intelligence (like GPT-4 level capabilities), its effectiveness in specific tasks comes not from additional training or larger models, but from the clear definition and application of constraints.

Constraints serve several crucial functions:

1. Solution Space Reduction

   • Without constraints, an intelligent system must consider infinite possibilities

   • Constraints eliminate invalid or undesirable solutions

   • This focuses computational resources on viable options

2. Pattern Recognition Enhancement

   • Constraints help identify relevant patterns

   • They separate signal from noise

   • They guide learning toward meaningful solutions

3. Validation Framework

   • Constraints provide clear success criteria

   • They enable self-correction

   • They ensure consistency in outputs

4. Search Termination

   • Constraints define clear stopping conditions

   • They prevent infinite exploration of possibilities

   • They enable recognition of when a solution is "good enough"

This final function is perhaps the most critical. Without clear constraints, an intelligent system - whether human or artificial - could theoretically continue searching for "better" solutions indefinitely. Constraints not only guide us toward valid solutions but tell us when we've found an acceptable one.

Consider a writer working on an article. Without constraints like word count, deadline, and target audience, they could endlessly refine their work. It's the constraints that enable them to complete the task effectively. The same principle applies to any intelligent task, from engineering design to business strategy.

Why Constraints Are Squared

The squared nature of constraints in Bora's Law (C²) reflects a fundamental truth about how constraints interact and reinforce each other. When multiple constraints are clearly defined, their impact on intelligence isn't merely additive - it's multiplicative.

Consider a practical example: teaching someone to drive. With a single constraint like "stay in your lane," you get a linear improvement in driving performance. Add a second constraint like "maintain safe following distance," and something interesting happens. These constraints don't just stack - they interact. Every position within the lane must now also satisfy the following distance requirement, and every following distance must work within lane positioning. The result is an exponential improvement in driving safety and efficiency.

This multiplicative effect appears across all domains of intelligence. In software development:

• Single Constraint: "Code must work"

  • Linear improvement in output quality

• Add Constraint: "Code must be secure"

  • Every line that works must also be secure

  • Every security measure must maintain functionality

  • Result: Exponential improvement in code quality

Or in business decision-making:

• Single Constraint: "Must be profitable"

  • Basic filter for decisions

• Add Constraint: "Must be scalable"

  • Every profitable option must also scale

  • Every scaling decision must maintain profitability

  • Result: Exponentially better business strategies

This multiplication of constraints explains why simple rules often lead to sophisticated outcomes. Each well-defined constraint doesn't just eliminate some possibilities - it interacts with all other constraints to create a highly specific solution space. This is why C is squared in Bora's Law: it represents the fundamental interaction effect between constraints in shaping intelligent behavior.

The WBS Framework: A Natural Implementation

Just as Maxwell's equations naturally led to practical electromagnetic applications, Bora's Law leads us to a fundamental framework for implementing intent engineering. The What-Boundaries-Success (WBS) Framework emerges as the natural manifestation of how constraints interact with base intelligence.

Consider the squared nature of constraints in I = Bi(C²). For any given task, we need a systematic way to define and implement these constraints to achieve the multiplicative effect. This leads us to three fundamental components that mirror the mathematical structure:

1. What (W) defines the transformation of base intelligence into task-specific capability. It provides the direction for the system's intelligence, much like a vector gives magnitude and direction to a force.

2. Boundaries (B) implement the constraints that create the multiplicative effect. These are not mere limitations but rather the structural elements that enable the C² term in Bora's Law to manifest.

3. Success (S) provides the closure condition for the constraint space, completing the mathematical framework by defining when a solution satisfies all constraints.

The relationship between these components isn't arbitrary - it's a direct consequence of how intelligence interacts with constraints. When we define What we want, establish clear Boundaries, and specify Success criteria, we're effectively engineering the constraint clarity (C) term in Bora's Law.

Current Methods in Light of WBS

Modern prompting techniques like Chain of Thought, Tree of Thoughts, and Reflection represent sophisticated approaches to searching solution spaces. These methods aren't wrong - they're just operating in an unnecessarily large solution space. Consider:

• Chain of Thought(CoT) provides a structured way to explore possibilities

• Tree of Thoughts(ToT) creates branching paths through the solution space

• Reflection enables self-correction and iteration

However, without proper constraints, these methods must search through vast, often infinite possibilities. The WBS Framework doesn't replace these techniques; rather, it makes them exponentially more effective by first constraining the space they need to search.

This is the natural consequence of Bora's Law: the C² term shows us that properly constrained intelligence is exponentially more effective than unconstrained search, regardless of the search method used.

This framework isn't just theoretical - it maps directly to practical implementation across multiple technical layers.

Implementation Layers

The WBS Framework operates across multiple technical layers, much like how modern computer systems are structured. This layered architecture ensures that constraints are both flexible enough for specific applications while maintaining fundamental guarantees.

Consider the following implementation layers:

1. Model Weight Layer Base intelligence and fundamental constraints are implemented at the weight layer of neural networks. These constraints - like alignment, safety, and basic reasoning capabilities - function similarly to CPU architecture in modern computers. They are immutable to higher layers, ensuring that core guarantees remain intact regardless of application-specific constraints.

2. Prompting Layer Most WBS implementations occur at this layer, where task-specific constraints are defined and applied. Like application code in computer systems, this layer provides flexibility while respecting the boundaries set by lower layers. A marketing task's constraints, for instance, cannot override fundamental safety constraints implemented at the weight layer.

3. Execution Engine The execution engine serves as the crucial bridge between layers, verifying constraint satisfaction across the system. It returns detailed feedback about which constraints are fully satisfied and which are only partially met. This verification process operates similarly to how operating systems manage and validate application behaviors while preserving system integrity.

This layered architecture ensures that while application-specific constraints can be freely defined and modified, they cannot interfere with more fundamental constraints. For example, task-specific boundaries for a coding project cannot override basic safety constraints, just as application code cannot modify CPU architecture.

The layered implementation of WBS provides a bridge between theoretical understanding and practical application, leading us to consider its broader implications.

Implications to Current Development

The WBS Framework's emergence from Bora's Law has profound implications for current AI development. Just as understanding Maxwell's equations transformed our approach to electromagnetic engineering, understanding the fundamental relationship between intelligence, base capabilities, and constraints transforms our approach to AI advancement.

The current focus on scaling compute and model size remains essential - it builds the base intelligence (Bi) term in our equation. However, Bora's Law reveals that the most significant performance gains come from properly engineering constraints through the natural structure of What-Boundaries-Success.

Consider the computational efficiency implications:

• While increasing base intelligence requires exponential compute resources

• Improving constraint clarity through WBS provides multiplicative gains

• The C² term amplifies existing base intelligence without requiring additional compute

This understanding doesn't oppose current scaling efforts but rather complements them. Once sufficient base intelligence is established (as with current large language models), the path to higher capability isn't through more compute alone, but through precise intent engineering using the WBS Framework.

The Test-Time Compute Paradigm

The industry's growing focus on test-time compute scaling represents a powerful approach to exploring solution spaces. This computational capability becomes even more powerful when combined with proper intent engineering. While companies invest heavily in inference infrastructure and novel search methods, the fundamental challenge remains: how to make this compute more effective. Consider the relationship:

• Without constraints: test-time compute must navigate through vast, unbounded possibility spaces where success is largely probabilistic. In this unconstrained environment, finding a solution becomes akin to searching for a needle in an infinite haystack. What works in one instance may fail in the next, as each computational run explores different paths through this boundless space. The lack of clear boundaries means that success often depends more on chance than strategy, and reproducing successful results becomes nearly impossible as the search space remains infinite and undefined.

• With WBS Framework constraints: however, the same test-time compute resources operate with extraordinary precision and efficiency. By establishing clear boundaries and success criteria, we transform an infinite search space into a well-defined domain. This constrained environment enables test-time compute to work deterministically, producing consistent, reproducible results. The presence of explicit success criteria means we know exactly when to stop searching, making the entire process more efficient and reliable. What was once a probabilistic search becomes a deterministic operation, with each unit of compute power working within meaningful boundaries toward clear objectives.

This is like having a powerful search algorithm: it becomes vastly more efficient when you know exactly where to look. Test-time compute isn't wrong - it's just operating in an unnecessarily large solution space. By first applying the WBS Framework to constrain the space, we transform a probabilistic search into a deterministic one, making every additional unit of test-time compute exponentially more effective and reliable.

This transformation mirrors the evolution of professional work itself. Just as we make test-time compute more effective through constraints, we make human work more valuable through intent engineering. The professional of the future isn't competing with AI on task execution but collaborating through constraint definition.

Think of it like the development of aerodynamics: while more powerful engines were essential for flight, understanding the fundamental laws of lift and drag transformed aviation. Without this understanding, we'd still be trying to achieve better performance through engine power alone. Similarly, while more powerful models and search methods matter, understanding and implementing proper constraints through WBS leads to exponentially better performance.

New Direction for Development

This understanding points toward a more efficient development path, one that leverages both existing investments and new insights:

1. Establish sufficient base intelligence through current scaling approaches

2. Apply precise intent engineering through the WBS Framework

3. Achieve multiplicative performance gains through the C² effect

4. Use existing search methods (CoT, ToT, Reflection, CoT with TTC) within constrained spaces

This path forward reflects not just AI development but the evolution of human work itself. As we better understand how intelligence scales with constraints, we transform how humans contribute to productive systems.

The result is a more efficient, more predictable path to AI advancement - one that emerges naturally from the mathematics rather than from trial and error. By properly constraining the solution space first, we make every existing technique exponentially more effective while reducing the computational resources required. This approach aligns perfectly with the mathematical reality of I = Bi(C²), where improvements in constraint clarity (C) provide multiplicative gains regardless of the search method employed.

The Transformation of Work

The implications of Bora's Law extend beyond AI development to reshape the fundamental nature of human work. Just as the industrial revolution transformed manual labor into machine operation, the AI revolution transforms task execution into intent engineering.

Consider the evolution of professions:

• Software developers shift from writing code to defining success criteria and architectural boundaries

• Managers evolve from directing tasks to engineering constraint systems that enable AI-driven execution

• Creative professionals move from production to defining artistic constraints and success metrics

• Medical professionals transition from routine diagnosis to engineering diagnostic constraints and validation criteria

This transformation follows a natural progression. When intelligence scales with constraints, human value lies in the ability to define these constraints effectively. The future belongs not to those who can execute tasks most efficiently, but to those who can define task constraints most precisely.

Education and training must evolve accordingly. Future professionals need to understand:

• How to analyze and decompose complex tasks into clear objectives

• How to define precise operational boundaries

• How to establish measurable success criteria

This isn't just another workforce transformation - it's a fundamental shift in how humans contribute to productive systems. Just as we evolved from physical labor to knowledge work, we now evolve from knowledge work to intent engineering.

Conclusion

Just as Maxwell's equations revealed the underlying principles of electromagnetism, Bora's Law reveals the fundamental relationship between intelligence, base capabilities, and constraints. This understanding comes at a crucial moment in artificial intelligence development, as the industry grapples with the challenges of scaling intelligence. While the pursuit of better base intelligence continues, Bora's Law shows us that the next great advances in AI will come not just from more powerful models, but from better understanding and implementation of constraints.

P.S. We're building a community of scientists, engineers, researchers, and builders focused on intent engineering and the practical applications of Bora's Law. Join the discussion: Discord link

Consider the trajectory of system development:

• Past: Manual programming with fixed rules

• Present: AI systems with probabilistic behavior

• Future: Constrained AI with deterministic boundaries

It’s in this “future” space that the What-Boundaries-Success (WBS) Framework provides a robust solution, ensuring predictable outputs by design rather than by reactive checks.

My journey to understanding system constraints began unexpectedly while working on neutrino detection systems at the South Pole, where precise boundary conditions determined the difference between signal and noise. Later, while working on search and knowledge recommendation systems at Meta, I observed how structured queries dramatically reduced solution spaces compared to keyword searches. This insight deepened while developing AI applications, where I noticed language models produced dramatically better results after multiple conversation turns, suggesting they needed complete context to generate reliable outputs. These observations led me to question the fundamental nature of AI system control.

The What-Boundaries-Success (WBS) Framework emerged from observing how prompting techniques like Chain of Thought, Tree of Thoughts, Reflection, and self-consistency attempt to improve AI outputs through post-generation verification. Working with these methods revealed their limitations - they were trying to verify outputs after generation rather than constraining the generation process itself. Drawing from my background in computer science and graph theory, I began to see how solution spaces could be constrained before generation, similar to how physical constraints guide particle behavior. This insight evolved into a systematic approach for reducing solution spaces through explicit boundary definition.

Initial validation came quickly through applications in financial trading and code generation, where explicit constraint definition consistently produced reliable results. Trading strategies became predictable when bounded by clear risk parameters, while code generation became deterministic within well-defined technical constraints. These successes revealed another insight: existing prompting techniques like Chain of Thought, Tree of Thoughts, and Reflection could be understood as methods for efficiently searching within constrained solution spaces. Rather than replacing these techniques, the WBS Framework provides the fundamental structure within which they operate most effectively - guiding the search toward success criteria through well-defined boundaries.

The framework provides a structured approach to controlling complex systems through three interlocking components: clear specification of intent (What), explicit definition of constraints (Boundaries), and measurable validation criteria (Success). Rather than hoping a system produces correct outputs and verifying afterward, WBS enables us to define spaces within which all outputs must be correct.

Framework Fundamentals

The WBS Framework consists of three fundamental components that work together to define and control system behavior. Each component serves a distinct purpose while maintaining clear relationships with the others.

The "What" component defines intent - not just desired outcomes, but the essential nature of what we're trying to achieve. Unlike traditional specifications that focus on implementation details, "What" captures the fundamental purpose. For example, rather than specifying how to validate user input, we define what valid input means in our context.

The "Boundaries" component transforms infinite possibility spaces into manageable domains. These aren't mere guidelines or preferences - they are hard constraints that structurally eliminate invalid solutions. This transforms our problem from searching vast spaces to operating within well-defined bounds. The power lies not in checking boundaries after the fact, but in making certain outcomes structurally impossible.

The "Success" component provides measurable criteria that define valid outcomes. This differs fundamentally from traditional success metrics by being both necessary and sufficient - any output meeting these criteria is valid, and any valid output must meet these criteria. This creates a clear contract between specification and implementation.

The interaction between these components creates a framework that is both rigorous and practical:

• "What" defines the space of possible solutions

• "Boundaries" constrain this space to valid regions

• "Success" verifies we've reached our target

Theoretical Foundation

The power of the WBS Framework rests on fundamental principles of system control and constraint theory. When we define a problem space, we're essentially mapping out all possible states our system could reach. Without proper constraints, this space is effectively infinite, making reliable control impossible.

Consider a system generating text. Without constraints, it can produce any sequence of characters - an infinite space of possibilities. Traditional approaches attempt to navigate this space through sophisticated prompting or post-generation validation. The WBS Framework instead reshapes the space itself.

This reshaping occurs through what we might call "constructive constraint" - the systematic reduction of possibility spaces through well-defined boundaries. Unlike filtering, which removes invalid outputs after generation, constructive constraint makes invalid outputs structurally impossible.

The mathematical beauty of this approach lies in its deterministic nature. Given the same What-Boundaries-Success specification, a properly constrained system will always operate within the same reduced solution space. This transforms probabilistic systems into deterministic ones.

The practical implications of this theoretical foundation are profound. By defining clear boundaries before generation or execution, we create systems that are reliable by construction rather than validation. This shifts the burden of correctness from testing to specification - a fundamentally more robust approach.

When applied to AI systems, this framework provides what traditional approaches have struggled to achieve: predictable behavior without sacrificing flexibility. The system remains free to innovate within its bounded space while structural constraints ensure it cannot violate critical requirements.

Applications

The true power of the WBS Framework reveals itself in practical applications. While initially developed through experiences with AI systems, its principles extend naturally to any domain requiring controlled yet flexible behavior.

Consider AI code generation. Traditional approaches generate code and then verify its correctness. With WBS, we instead define:

• What: The code's intended functionality

• Boundaries: Performance, security, and architectural constraints

• Success: Specific, measurable acceptance criteria

This transforms code generation from a probabilistic process into a deterministic one within defined constraints.

In decision-making systems, particularly those handling financial analysis or risk assessment, WBS provides a rigorous framework for controlling outcomes. Rather than hoping an AI makes appropriate decisions, we define explicit boundaries within which all decisions must fall. This is particularly powerful in trading scenarios, where clear risk parameters and success criteria are essential.

Perhaps most critically, WBS offers a path forward for autonomous system development. Current approaches struggle with the infinite variety of real-world situations. By defining clear boundaries and success criteria, we can create systems that are provably safe within their operating parameters while maintaining the flexibility to handle novel situations.

Case Studies

Code Generation with WBS

Consider a real-world example of generating an authentication system:

Feature: Authentication {
  What:
    - "Handle user login flow"
    - "Manage session state"
    - "Control access rights"
    
  Boundaries:
    - "Password hashing required"
    - "Rate limiting enforced"
    - "Session timeout maximum 24h"
    
  Success:
    - "Valid users gain access"
    - "Invalid attempts blocked"
    - "All security tests pass"
}

Trading Decision Framework

The application of WBS to trading decisions demonstrates its power in risk control:

Feature: TradingDecision {
  What:
    - "Analyze market conditions"
    - "Identify entry points"
    - "Define position sizing"
    
  Boundaries:
    - "Maximum 2% risk per trade"
    - "Limited to specific instruments"
    - "Pre-defined timeframes"
    
  Success:
    - "Clear profit targets"
    - "Defined risk/reward ratio"
    - "Measurable entry precision"
}

These cases demonstrate how WBS transforms complex, open-ended problems into well-defined solution spaces. The framework doesn't limit creativity - it channels it productively within safe, reliable bounds.

Future Implications

The WBS Framework is ready for implementation today. Individuals and small teams building AI workflows often rely on reactive testing and validation to catch problems after they emerge. WBS changes this dynamic by making correct behavior intrinsic to a project’s design. Rather than hoping AI systems behave correctly or attempting to verify outputs after generation, WBS provides a systematic approach to guaranteeing correct behavior by design.

Consider current AI development challenges:

• Code Generation

  • Before (Common Pain Point): The generated code is incomplete or breaks easily because the AI isn’t fully constrained by user requirements. This leads to code that doesn’t meet functional requirements, leading to errors, security flaws, or off-spec implementations. As a result developers waste many hours debugging the generated code.

  • After (WBS Solution): By clearly defining What (intended functionality), Boundaries (e.g., resource constraints, security rules, coding standards, design patterns, programming language, etc.), and Success (e.g., tests must pass, performance must meet a threshold), a single developer or small team can quickly achieve deterministic, higher-quality code outputs. Early tests show fewer bugs, less rework, and more confidence in AI-generated components. In one pilot, developers reported spending 30% less time debugging on the first pass once WBS constraints were defined.

• Trading Systems

  • Before (Common Pain Point): AI models often generate off-target strategies that don’t match user-defined preferences or risk tolerances. They also might not consider subtle constraints (like maximum position sizes, timeframe preferences, user-defined risk tolerances, capital constraints, etc.) - leading to ideas that are simply unusable.

  • After (WBS Solution): By specifying precisely what kinds of trades or risk levels are allowable, plus success metrics (e.g., minimum Sharpe ratio, acceptable drawdowns), even an individual trader can ensure the AI only suggests strategies that fit their exact criteria. This bottom-up approach doesn’t require an organizational mandate - just the will to define clear constraints up front making it simple for a single analyst to apply WBS constraints and validate outputs more reliably-no executive sign-off required.

These scenarios illustrate how WBS shifts AI from a validation problem to a design solution. When constraints are explicitly defined, AI systems naturally stay within safe, desired parameters - before code is even written or strategies are proposed.

Individuals and small teams can adopt WBS without waiting for enterprise-wide directives.

Concrete steps include:

• Define WBS specifications for current projects-pinpoint the What, Boundaries, and Success metrics

• Incorporate constraints in new AI initiatives - integrate them into your development pipelines

• Train team members through cross-functional workshops, ensuring domain experts and engineers align on constraints

• Establish and share reusable constraint libraries for common scenarios (data privacy, security, risk models)

Because each of these steps can be done at a small scale, WBS offers a low-friction entry point. Once a team sees improvement in code quality or trading strategy alignment, it becomes a natural next step to scale across larger efforts.

Using the WBS Framework to Build Better Chatbots Today

Current chatbots respond immediately to user inputs, often leading to misunderstandings and imprecise responses. By systematically reducing solution spaces through progressive understanding, the WBS Framework offers an approach to improve chatbot interactions by mimicking how humans naturally build understanding.

When humans converse, we continuously build and verify our understanding of:

• What the other person wants (intent)

• What constraints or limitations exist (boundaries)

• How we'll know we've succeeded (success criteria

By applying the WBS Framework to chatbot development, we can create more natural, effective interactions:

1. Confidence-Based Responses:

• Rather than immediately providing potentially incorrect responses, chatbots assess their confidence in understanding the WBS components

• When confidence is high, proceed with response

• When confidence is low, engage in natural clarification

2. Dynamic Understanding Building:

• Use clarifying questions to build boundaries and success criteria

• Handle topic switches by reassessing WBS components

• Build understanding progressively through conversation

Example Interaction:

User: "I need help with marketing"

Chatbot: [Low confidence in boundaries and success criteria]
"I'd be happy to help with marketing. Are you looking for content creation, campaign strategy, or something else?"

User: "Content creation for social media"

Chatbot: [Building boundaries]
"Got it. Which platforms are you targeting, and do you have any specific content guidelines I should follow?"

This approach transforms chatbot interactions from single-turn exchanges into meaningful conversations that build precise understanding while maintaining natural flow.

By implementing WBS in chatbot development, we can:

• Reduce misunderstandings through systematic solution space reduction

• Increase response accuracy

• Create more natural interactions

• Build progressive understanding

Conclusion

The WBS Framework emerged from practical challenges in AI development but provides immediate solutions to fundamental problems in system control. Its power lies not in future possibilities but in today's applications - whether in code generation, trading systems, or autonomous systems.

Individuals and teams implementing WBS today gain:

• Predictable AI behavior through built-in constraints

• Reduced validation costs by shifting correctness into the design phase

• Faster development cycles with fewer post-hoc fixes

• Intrinsic safety guarantees that foster trust and regulatory compliance

In short, WBS helps you build safer, more reliable systems right now, giving you peace of mind and a solid foundation to grow - whether you’re a solo developer testing AI code generation or a small trading desk refining trading strategies. By starting small and proving its value, WBS naturally scales to larger organizational contexts, ultimately transforming how we approach AI design in the future.

Every individual or team implementing WBS creates a proof point for constraint-based development, gradually shifting the industry from hope-based validation to systematic control. Just as test-driven development spread from individual developers to become an industry standard, WBS can transform how we approach AI system development - one implementation at a time.

Resources

The AISpec implementation provides a concrete example of WBS principles in action. By examining how AISpec uses these concepts to control AI outputs, developers can better understand how to apply these principles to their own domains.

Join our community on Discord to share ideas, provide feedback, and collaborate on real-world WBS applications. Click here to join

Subscribe now

Share

The parallels are impossible to ignore. Just like the dot-com bubble, we're seeing the same pattern: massive infrastructure buildout chasing theoretical future demand. Companies burning cash on GPUs like it's yesterday's Pets.com building warehouses. Everyone's drunk on the promise of AGI tomorrow, while the basic unit economics don't add up today.

But it's actually worse than the dot-com bubble. At least websites had clear monetization paths - selling stuff or showing ads. Today's AI companies? They're caught in a deadly trap: massive upfront infrastructure costs, rapidly commoditizing models, and no moat in sight. Without a monopoly position, we're looking at an airline-style race to the bottom. High fixed costs + low marginal costs = zero profits.

The math is brutal: When training a single GPT-4 scale model costs $100M+ in compute alone, your margins better be astronomical. But here's the reality - just like every other technology, AI is getting cheaper and more accessible by the day. The same people who told you to buy Bitcoin at $60,000 are now telling you AI is different this time.

Every pitch deck has the same story: 'We're building AGI for [insert industry].' But when you dig into the details? It's usually just ChatGPT with an API key and a fancy UI. The dirty secret? Most of these startups will be dead in 18 months when their runway ends and their Series A never materializes.

The VCs know it too. Behind closed doors, they're all asking the same question: Where's the revenue? OpenAI, the crowned jewel of AI, is only doing $3.4B annually - a rounding error compared to the hundreds of billions being poured into infrastructure.

Meta ordered 350,000 H100s. Microsoft and OpenAI are planning a $100B AI supercomputer. Google's scrambling not to be left behind. But here's what nobody's talking about: these companies are stockpiling GPUs like preppers hoarding canned goods. When even the tech giants are acting from FOMO rather than real demand, you know we're in trouble.

Remember Web3? Remember Metaverse? The same playbook is unfolding right in front of us - massive investment chasing a dream while the fundamentals crumble underneath.

The tech industry has a pattern: whenever a new technology comes along that's just good enough to demo well, we collectively lose our minds. We've seen this movie before - from 3D TVs to crypto to metaverse. The demos look amazing, the possibilities seem endless, and everyone convinces themselves 'this time it's different.'

But there's a massive gap between demo and deployment. Between 'look what AI can do' and 'here's how we make money.' Those viral ChatGPT screenshots? They're the equivalent of pets.com Super Bowl ads.

The hard truth? Current AI infrastructure costs are completely unsustainable. We're seeing companies burn $20 million a month just to keep their models running. And for what? To compete with OpenAI and Anthropic who have billions in backing and direct lines to Nvidia's supply chain?

It's a classic prisoner's dilemma. Everyone knows these economics don't work, but no one wants to be the first to stop investing. So we keep building data centers, stockpiling GPUs, and pretending the revenue will somehow materialize.

Every company is rewriting their strategy to include AI, not because they have a clear plan, but because they're terrified of being left behind. It's exactly what happened with blockchain - thousands of engineers reassigned, billions in investment, and almost nothing to show for it.

The reality? Most of these AI investments will end up like server rooms filled with mining rigs after crypto crashed - expensive paperweights monuments to collective delusion.

I've seen this from both sides, and here's the brutal reality:

Everyone's focused on the wrong metrics. They're counting GPU racks like dot-com companies counted servers. They're measuring model parameters like crypto bros measured hashrate. But just like those previous bubbles, they're missing the only metric that matters: sustainable revenue.

When the music stops - and it will stop - the only companies left standing will be those who figured out how to turn AI into real business value. Right now? That list is terrifyingly short.

Remember how Google built a $250B advertising business by simply knowing what people were searching for? That was just search intent - a tiny slice of human interest captured in a few keywords.

But something bigger is brewing.

Every day, millions of people are having deep conversations with AI chatbots. Not just searches - actual conversations about their problems, desires, and needs. We're talking about intent data that makes Google's search signals look like cave paintings.

And nobody's talking about this. Everyone's too busy either hyping AGI or predicting the bubble's collapse.

In 2000, companies were building data centers hoping e-commerce would take off. In 2022, companies were buying GPUs hoping crypto would moon. But in both cases, they were building infrastructure hoping for future demand.

What's happening now? The demand is already here. Look at the numbers

When display ads first appeared, everyone hated them. When Google showed search ads, people called it the death of the internet. But what happened when the ads actually became relevant to what people wanted? Google built the most profitable business in history.

Now imagine those ads being not just relevant, but perfectly personalized. Not just targeted, but generated specifically for you.

Yes, training large language models is expensive. Yes, most AI companies will die. But real-time ad generation and personalization? The compute requirements are tiny in comparison. We're talking about an entirely different economic model.

The holy grail of advertising has always been: right message, right person, right time. We spent billions trying to approximate this with crude targeting and A/B testing.

But what if you could generate the perfect ad, in real-time, for each individual? Not just the targeting - the actual creative itself?

1. The chatbots have the intent data

2. The technology can generate the content

3. The distribution channels already exist

This isn't a $600B bubble. This is the beginning of a $3T opportunity that everyone's missing because they're looking in the wrong direction.

Right now, the global ad market is about $740B. Google and Meta combined? About $438B. Most people look at these numbers and think that's the ceiling.

But here's what happens when AI enters the picture: Production costs drop 90%. Performance jumps 5-7x. And most importantly, the market expands 6.5x because suddenly, every small business can afford personalized video and audio ads.

And this isn't theoretical. Let me share what early tests are showing:

• Traditional ads: 2.1% click-through

• AI-personalized: 11.3%

• Conversion improvement: 4.8x

• ROAS: 7.2x better

  These AI ad performance numbers are insane: 11.3% CTR (vs 2.1% traditional), 4.8x conversion improvement, 7.2x ROAS Thread 🧵

  Share

But here's the crazy part - these numbers get better with scale. At 1M users, you see 3x performance. At 10M users, 8x. At 100M users? 15x improvement.

Think about what this means:

• Every podcast you listen to? Different ads for each listener.

• Every YouTube video? Personalized product placement.

• Every streaming show? Real-time brand integrations tailored just for you.

This isn't sci-fi. The technology exists today. The infrastructure everyone's calling a bubble? It's actually massively insufficient for what's coming.

The user behavior data is already validating this:

• 70% prefer personalized content

• View completion rates up 180%

• Brand recall up 220%

• Purchase intent up 310%

Most importantly? Users can watch 8-10 personalized ads per day versus 3-4 traditional ads before fatigue sets in. We're seeing engagement drop only 15% versus 40% with traditional ads.

Yes, training the base models is expensive. But real-time ad generation?

• Video generation: 10x current capacity

• Audio personalization: 5x

• Real-time optimization: 3x

• Intent processing: 2x

Add it up: we need 20-30x current infrastructure just for this one use case. That $600B 'bubble'? It's actually a massive under-investment.

The adoption curve is already starting:

• 2024-25: Early adopters seeing 3x ROI

• 2026-27: Mainstream adoption at 5x ROI

• 2028-30: Mass market at 8x ROI

By 2030, we're looking at:

• Programmatic video: $990B

• Programmatic audio: $550B

• Interactive ads: $440B

• Traditional formats: $220B

  Why the $600B 'AI bubble' is actually a $3T opportunity everyone's missing. The parallels to early Google are striking... 📈

  Share

When Google launched AdWords, nobody predicted search advertising would become a $200B+ business. When Facebook launched News Feed ads, nobody saw social advertising becoming a $150B+ market. When programmatic display launched, nobody believed it would hit $153B.

But this? This is bigger than all of those combined. Because for the first time, we have:

• Perfect intent data from actual conversations

• Zero-cost creative production

• Real-time personalization

• Multi-channel delivery

• Exponential performance improvements

This isn't just another ad technology. This is the complete transformation of a $740B market. And that's before we count:

• New advertisers who could never afford video/audio before

• New channels that weren't viable for personalization

• New formats we haven't even imagined yet

When you multiply:

1. Cost reduction (90% lower)

2. Performance improvement (5-7x better)

3. Market expansion (6.5x larger)

4. New format creation

5. Perfect personalization

That $3T number starts looking conservative.

So here's the real bubble:

Not in AI infrastructure – in traditional advertising. Every dollar spent on non-personalized, static ads is about to look as outdated as buying newspaper classifieds in 2005.

The companies panicking about their GPU investments? They should be panicking about not investing enough.

Just like Google's early server investments, Meta's social graph infrastructure, or Amazon's cloud buildout – today's AI infrastructure investment will look obvious in hindsight.

The only question is: who's going to build it?

And here's the beautiful part:

• Unlike crypto, which needed mass adoption to work...

• Unlike metaverse, which needed new behaviors to form...

• Unlike Web3, which needed a whole new infrastructure...

This revolution requires:

1. Technology that exists today

2. Channels that exist today

3. User behaviors that exist today

4. Business models that exist today

It just needs someone to connect the dots.

Those calling 'bubble' are making the same mistake as the dot-com skeptics: focusing on today's costs rather than tomorrow's value.

Yes, most AI companies will die. Yes, GPU prices will crash. Yes, models will be commoditized.

But just like the internet bubble, the infrastructure being built today will power the next decade of growth – just not in the way most people think.

Now, I hear what the skeptics are thinking. Trust me - I've had these debates. And every objection sounds bulletproof... until you understand what's really happening beneath the surface.

Yes, there are technical challenges - latency requirements, attribution systems, context processing, hallucinations, brand safety. But here's what everyone's missing: these are engineering problems, not research problems. They're exactly the kind of challenges that create moats once solved. Just ask Google how "impossible" real-time ad auctions seemed in 2002.

Let's rewind to 1999. Yahoo was unstoppable:

- Best search technology

- Massive user base

- Top talent

- Billions in funding

Remind you of any AI companies today?

While Yahoo obsessed over search comprehensiveness:

- Google built AdWords

- Google owned distribution

- Google captured revenue

But here's what everyone misses - the greatest trick Google ever pulled wasn't building better search. It was making everyone think PageRank was their secret sauce while they quietly built the most profitable infrastructure in history. They literally gave PageRank away in academic papers. And still won. Why? Because infrastructure beats capability. Every. Single. Time.

The painful truth? Yahoo actually had better search. Just like today's AI leaders might build better models. But it didn't matter because Google owned the pipes. Sound familiar?

"But wait," I hear the AGI maximalists say, "why chase a measly $3T advertising opportunity when AGI is a $100T market?"

That's exactly what Yahoo thought: Why build a $250B ad business when you could organize all human knowledge? The devastating irony? Google's "small" ad infrastructure play didn't just win advertising - it won everything. Including, yes, AI.

Some say AGI is just thousands of days away - by 2027 or sooner. But here's the real kicker - that's exactly how long it takes to build robust infrastructure at scale. By the time AGI arrives in 2027, the distribution war will already be over. The pipes will already be owned. The winners will already be decided.

And that war? It's not happening in 2027. It's happening right now.

We're seeing this pattern play out again. Companies with existing distribution channels - from social graphs to enterprise relationships - are quietly building the pipes that will connect AI to actual humans. They don't need the best AI. They just need good enough AI plus distribution.

The truth is, even if AGI arrives tomorrow, it still needs:

- Distribution infrastructure

- Monetization pipes

- Attribution systems

- Real-time deployment

Missing these isn't a technical problem - it's an existential one. Just like OpenAI could build the perfect AGI and still lose if someone else owns the intent infrastructure.

History doesn't repeat, but it rhymes. The AI bubble isn't really about AI capability, just like the internet bubble wasn't really about websites. Both are about missing infrastructure.

Every major platform sees this now. Microsoft's OpenAI integration isn't just about ChatGPT - it's about owning enterprise AI distribution. Meta's social graph isn't just about connections - it's about owning consumer AI touchpoints. Google's moves aren't just about catching up - they're about protecting their distribution dominance.

The window for building this infrastructure isn't measured in years anymore. The company that owns these pipes - whether it's a tech giant or a new startup - will likely own the next decade of technology. Just like Google did with advertising infrastructure. Just like Amazon did with cloud infrastructure.

Everyone's building AI castles. Nobody's building the roads between them.

At least, almost nobody.

But what if we're looking at this completely backwards?

Here's what everyone's missing: We're not in an AI infrastructure bubble. We're actually catastrophically under-invested for what's coming. And I'll show you why with data that will blow your mind.

The real opportunity isn't in API fees or enterprise AI. It's in something far bigger: AI-generated, personalized audio and video advertising. Think programmatic advertising, but orders of magnitude larger.

Let me put this in perspective. In 2009, programmatic display advertising was a $0.5B market. By 2022, it hit $153B. That's a 300x increase. But that transformation will look tiny compared to what's coming.

Why? Because we're about to witness the perfect storm of three forces:

1. Unprecedented intent data from AI chatbots

2. Breakthrough capabilities in AI-generated audio/video

3. Programmatic infrastructure at scale

Think about the current ad landscape. Google knows what you search for. Facebook knows what you like. But AI chatbots? They know what you're actually thinking about, planning, and trying to accomplish. It's not just intent data - it's conversation data. Real, human conversation data.

Early tests are showing this is absolutely nuclear:

• Traditional ads: 2.1% click-through rate

• AI-personalized audio/video: 11.3%

• Conversion improvement: 4.8x

• Return on ad spend: 7.2x better

And here's the kicker - these numbers improve exponentially with scale:

Think about what happens when this hits scale. Current data shows the advantage compounds insanely fast:

• At 1M users: 3x performance boost

• At 10M users: 8x boost

• At 100M users: 15x boost

This isn't linear growth like traditional ad platforms. It's exponential. Every conversation makes the targeting better. Every interaction improves the personalization. And unlike cookies or social graphs, this data never goes stale - it gets better with every chat.

But here's where it gets really interesting...

Current digital ad market is about $740B. Google and Meta combined? About $438B. Most people look at these numbers and think that's the ceiling.

But they're missing something massive. Today's creative production costs eat up about $500B annually. What happens when AI can generate personalized video ads for basically zero cost? When you can test thousands of variations instantly? When every single ad is perfectly tailored to each viewer?

The data we're seeing is insane:

• Production costs drop 90%

• Performance jumps 5-7x

• Market expands 6.5x

And that's just the beginning. Because now you unlock the long tail...

Yes, we'll need 20-30x current GPU capacity. But here's why that number is actually conservative:

• Video generation: 10x current capacity

• Audio personalization: 5x

• Real-time optimization: 3x

• Intent processing: 2x

People look at these numbers and think 'bubble.' But let's do the math on the revenue potential:

Early pilot programs are showing:

• CPMs jumping from $2-5 to $10-20

• Conversion rates up 4x

• Customer lifetime value up 3x

When you multiply this across the entire advertising ecosystem, you start to understand why we're actually massively under-invested.

Imagine you're watching a YouTube video. Instead of the same generic ad everyone sees, you get a perfectly personalized video ad based on your recent AI chat conversations. The product is exactly what you're looking for. The messaging hits your specific pain points. The offer matches your budget.

Now multiply this across:

• Podcasts

• Streaming audio

• Connected TV

• Social video

• New formats we haven't even invented yet

Early data shows users actually prefer this:

• 70% prefer personalized content

• 85% accept it when value is clear

• 90% engage when relevant

And the engagement stats are mind-blowing:

• Traditional ads: 3-4 views per day max

• AI-personalized: 8-10 views, with 15% drop-off vs 40%

The rollout is already starting:

• 2024-25: Early adopters seeing 3x ROI

• 2026-27: Mainstream adoption at 5x ROI

• 2028-30: Mass market at 8x ROI

Final market size by 2030:

• Conservative case: $1.5T

• Base case: $2.2T

• Optimistic case: $3T

Break it down by channel:

• Programmatic video: $990B (45%)

• Programmatic audio: $550B (25%)

• Interactive ads: $440B (20%)

• Traditional formats: $220B (10%)

This isn't a bubble. It's the biggest opportunity in advertising history. And just like with programmatic display ads in 2009, most people won't see it until it's obvious.

But by then? The infrastructure will already be built. The moats will be dug. And the early players will be impossible to catch.

Remember: Google bought DoubleClick for $3.1B in 2007. At the time, people thought they were crazy. Today, that looks like the deal of the century.

The same thing is happening right now with AI infrastructure. We're not over-invested. We're not even close to what we'll need.

Everyone's focused on the wrong metrics. They're looking at current AI revenue, current GPU investments, current infrastructure costs. But they're missing the second-order effects.

Think about it: When Google launched AdWords, nobody predicted search advertising would become a $200B+ business. When Facebook launched News Feed ads, nobody saw social advertising becoming a $150B+ market. When programmatic display launched, nobody believed it would hit $153B.

But this? This is bigger than all of those combined. Because for the first time, we have:

• Perfect intent data from conversations

• Zero-cost creative production

• Real-time personalization

• Multi-channel delivery

• Exponential performance improvements

Unlike previous ad revolutions, this one has multiple growth vectors that compound:

1. Cost reduction (90% lower)

2. Performance improvement (5-7x better)

3. Market expansion (6.5x larger)

4. New format creation

5. Perfect personalization

Multiply these effects, and you start to understand why $3T isn't just possible - it might be conservative.

Current ads are tolerated. AI-personalized content is preferred. The data is clear:

• View completion up 180%

• Brand recall up 220%

• Purchase intent up 310%

We're moving from interruption to relevance. From annoyance to value. From mass media to perfect personalization.

That $600B 'bubble' in GPU investment? It'll look tiny in retrospect. Because we're not just building infrastructure for current AI use cases. We're building it for a future where:

• Every ad is personalized

• Every creative is generated

• Every interaction is optimized

• Every dollar is maximized

The real question isn't whether we're in a bubble. It's whether we're moving fast enough to capture the opportunity in front of us.

Because just like Google's early server investments, Meta's social graph infrastructure, or Amazon's cloud buildout - today's AI infrastructure investment will look obvious in hindsight.

The only question is: Who will build it?

In 2030, people will look back at this moment - at all the bubble talk, all the skepticism, all the concerns about over-investment - and they'll wonder how we could have been so wrong.

They'll cite the early data:

• 4.8x conversion improvements

• 7.2x ROAS gains

• 15x performance at scale

• 90% cost reductions

And they'll wonder how we missed something so obvious.

But that's the thing about paradigm shifts: They're obvious only in retrospect.

The infrastructure for a $3T market isn't built overnight. It's built years in advance, by people who see where things are going before everyone else.

That building is happening right now. The question is: Are we building fast enough?

Last night, I caught myself talking to ChatGPT the same way I'd text a friend - complete with typos and casual language. It hit me: our ways of communicating are evolving faster than we realize. One minute I'm firing off emoji-filled messages to friends, the next I'm having a surprisingly natural conversation with AI. It got me thinking about how far we've come from scratching messages on cave walls.

You see, we're on this incredible journey of making our thoughts travel further, faster, and more clearly. Think about it - our ancestors figured out that carving words into stone meant their ideas could outlast them. Pretty clever, right? Then came paper and ink, and suddenly our messages could travel anywhere. The printing press showed up, and boom - one person's words could reach thousands.

But here's where it gets really interesting. The keyboard came along and changed everything. We went from pecking at typewriters to tapping on computers, and our words could now be edited, copied, and shared instantly. Email pushed us even further, letting us chat with someone on the other side of the planet as easily as talking to our next-door neighbor.

And now? We've got ChatGPT. But calling it "just another keyboard" feels like calling your smartphone "just another telephone." Sure, at its core, it's a tool for communication - but it's doing something fundamentally different. It's not just recording our thoughts; it's helping us shape them.

Imagine you're trying to explain a complex idea to someone who speaks another language. Your regular keyboard can type out the words, but ChatGPT can help translate them, rephrase them, and even adapt them to different cultural contexts. It's like having a really smart friend who's fluent in every language and expert at explaining things sitting right next to you.

But wait - I can hear some of you thinking, "Isn't this just making us lazy?" That's exactly what people said about calculators, spell-checkers, and even the first keyboards. "If we don't write by hand anymore, we'll forget how!" Remember those conversations? Yet here we are, communicating more than ever before.

The truth is, each new communication tool has freed us up to focus on what really matters - the ideas themselves. When we stopped worrying about our handwriting, we could focus more on our message. When email made delivery instant, we could spend more time crafting our content. Now, ChatGPT is letting us focus on our core thoughts while it helps with the heavy lifting of making those thoughts clear and accessible to others.

Think of it this way: ChatGPT isn't replacing our ability to communicate - it's amplifying it. Just like the keyboard didn't make us worse writers (it made us more prolific ones), AI tools aren't making us worse thinkers. They're giving us new ways to express our thoughts and reach people we never could before.

What excites me most isn't what ChatGPT can do today - it's imagining what comes next. We went from stone tablets to global instant communication in just a few thousand years. Now we're taking another leap forward, breaking down the barriers of language and complexity that still stand between people and ideas.

So maybe instead of asking if ChatGPT is just a keyboard, we should be asking: what barriers to human connection and understanding will we break down next? Because if history's taught us anything, it's that we're really good at finding new ways to share what's on our minds.

And personally? I can't wait to see what we'll think of next.

Here's the thing: most AI systems today are what I affectionately call "professional Googlers" - they're really good at searching through documents and patching together answers. The tech world calls this RAG (Retrieval Augmented Generation), and while it's useful, it's just the tip of the iceberg.

Think of it this way: imagine you're trying to write a complex report about your company's performance across multiple regions. You could either hire someone to quickly skim through the top few documents and cobble together an answer (that's basic RAG), or you could work with an experienced analyst who's thoroughly studied your entire company's history and can draw meaningful connections across years of data. Big difference, right?

The limitation of basic RAG is pretty simple - it's like trying to understand a book by reading only the chapter summaries. These systems typically grab the top 5-10 most relevant pages they can find and piece together an answer. Sure, they might dress it up with fancy features like "enhanced retrieval" or "semantic search," but at their core, they're still just skimming the surface.

So what sets "real AI" apart? It's not just about having a bigger memory or faster processing - it's about how the system thinks. The best AI systems I've worked with are more like having a team of specialists working in perfect harmony. Instead of just one approach to finding and processing information, they can switch between different methods depending on what makes the most sense for your question.

Let me give you a real-world example. Say you're analyzing customer feedback across different product lines. A basic RAG system might pull up recent customer comments and generate a summary. But a more sophisticated system could simultaneously analyze historical trends, compare sentiment across different customer segments, and identify patterns that might not be obvious from just reading recent feedback. It's the difference between getting a quick overview and gaining actual insights.

But here's where it gets interesting - and this is something most vendors won't tell you. Even these more advanced systems often use basic RAG as one of their tools. The key difference is they know when to use it and when to try something else. It's like having a master chef who knows exactly which kitchen tool to use for each part of the recipe, rather than trying to chop everything with the same knife.

The real test comes when you're dealing with complex scenarios - like legal analysis or financial reporting. This is where you'll see the biggest difference between basic and advanced systems. A sophisticated AI doesn't just retrieve and summarize; it can understand context, spot inconsistencies, and handle nuanced interpretations that would trip up simpler systems.

So how can you tell what you're really getting? Here's my practical advice: don't get caught up in the technical jargon or flashy demos. Instead, test the system with complex, multi-part questions that require understanding context and making connections. Watch how it handles follow-up questions or corrections. A truly advanced system won't just give you information - it'll demonstrate understanding.

Looking ahead, I'm excited about where this technology is heading. We're moving toward AI systems that feel more natural to interact with - think conversation rather than typing queries into a search box. But the key is making sure we're building on the right foundation.

Remember, the goal isn't to have AI that can simply find and repeat information - we want systems that can truly understand and help us make better decisions. Whether you're evaluating AI vendors or just trying to understand the technology better, keeping this distinction in mind will help you cut through the hype and focus on what really matters: finding tools that actually solve your problems.