AI

The Knowledge Equation

Everyone will learn to orchestrate AI agents. The differentiator isn't the workflow — it's what you feed into it.

The Knowledge Equation — AI

In The Architect's Protocol, I laid out the full AI-native workflow: ingestion, specification, feedback loops, a growing knowledge base. In Spec-Driven Agentic Development, we went deeper into how to write specifications that actually work. In Eval-Driven Development, we talked about measuring output quality.

All of that is one variable in an equation.

There's another variable. And without it, everything else is noise.

Two Variables, One Equation

Every AI-native outcome is shaped by two forces. The first is orchestration — the skill of working with AI agents. How you write specs. How you structure feedback loops. How you manage the workflow from ingestion to output. How you evaluate results.

The second is domain knowledge — the deep, hard-won understanding of the problem you're solving. The business logic. The edge cases. The real-world constraints that no documentation fully captures.

Multiply them together and you get the value of your output. Zero on either side and the whole thing collapses.

Variable One: Orchestration

This is the how. How to work with agents. How to structure a development session. How to grow a knowledge base that makes every subsequent session smarter than the last.

It includes:

This is learnable. This is a skill. Patterns are emerging, tools are maturing, and the knowledge is spreading fast. Within a year or two, every competent engineer will have it. As I wrote in The AI-Native Litmus Test, the gap between AI-native and AI-adjacent is closing — but only on this axis.

Variable Two: Domain Knowledge

This is the what. What you feed into the system. What context you provide. What expertise sits behind every prompt, every spec, every evaluation.

Domain knowledge is messy. It flows in from everywhere:

  • Documents — requirements, design docs, architecture decisions that shaped the system
  • Meetings — the things stakeholders say that never make it into writing
  • Slack threads — the real decisions, buried in informal conversations that disappear after a week
  • Customer feedback — what users actually struggle with, not what the roadmap assumes
  • Production data — how the system really behaves under load, at scale, at 3 AM
  • Institutional memory — why the codebase has that weird pattern in the payment module that nobody dares touch

When you ingest all of this into your knowledge base — your CLAUDE.md, your context files, your growing corpus of project intelligence — you're not just adding text. You're adding understanding.

But here's the thing: if that understanding is shallow, your output will be shallow too. Quality of input dictates quality of output. Always has. Always will.

The Mess

Let's be honest about what happens in practice.

You're ingesting information from ten different sources. Some of it is structured. Most of it isn't. Documents contradict each other. Slack threads where the decision changed three times. Meeting notes that capture a fraction of what was actually discussed. Half-finished specs. Outdated wikis. Tribal knowledge trapped in people's heads.

This is the real work. Not prompting. Not configuring agents. Making sense of the mess.

An AI orchestrator who doesn't understand the domain will produce output that looks right but isn't. It'll pass a surface-level review. It might even pass tests. But it won't solve the actual problem — because the actual problem requires knowing things that aren't written down anywhere.

I explored this idea in The Verification Gap — the distance between "AI produced output" and "the output is actually correct" is exactly the distance of your domain expertise. Without it, you can't even tell if the result is good.

Why Orchestration Becomes Table Stakes

Here's my prediction: within two years, AI orchestration will be a baseline skill.

Everyone will know how to:

  • Write effective specifications
  • Set up and manage agent workflows
  • Use feedback loops to iterate
  • Build and maintain a knowledge base
  • Evaluate AI output critically

This isn't a controversial take. The tools are getting better every month. I wrote about this trajectory in From AI Skeptic to AI Architect — the path from "this is a toy" to "this is how I work" is shorter than most people think.

When everyone has the same orchestration skills, what separates them?

Domain knowledge.

The Hard Part

Domain knowledge is hard because it can't be shortcutted.

You can't read a blog post about fintech and understand how payment reconciliation actually works when three different payment providers have three different settlement timelines and your operations team has built manual workarounds that nobody documented.

You can't attend a workshop on healthcare and understand why the clinical team insists on a specific workflow that seems redundant until you realize it's driven by a regulatory requirement that changed six months ago.

You can't watch a tutorial about gaming infrastructure and understand why the matchmaking system needs to account for latency distributions that vary by region and time of day in ways that only become visible after months of analyzing production telemetry.

This knowledge lives in people. In their experience. In their failures. In the thousand small decisions they've made over years of working in the same domain. It's the kind of knowledge that, when injected into an AI workflow, transforms output from "technically correct" to "actually solves the problem."

The Equation

Here it is, plain:

Orchestration × Domain Knowledge = Output Value

If you have orchestration but no domain knowledge, you'll produce generic, surface-level work. Fast, yes. Polished, maybe. But not deeply valuable.

If you have domain knowledge but no orchestration, you'll work at human speed. You'll solve the right problems, but slowly. And you'll be outpaced by someone who has both.

The winning combination — for a person, a team, or a company — is both.

This is why the most valuable people in the coming years won't be "AI experts" or "prompt engineers." They'll be domain experts who have mastered AI orchestration. Or AI-native engineers who have deliberately invested in deep domain knowledge. As I argued in Human Language Is the Best Programming Language, the ability to articulate what you know with precision is becoming the most valuable technical skill.

What This Means in Practice

If you're an engineer, don't just learn the AI workflow. Learn the business. Sit in on customer calls. Read support tickets. Understand why the product decisions were made, not just what they were. The deeper your understanding of the domain, the better your AI-assisted output will be.

If you're a domain expert, don't dismiss the AI workflow. Learn how to translate your knowledge into structured context. Learn how to write specs that capture what you know. The orchestration layer is the multiplier for everything in your head.

If you're building a team, don't just hire AI-native engineers. Pair them with domain experts. Or better yet, find the rare people who are both. KISS Your AI Workflow doesn't mean keep your knowledge simple — it means keep your process simple, so you can focus on the quality and depth of what goes in.

The Real Moat

Everyone talks about AI moats. Proprietary models. Custom fine-tuning. Unique datasets.

For most teams, the real moat is simpler: do you deeply understand the problem you're solving?

Because if you do, and you can translate that understanding into structured context that an AI agent can work with, you'll produce work that no amount of orchestration skill alone can match.

Knowledge is the bottleneck. Knowledge is the differentiator. Knowledge is the moat.

In the age of AI, domain knowledge isn't less valuable. It's more valuable than ever.

Read more