The Knowledge Equation

AI workflow skills and domain knowledge complement each other. Build a curated, authorized knowledge base and verify whether the output solves the actual problem.

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.

Treat the relationship as a heuristic: effective orchestration and relevant domain knowledge can strengthen each other. It is not a measured equation, and neither variable captures every factor that affects an outcome.

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:

Orchestration is a learnable skill. As tools and practices spread, it may become a more common part of engineering work. The rate of adoption and the capabilities needed will vary by team and task.

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

Select the material that the workflow is authorized to process. Review its sensitivity, access permissions and destination before adding it to a knowledge base or model context. Curate the relevant decisions and evidence instead of indiscriminately ingesting internal conversations or production records.

Relevant, accurate input gives the workflow a better basis for the task. It still needs interpretation and verification: a well-documented source can be stale, incomplete or wrong.

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.

Domain expertise helps reveal whether a plausible result answers the actual problem. It works alongside tests, source verification and review; none of these alone closes every gap between generated output and a correct result.

Why Orchestration Becomes Table Stakes

My expectation is that familiarity with AI-assisted workflows will become more common. That is a prediction, not a timetable every engineer or organization will follow.

Useful skills to develop include:

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

Adoption depends on the work, available tools and organizational constraints. Evaluate a workflow by its outcomes rather than treating a particular adoption speed as evidence of competence.

As orchestration practices become more accessible, what else distinguishes useful work?

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.

Domain expertise without an AI workflow can still produce valuable results. The question is whether a particular tool or process helps apply that expertise more effectively on the task at hand.

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

Teams benefit when people can connect domain understanding with an effective, verifiable workflow. Precise explanations help communicate requirements, but they complement other engineering skills rather than replacing them.

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.

Related Reading

  • The Exomind — Build an agent-maintained technical knowledge base with preserved sources, permission-aware retrieval, serialized maintenance and independently configured memory.
  • The Architect's Protocol — A practical architecture for AI-assisted engineering: maintained Markdown knowledge, explicit task context, versioned decisions, and review of generated work.
  • Spec-Driven Agentic Development — A specification-first workflow can reduce requirements-related rework. Review and tests still need to verify both the specification and its implementation.
  • Eval-Driven Development — Define acceptance criteria, use deterministic checks for verifiable properties, and review the checks themselves. Passing tests increases confidence within their coverage; it does not prove every behavior correct.
  • The Verification Gap — AI builds, tests, and deploys your code. But "Claude tested it" is not the same as "I verified it." The most dangerous moment in AI-assisted engineering is when you stop checking.
  • The Context Wall — Diagnose context failures, organize durable technical knowledge and add QMD retrieval using documented commands, explicit access boundaries and observable maintenance.
  • The Knowledge Base That Builds Itself — Use an agent to maintain sourced technical summaries, cross-references and a reviewable wiki. Keep originals, check derived claims and add retrieval when measurements justify it.
  • The Cockpit — A separate workspace can hold personal agent configuration and coordinate several repositories. Keep authoritative team knowledge in approved shared storage and respect each repository’s rules.
  • The Graph Is the Context — Prompt, context, loop — and now graph engineering. Half the label is marketing; the shift under it is real: stop searching a flat pile of documents by similarity, start walking a typed graph of what's connected. ELI5 to the arithmetic that kills it in production.
  • Money Maker — An engineering view of persistent AI workflows: acceptance criteria, independent verification, durable execution and ownership. Lower production costs do not guarantee personal wealth.
  • Your Moat Was Never the Code — AI can reduce the effort of reproducing some software features. A reassessment of competitive advantage through distribution, trust, operating knowledge and production requirements.

Read more