MindHYVE.ai

Doctrine

The scaffolding comes down

Why the industry spent two years building orchestration it is now deleting — and what is left standing when it goes.

Bill FarukiFounder & CEO12 min read

Originally published on billfaruki.substack.com on August 27, 2026. Republished on MindHYVE.ai with light canon edits.

In the summer of 2022, I started building agentic AI, except nobody called it that yet.

There was no word for a system that reasons through a professional's work rather than answering a professional's question. There were no frameworks. There was no agent stack diagram, no orchestration layer, no harness, no MCP.

There was a conviction, which I could not yet defend with anything except the conviction itself:

The thing worth owning was not access to a model, but the reasoning a domain requires — held somewhere the model could not take back.

Four years on, the industry has built an enormous amount of machinery on the opposite bet.

And this year, it started tearing that machinery down.

I want to write about what is coming down, why, and what is left standing when it goes.

This is not a victory lap.

It is an argument about which assets survive a model release, made at the moment the field is discovering the answer the expensive way.

What the industry built instead

Between 2023 and 2025, the dominant answer to “How do we make a model do real work?” was:

Put a controller above it.

LangGraph. CrewAI. Google's ADK. An agents SDK from one of the major labs. Microsoft's Semantic Kernel. Amazon's Strands. LlamaIndex.

Different abstractions, one architecture.

An external orchestrator tracks state and injects instructions at every turn. Enormous engineering investment went into this — by the companies building the frameworks and by everyone adopting them.

The architecture made sense for the models of 2023.

A model that could not hold a long procedure in its head needed the procedure held for it.

So the field built the holding.

Then the models got better.

And the holding became the constraint.

The measurement that should change how you plan

In May, a team at Melbourne published a controlled comparison that I think is one of the most consequential applied-AI results of the year — and almost nobody in the vertical AI conversation has read it.

They took three procedural domains:

  • Travel booking — 14 nodes
  • Technical support — 14 nodes
  • Insurance claims — 55 nodes

They ran 200 conversations per condition, per domain.

Same model on both sides.

The only variable was architecture:

Option one: an external LangGraph orchestrator.

Option two: the entire procedure serialized into the system prompt, with the model left to route itself.

The in-context approach won every metric in every domain.

Fifteen out of fifteen comparisons.

The orchestrated system failed on:

  • 24% of travel conversations
  • 9% of support conversations
  • 17% of insurance conversations

The unorchestrated baseline failed on:

  • 11.5% of travel conversations
  • 0.5% of support conversations
  • 5% of insurance conversations

Orchestration also required 1.2 to 1.7 times more model calls to do worse, because every decision hub spends a call deciding.

Their diagnosis is the part worth sitting with.

Orchestration fragments reasoning.

The model generates each turn seeing only the current node, producing locally sensible and globally incoherent work.

It introduces failure modes that would not otherwise exist:

  • routing errors,
  • ambiguous edges,
  • template conflicts,
  • and downstream error propagation.

A claim type misclassified at intake produces the wrong questions, then the wrong coverage determination, then an unresolved claim.

One major lab's own guidance moved in the same direction this year: from build a harness toward ask what you can delete, on the reasoning that scaffolding designed for a weaker model becomes a cage for a stronger one.

And there is a measured gradient underneath all of it.

Adding a planning-and-verification scaffold roughly doubles task success for weak backbones and contributes far less on the strongest ones.

The value of external structure decays as capability rises.

That is not a prediction.

It is in the tables.

If your product's differentiation is the controller, you are holding a depreciating asset — and the depreciation schedule is set by someone else's release calendar.

Why 'the harness is the moat' is a losing position

There is a widely circulated thesis that the orchestration layer is where advantage accumulates — that the model commoditizes and the harness compounds.

I have no quarrel with the economics.

I have a quarrel with who gets to occupy that position.

At a major platform conference this year, one of the hyperscalers made the harness argument operational:

Agents registered and managed at the operating-system level. Persistent context across agent sessions. Customer usage feeding back into model training.

They are making that argument from 400 million seats, their desktop operating system as the agent runtime, and their own cloud underneath.

Another hyperscaler is running the same play into roughly 150,000 existing customers.

A third is running it on two billion devices.

If the contest is for the harness, a vertical company loses it.

Not on merit.

On distribution.

Any founder whose deck says “the orchestration layer is the moat” should read that keynote and then read their own slide again.

So the honest question is not whether orchestration compounds.

It is:

What compounds that a platform cannot bundle and a model release cannot delete?

Three assets that survive a model release

1. The corpus

Not data in general.

Data that was expensive to construct and is not on the open web.

We built the Islamic Primary Sources Corpus because the reasoning we needed did not exist in machine-readable form:

617,912 narrations across 123 classical works, every chain of transmission parsed, narrators resolved where determinable, every grade traced to documented inputs.

A better frontier model does not produce that.

It consumes it, if you give it access.

2. The reasoning, compiled into weights

This is the piece the research caught up to in May.

The same Melbourne group published a companion result:

Compile the procedure into a small fine-tuned model instead of holding it in a controller or a prompt.

An 8B compiled model reached 87% to 98% of in-context frontier quality, ran 128 to 462 times cheaper per conversation, and recompiled in 30 to 50 minutes.

A build cycle.

Not a research project.

Read their stated motivation, because it is the argument I have been making since before the papers existed:

The in-context approach requires a frontier model on every single conversation, inflates tokens, consumes context, and exposes proprietary procedures to third-party providers.

That last clause is the whole thesis.

If your domain reasoning lives in a prompt, you are shipping it to a vendor on every request.

If it lives in weights you trained on a corpus you built, you are not.

3. The reconstructability record

In regulated work, the deliverable is not an answer.

It is a position that survives audit.

The risk is not complexity.

It is output that cannot be traced, verified, or reconstructed months or years after the fact.

And the market is increasingly being told to demand exactly this.

General models still hallucinate legal content at rates approaching 58% to 88% on tasks such as case citation, and the best general model tested still fabricated in 23% of clinical case summaries with every mitigation applied.

Meanwhile, the benchmark picture shows models strongest on isolated reasoning, weaker on retrieval over real document corpora, and weakest on rubric-graded tasks that mirror what a practitioner actually does.

Average scores do not survive a deposition.

None of these three assets is an orchestration claim. All three are what we spent four years accumulating while the field was building controllers.

Where the bitter lesson actually applies

The standard objection is Sutton's:

General methods that scale with compute beat hand-built structure, every time, and anyone encoding human process into a system is on the wrong side of history.

I accept the lesson.

I dispute its range.

Its force is greatest where data is abundant:

General coding. General web tasks. Domains where the internet already contains a million worked examples.

Its application is far more complicated for novel tasks and niche domains where training data is scarce.

That is not my caveat.

It is stated plainly in the agentic software engineering literature.

Scarcity is the whole condition of the verticals we chose.

There is no web-scale corpus of workers' compensation apportionment reasoning under California Labor Code 4663.

There is no scraped archive of how a trained scholar moves from a chain of transmission to a defensible position on a question.

Where the examples exist in bulk, scale wins.

You should not fight it.

Where they do not, someone has to construct them.

That construction is the work.

And it does not get cheaper when the models get better.

It gets more valuable, because the models get better at using it.

The honest limits of what I just cited

I want to name what these papers do not establish, because I would rather do it than have a diligence reader do it for me.

The orchestration comparisons run on synthetic procedures with simulated users and model-as-judge scoring, and the authors say so.

Their finding is scoped to multi-turn conversations following a defined procedure.

They explicitly exclude:

  • multi-model pipelines,
  • tool use against external state,
  • non-procedural work,
  • and smaller models.

Taken together, those categories describe much of what a production vertical system actually does.

Nobody has replicated any of this on our estate.

And the compiled-weights result is one team's finding at one parameter scale.

None of it mentions MindHYVE™.

None of it was written to support anything I am building.

That is precisely why it is worth citing.

It is the field arriving independently at a conclusion — and independent arrival is the only kind that counts.

What I will not claim:

That we have measured any of this internally at that rigor, or that a compiled reasoning layer is a completed defense rather than an accumulating one.

What this means if you are building

Ask which of your assets a competitor's next model release deletes.

Prompt libraries: deleted.

Routing graphs: deleted — and probably an active liability.

Framework expertise: depreciating on someone else's schedule.

A constructed corpus in a domain with no web-scale equivalent: not deleted.

Reasoning compiled into weights over that corpus: not deleted.

A traceability record a regulator will accept in 2029: not deleted — and increasingly the thing the buyer asks for first.

Then ask the harder question:

Is the thing you call your moat a position that a platform with 400 million seats would like to occupy?

If it is, it is not a moat.

It is a queue.

I did not get here by reading these papers. I got here in 2022, by betting that the durable thing was the reasoning and the corpus rather than the wrapper, at a moment when that bet had no vocabulary and no evidence behind it.

The evidence arrived this year.

The scaffolding is coming down across the industry.

And what is standing underneath it, for us, is what we were building instead.

Build the thing the next model release cannot take away from you.

Bill Faruki
Founder & CEO, MindHYVE.ai

The AI reasons. The human decides.

Sources

Dennis et al., “In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks” — arXiv:2604.27891, v2 May 2026. Dennis et al., “Compiling Agentic Workflows into Model Weights” — arXiv:2605.22502. “Agentic Software Engineering: Foundational Pillars and a Research Roadmap” — arXiv:2509.06216. AgentSynth scaffolding evaluation — arXiv:2506.14205. CRV, “What Is Vertical AI?” — July 2026. Kili Technology, “Domain-Specific Model Benchmarks: 2026 Vertical AI Map” — May 2026. Cognitive World, “AI in Regulated Industries” — February 2026. Coverage of 2026 platform-conference agent-harness announcements. Corpus figures as published at ipsc.theogrid.ai, verified August 27, 2026.

First published on Bill Faruki's Substack on August 27, 2026. Lightly edited for house style. Read the original.