There is an uncomfortable parallel between the AI industry in 2026 and post-war manufacturing in the 1950s. Both produced at impressive scale. Both relied on end-of-line inspection to catch defects. And both treated quality as someone else’s problem: in the factory, it was the inspector’s job; in the AI pipeline, it is the human reviewer’s.

The manufacturing world took roughly three decades and one quality revolution (starting in Japan, spreading across Europe and the United States) to learn that this approach does not work. The AI industry is on track to learn the same lesson, and it does not need to take that long.

The verification tax

Consider the workflow that has become standard in any serious AI deployment. An agentic system analyses documents, extracts data, synthesises findings, and produces an artefact: a report, a codebase, a dataset, a slide deck. Then a human sits down to verify and validate. This is the V&V step, borrowed from systems engineering, and it is where the entire quality burden now lands on human cognition: reading, cross-checking, hunting for errors the system cannot see.

The cost of this is rarely measured but always felt. Every artefact produced by an AI agent carries an implicit verification tax: the time, attention, and domain expertise a human must spend to confirm the output is correct. As AI systems produce more, faster, the tax does not shrink. It compounds. The human becomes the bottleneck in a pipeline that was supposed to remove bottlenecks.

The problem is not that humans are bad at verification. The problem is structural. The reviewer is validating against a specification that exists only in their head. They carry tacit knowledge about what a correct output looks like: domain conventions, semantic constraints, inter-field dependencies, formatting norms, edge cases learned through years of practice. None of this is written down. None of it is measurable. And none of it is available to the system that produced the artefact in the first place.

You might argue that we could delegate this review to another AI agent. In practice, this merely displaces the problem. An LLM asked to “check if this extraction is correct” will apply its own stochastic judgement, not a deterministic specification. It cannot guarantee coverage of domain-specific rules it was never explicitly given. It is, in current jargon, “LLM-as-judge”: an ad hoc assessor with no formal quality framework, no defined tolerances, and no traceability.

This is still inspection. And as W. Edwards Deming spent his career arguing, from his work with Japanese manufacturers in the 1950s to his later influence on Western industry, inspection does not produce quality. It merely sorts good outputs from bad ones after the damage is done. The defect has already been produced; you are just deciding whether to ship it.

What the quality revolution actually taught us

The transformation that Deming helped set in motion (first in Japan, then adopted globally through lean production, the Toyota Production System, and Six Sigma, originally developed at Motorola) rested on a deceptively simple insight: quality must be built into the process, not verified after the fact. The mechanism for this shift was formalisation. You take what you know about what “good” looks like, and you turn it into things you can measure.

In quality engineering terminology, these are Critical to Quality characteristics (CTQs): measurable properties of the output that matter to the end user, derived from higher-level requirements through a structured decomposition. A CTQ is not a vague aspiration (”the output should be accurate”). It is a specification with a target, an upper tolerance, a lower tolerance, and a measurement method. The diameter of this shaft shall be 25.00mm ± 0.02mm, measured by coordinate measuring machine.

Once you have CTQs, everything else follows. You can monitor the process in real time. You can calculate whether the process can reliably produce within specification. You can anticipate failure modes before they occur. And you can design the process itself to make defects structurally difficult to produce.

This last concept, known as poka-yoke in the Toyota Production System, is particularly instructive. A poka-yoke is a constraint built into the process that prevents errors by design. A USB connector that only fits one way. A car that will not shift into reverse above a certain speed. The principle is not to train the operator to be more careful; it is to make the wrong outcome mechanically impossible, or at least immediately detectable.

In software engineering, this philosophy has mature equivalents: Design by Contract (preconditions, postconditions, invariants), static type systems that catch errors at compile time rather than run time, property-based testing that verifies behavioural invariants across thousands of generated inputs. The underlying principle is the same: formalise what “correct” means, and verify it automatically.

The octopus in the labyrinth

Now transpose this to agentic AI. An LLM executing a complex task (extracting structured data from a document, generating a technical report, producing code from a specification) is, in essence, an octopus in a labyrinth. It is remarkably capable: flexible, fast, able to squeeze through passages that rigid rule-based systems could never navigate. But it has a fundamental limitation. It decides for itself whether it has reached the exit. It has no external reference for “done.” It has no walls telling it “not this way.” It is navigating by feel and by pattern, and when it reaches what looks like an opening, it declares success, even if it is in a dead end.

What we propose is to separate the problem into its constituent parts. The octopus is the agent: the flexible, adaptive intelligence that navigates. The labyrinth walls are the compiled constraints: the assertions, invariants, and V&V rulesets that define what constitutes a valid path. And the definition of done is external to the agent, established during build time, not improvised during run time.

The missing middle layer

What does this look like concretely? Consider the current landscape of quality tools available for AI pipelines.

Structured output validation (JSON Schema, Pydantic models) checks whether the output conforms to a data structure. This is necessary, but it operates at the syntactic level. It is type checking. Verifying that a field called “total_amount” is a number is not the same as verifying that the number equals the sum of line items minus the discount, and that the discount rate matches the contractual terms on file.

Guardrails frameworks (NeMo Guardrails, Guardrails.ai) enforce constraints around safety, format compliance, and topic boundaries. Again, necessary. But these are generic: they know nothing about the specific domain in which the AI is operating.

LLM-as-judge approaches use one model to evaluate another’s output. This introduces stochasticity into the quality process itself. Running the same evaluation twice may yield different results. There is no specification, no tolerance, no traceability.

What is missing is the middle layer: domain-aware, semantically rich, measurable quality characteristics that are formally derived from compiled domain knowledge and enforced inline during execution. Not type checking, but semantic contract enforcement.

To make this concrete: consider a system extracting financial data from fund reports. A compiled quality specification for a single field, the net asset value per share, would define not just that the field must be a number (structured output), but that it must be arithmetically consistent with total NAV divided by shares outstanding, that it must fall within a plausibility bound relative to the prior quarter, that its currency denomination must match the fund reference data, and that any deviation triggers a defined response (flag, escalate, halt). Each of these rules is a domain invariant, compiled from expert knowledge, enforced deterministically at run time.

These are not validation rules that an engineer guesses at. They are quality characteristics systematically derived from domain knowledge. And the methodology for deriving them, ensuring coverage, and maintaining them as the domain evolves, is where the real work lies.

Build time and run time

The approach separates AI pipeline design into two distinct phases, borrowing from both quality engineering and software compiler design:

Build time is when domain knowledge is compiled into executable artefacts: the contract specifications (what must be true about each output, with targets and tolerances), the assertion sets (deterministic checks, cross-field validations, plausibility bounds), and the pipeline topology (which steps execute in what order, with quality gates between them). Build time is where you define the invariants and embed the poka-yokes.

Run time is when the agent executes within this compiled framework. The LLM does what it does best: flexible, adaptive processing of unstructured information. But it operates within constraints. Every intermediate artefact is measured against its compiled specifications. Violations trigger defined responses. The definition of done is not the model’s assessment of its own performance; it is the compiled specification’s assessment of the output.

This is not a new idea in principle. Design by Contract has existed since the 1980s. Static analysis catches entire classes of bugs at compile time. What is new is applying this rigour to the specific challenge of AI-generated artefacts, where the execution engine is stochastic by nature and the output is information rather than a binary.

The missing abstraction

The current tooling for AI quality (structured outputs, guardrails, evaluation benchmarks, LLM-as-judge) addresses symptoms without providing an organising principle. Each tool solves a narrow problem. None of them answers the question: where do the quality specifications come from? How are they derived from domain knowledge? How do you ensure coverage? How do you maintain them as the domain evolves?

This is the gap. Without a systematic methodology for compiling domain knowledge into measurable specifications, AI engineers write ad hoc validation rules based on their best understanding of the domain. Coverage is accidental. Maintenance is manual. The quality system is fragile because its foundations are informal.

With domain knowledge compilation, you have a formal, auditable, maintainable derivation of quality specifications from source knowledge. The compilation step is what makes everything downstream, the runtime enforcement, the monitoring, the continuous improvement, possible and grounded.

The road ahead

We are not suggesting that this is easy. The hardest part is not building the enforcement system; it is defining what to enforce. Eliciting tacit domain knowledge from experts and formalising it into measurable specifications is painstaking work. It requires deep domain understanding, iterative refinement, and the intellectual honesty to admit when a quality characteristic is not yet measurable.

But the alternative, the status quo of human-in-the-loop inspection at the end of an AI pipeline, does not scale. It worked when volumes were low. It breaks when you are processing thousands of documents, generating hundreds of artefacts, extracting millions of data points. The verification tax becomes the dominant cost.

The manufacturing world learned this lesson. The question is whether the AI industry will learn it from history, or insist on learning it the hard way.

Subscribe now

I spent fifteen years between two worlds that rarely talk to each other: lean manufacturing and quality engineering on one side, machine learning and generative AI on the other. I hold a Six Sigma Black Belt and have built AI systems for critical industries. This article exists because I kept seeing the same quality failures I had learned to prevent on the factory floor reappearing, almost identically, in AI pipelines. The tools to fix them already exist. They just need translating.

This article reflects work at the intersection of AI systems design and quality engineering. We build systems where LLMs act not as autonomous engines but as compilers: transforming structured knowledge into verified, auditable artefacts. The ideas here draw on practice in critical systems engineering, lean production principles, and the daily reality of making AI outputs trustworthy enough for professional use.

In the Lascaux prehistoric cave (France), just below the famous painting of a great stag, there’s a discreet drawing that’s easy to miss: a simple rectangle. No animal, no scene, just four lines meeting at right angles.

Stanislas Dehaene, the French neuroscientist at the Collège de France, spent years investigating why early humans drew geometric shapes before they drew anything else. His conclusion, published in Le Rectangle de Lascaux (2026): geometry is a language of thought unique to Homo sapiens. Before language, before writing, before agriculture, our ancestors were already thinking in shapes. Rectangles, circles, spirals, parallel lines. These aren’t decorations. They’re the native format of human cognition.

40,000 years later, we built machines that think in tokens.

And now we’re asking both to work together.

Three conversations, three mismatches

Every AI system involves three communication channels. Each has a different problem.

Agent ↔ Agent is the easy one. Tokens in, tokens out. JSON, function calls, structured data. Machines don’t care about bandwidth. They don’t get bored. They don’t skim. This channel is essentially solved — it’s engineering, not design.

Human ↔ Human is the ancient one. We’ve been optimising this for millennia. And the pattern is clear: whenever the stakes are high, we don’t just write, we show. The board presentation. The architectural blueprint. The napkin sketch. The war room whiteboard. High-stakes human communication converges on visual artifacts because that’s where our cognitive bandwidth lives. Vision processes information at roughly 10 million bits per second. Language? About 50 bits/sec. The ratio isn’t close, it’s five orders of magnitude (100 000x).

Agent ↔ Human is the broken one. And it’s broken in a specific way: agents communicate like they’re talking to other agents. They dump plans in prose. They explain in paragraphs. They output reasoning traces that read like legal depositions. All tokens, no shapes.

The smarter the agent gets, the worse this mismatch becomes. More capability means more output. More output means more text the human has to read, validate, and course-correct: all through a 50 bit/s pipe.

The validation bottleneck

This isn’t an abstract UX concern. It’s the binding constraint on agent usefulness.

When an agent generates a work plan, a research synthesis, or a presentation draft, a human needs to validate it. They need to evaluate whether the structure, logic, and emphasis are right. Today that means reading. A lot. And reading is slow, sequential, and exhausting.

The result is predictable: people skim, approve, and move on. The agent executes a plan that was never truly reviewed. We’ve traded one problem (doing the work) for another (supervising work we can’t efficiently inspect).

Dehaene’s research suggests why this feels so wrong. Humans don’t just prefer visual information: we have dedicated neural circuits for processing geometric regularity. His team showed that when we look at a shape, we immediately form a mental program for it: a compact, symbolic representation built from primitives like symmetry, parallelism, and repetition. This “geometric language of thought” operates alongside (and partly independent of) natural language.

In other words, shapes aren’t a nice-to-have. They’re a cognitive channel that text literally cannot replace.

The presentation paradox

When an agent generates a slide deck, it’s not producing output for itself: it’s producing an artifact for “human↔human” persuasion. But it builds that artifact the only way it knows how: token by token, optimising for textual coherence. It has no access to the visual, spatial, emotional channel that actually drives conviction between humans.

This is why AI-generated decks are always... adequate. Coherent structure, reasonable visuals, generic everything. A great presentation is shaped by context you can’t verbalise upfront: the politics of the room, the board’s past objections, the visual shorthand your industry uses, the emotional arc that will land with this audience. This is System 1 territory (spatial, intuitive, felt) not something you can spell out in a prompt.

Current tools force a binary choice: re-prompt and regenerate the entire deck (losing everything you shaped), or manually edit the final pixels (defeating the purpose of automation). The agent produces the artifact, but the human can’t inject what matters most: the non-verbal intelligence that makes the difference between a deck that informs and one that convinces.

Visual Plan Mode

The fix is structural, not cosmetic. Instead of text plans that humans read, or final artifacts that humans manually edit, we need an intermediate layer that speaks the brain’s native geometric language.

For a presentation, this means three steps:

Storyline: a lightweight text structure. What’s the argument? What’s the sequence? This is System 2 territory: logic, coherence, narrative arc. Agent and human can iterate fast here.

Layouts: the agent proposes visual arrangements for each slide. Not final designs (spatial blueprints). Where’s the chart? Where’s the headline? What’s the visual weight? The human grasps these instantly (System 1), adjusts with a drag, and moves on. This is the step current tools skip entirely.

Generation: the agent renders final content within the validated layouts. Each element stays editable without regenerating the whole slide. The layout acts as a constraint that preserves the human’s intent.

This three-step loop works because it matches how cognition actually flows: logic first (System 2), then spatial validation (System 1: the geometric channel), then detail.

But presentations are just one case. The principle generalises: any complex agent output benefits from a visual intermediate representation. A project plan becomes an editable timeline, not a bullet list. A research synthesis becomes a spatial map of themes, not a wall of text. A financial model becomes an annotated flow, not a paragraph of cell references.

The shape of what comes next

The agent ecosystem is racing to make models smarter. Longer context windows, better reasoning, more tools. But the interface, where agent and human actually meet, is stuck in the terminal. Text in, text out.

Dehaene showed that 40,000 years ago, our ancestors were already encoding complex thought into geometric forms. That capacity didn’t disappear when we invented writing: it was obscured by it. The most powerful cognitive channel we have is the one our AI tools ignore.

The rectangle in Lascaux wasn’t primitive. It was the first interface.

It’s time we built the next one.

At Knowtilus, we’re building visual plan mode for knowledge work. The intermediate representations are called Knowtiles: editable, auditable visual building blocks that sit between human intent and agent execution. If you work in consulting, advisory, or financial analysis, let’s talk.

The Invertebrate Problem

Watch a modern AI agent in action. It receives a task, reasons about it, decides on a plan, executes steps, adjusts on the fly, and sometimes (often, actually) does something unpredictable that breaks the entire workflow.

This is the invertebrate architecture: the LLM is the brain, the body, and the spine all at once. It decides what to do, how to do it, and in what order. Every decision is probabilistic. Every execution is a fresh generation. The agent is flexible, capable of remarkable contortions but structurally unsound.

The numbers tell the story. Multi-agent success rates degrade from 58% on single-turn tasks to 35% on multi-turn ones. Nearly 79% of failures stem not from reasoning errors but from specification and coordination issues. The agent knows what to do. It just can’t reliably do it the same way twice.

Enterprises have noticed. While 88% of organisations now use AI in at least one function, roughly two-thirds still can’t scale beyond pilot projects. The gap isn’t intelligence. It’s structure.

More Tentacles Won’t Help

The current industry response to unreliable agents is to give them more tools. More MCP connectors. More skills. More context. An agent with 50 integrations can read your CRM, query your database, send emails, generate charts, and search the web : all in one turn.

But it still decides which tools to call, in what order, with what parameters, every single time. The workflow is emergent. The agent figures it out at runtime. More tools make a more capable invertebrate. Still an invertebrate.

This is the equivalent of giving an octopus more tentacles. The problem was never capability. It was structure.

Tools give the agent hands. What it’s missing is a spine : a rigid internal structure that says “you will do step A before step B, you will use this formula for X, you will not skip the validation check Y” regardless of which model is driving.

What Vertebrates Have That Invertebrates Don’t

In biology, the vertebrate innovation wasn’t a bigger brain. It was a spinal column : a rigid internal structure that constrains movement into reliable, repeatable patterns while freeing the nervous system to handle only what requires genuine intelligence.

An octopus is brilliant. It can open jars, solve puzzles, squeeze through impossible gaps. But you wouldn’t build a factory around one. You’d build it around vertebrates: organisms whose movements are predictable, repeatable, and structurally constrained, with intelligence deployed where it actually matters.

A vertebrate agent has:

A spine : deterministic, compiled workflow logic that defines what steps execute, in what order, with what constraints. This is code, not prompts. It runs the same way every time. It’s auditable, versionable, and testable.

Joints : bounded points where the LLM is invoked for genuine intelligence tasks: interpreting ambiguous text, drafting narrative, classifying edge cases. The LLM operates within a slot defined by the spine. It can move freely, but only within the range the joint allows.

Muscles : the domain knowledge, business rules, and validation logic that connect spine to action. An EBITDA margin is calculated as EBITDA / Revenue × 100. A compliance document must contain sections A, B, C in that order. These aren’t suggestions. They’re constraints encoded in code.

The LLM never decides the workflow’s path. It fills bounded slots within a structure it didn’t create and can’t override.

Graduated Determinism: Not All Vertebrae Are Equal

A real spine isn’t uniformly rigid. The cervical vertebrae allow the head to turn freely. The thoracic vertebrae lock the ribcage in place. The lumbar vertebrae bear load with controlled flexibility. The architecture should reflect this gradient.

Hard rules : the skull. Zero LLM involvement. EBITDA is calculated, not interpreted. The company logo goes bottom-right, 24px from the edge. A regulatory filing must contain these sections in this order. These are validators, layout constraints, calculation rules. If they fail, the output is rejected.

Soft rules : the thoracic spine. Deterministic defaults that humans can override. The executive summary is typically two slides. Financial projections default to three years historical plus two projected. The system proposes; the human disposes.

Bounded LLM slots : the joints. Runtime intelligence, contained. Given the financial data and the kick-off notes, write the narrative paragraph under the EBITDA bridge chart. Given the management bios, draft the key persons slide. The LLM fills a slot defined by the spine, never the other way around.

When semantic judgment is unavoidable, the pattern is what researchers call the “Safety Sandwich”: deterministic validation before the LLM call constrains the input; deterministic validation after the call constrains the output. The LLM is sandwiched between two layers of compiled rules. It can think freely within its slot. It cannot escape it.

This gradient, from fully deterministic to bounded probabilistic, is what makes vertebrate agents practical. Not every decision needs to be hard-coded. But every decision needs to know which category it belongs to.

Who Builds the Spine?

Here’s where the field reveals a gap.

The research demonstrates that vertebrate architecture works. Deterministic workflows with bounded LLM calls outperform autonomous agents on reliability, cost, and surprisingly on accuracy too. Models perform dramatically better when given curated structure than when they self-organize. One benchmark found a 16-pp improvement with curated skills, and zero or negative benefit from self-generated ones.

The models cannot build their own spine. Someone has to build it for them.

But who? Today, the answer is: a developer, manually, for each workflow. That’s where the node-based tools stop. It works for a handful of workflows. It doesn’t scale to the thousands of domain-specific processes an enterprise runs.

The missing piece is knowledge compilation : the systematic extraction of organisational knowledge (from documents, processes, expert minds, past deliverables) into the compiled, deterministic artifacts that form the spine. An ontology that structures what the organisation knows. Validation rules derived from how the organisation actually works. Bounded LLM slots placed exactly where genuine judgment is needed.

This compilation layer (not the models, not the raw knowledge) is where durable value accrues. The LLMs are commoditizing. The spines are not.

The Uncomfortable Implication

The dominant narrative in AI, that we need bigger, smarter, more autonomous agents, is directionally wrong for enterprise adoption.

What enterprises need isn’t more intelligence. It’s more structure around the intelligence they already have access to. The value isn’t in the model. It’s in the compilation layer that turns organisational knowledge into a reliable spine, then deploys any model’s intelligence within it.

The agent doesn’t need a bigger brain. It needs a spine.

Hadi Mahihenni is CEO and co-founder of Databold

We’re building the knowledge compilation layer for structured professional artifacts: the infrastructure that turns organisational expertise into reliable, auditable spines for AI-generated deliverables. We’ve validated the architecture on two live use cases (decision decks and financial data extraction workflows) and we’re raising to generalise it. If you’re an engineer who wants to work on this problem, or an investor who sees where it’s going, please reach out.

Notes & Further Reading

The empirical findings referenced in this piece draw from several recent research papers for those who want to go deeper:

[1] Multi-agent failure rates (79% from specification/coordination, 58%→35% degradation): Trooskens et al., “Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation,” April 2026. arxiv.org/abs/2604.05150

[2] The “Safety Sandwich” pattern and compile-time code generation achieving 57× cost reduction: same paper as [1].

[3] The “Blueprint First, Model Second” philosophy and Source Code Agent framework (+10.1pp over best baseline on τ-bench): Qiu et al., Alibaba Group, August 2025. arxiv.org/abs/2508.02721

[4] Curated skills = +16.2pp improvement, self-generated skills = zero or negative benefit, smaller models + good skills ≈ bigger models: Li et al., “SkillsBench,” February 2026. arxiv.org/abs/2602.12670

[5] Same compiled skill = up to 40% performance variance across models and frameworks: Chen et al., “SkVM,” April 2026 arxiv.org/abs/2604.03088; Ouyang et al., “SkCC,” May 2026 arxiv.org/abs/2605.03353.

[6] Multi-level skill compilation from agent trajectories (planning / functional / atomic): “SkillX,” submitted to ICML 2025. arxiv.org/abs/2604.04804

[7] The “Code Factory” paradigm — LLM writes code once, code runs forever: XY.AI Labs, “The Code Factory Manifesto,” January 2026. xy.ai/tech-behind-xyai/the-code-factory-manifesto

[8] Organisational tacit knowledge extraction via LLM-conducted expert interviews: Zuin et al., July 2025. arxiv.org/abs/2507.03811

[9] Codified expert domain knowledge achieving 206% improvement in AI agent output quality: “How to Build AI Agents by Augmenting LLMs with Codified Human Expert Domain Knowledge,” CAIN’26. arxiv.org/abs/2601.15153

[10] The “deterministic code as out

put layer” architecture applied to industrial operations: OSS Ventures, November 2024. medium.com/oss-ventures

What I’ve learned: the bottleneck isn’t AI intelligence. It’s AI structure. The models can reason, write, and analyse. What they can’t do reliably is produce the same artifact the same way twice, respect domain rules they weren’t trained on, or work within constraints that matter to the people who sign the deliverable.

This Substack is where I’ll think out loud about what I’m calling compiled intelligence: the emerging architecture where organisational knowledge gets compiled into deterministic artifacts that constrain AI execution, rather than hoping the model figures it out at runtime.

Expect a post every week. Topics will range from the technical (knowledge compilation, ontology design, hybrid neural-symbolic systems) to the practical (what actually works when you ship AI to demanding professionals or in critical industries).

First article this week: “The Vertebrate Agent: Why AI Agents Need a Spine, Not a Bigger Brain.

If you build AI products for enterprise, work in consulting or finance, or think about the gap between AI demos and AI in production: this is for you.