A few months ago, I was asked to look at something a team had built with AI. It was a financial analysis system, a set of prompts designed to evaluate potential acquisition targets. The team had spent weeks on it. They were proud of it.
The output looked impressive. Clean formatting, professional language, all the right sections. Executive summary, risk assessment, financial projections, strategic fit analysis. If you glanced at it, you'd think a senior analyst had written it.
But if you were to read it carefully, the way a CFO would read it before committing capital, the problems were hard to miss.
The risk assessment flagged generic risks that could apply to any company in any industry. The financial projections extrapolated trends without questioning whether those trends were sustainable. The strategic fit analysis used the phrase "strong synergies" without specifying a single one. And nowhere in the entire output did the system say "I don't have enough information to evaluate this" - even in places where it clearly didn't.
The team's conclusion was that they needed a better model. They'd been using GPT-4, so they switched to GPT-5. That helped a little. Then they tried Claude, and again, minor improvements. But they still weren't satisfied. The prompts were good. The output looked good. Something was still missing, though, especially around edge cases.
And so, after spending some time reviewing and testing their prompts, I eventually realized what the underlying problem was: They had designed prompts that described what the AI should do, but not how it should think.
The Gap
The prompts that the team had created told the AI what to produce. For example, one prompt told the AI to create a financial analysis with these sections, in this format, at this length. And it did that very, very well.
What it didn't tell the AI was how a senior analyst really thinks through an acquisition. Where to be skeptical. What to double-check. When to say "this data isn't sufficient to draw a conclusion." Which risks are worth worrying about, and which ones are only there because the template has a risk section.
The AI did exactly what it was asked to do. It produced a document that looked like a financial analysis. But looking like an analysis and being one are different things. And when you're making an important business decision, that difference matters.
That's the gap I saw in this team's work. And once I started looking for it, I realized that I could find it in some of my own prompts, too. I also realized that no matter how much AI models continue to improve, they're unlikely to fix this on their own, especially considering that it's a problem that I think most people don't even know they have.
Introducing Cognitive Systems Design
I've started calling this work Cognitive Systems Design, and the simplest way I can describe it is this: it's the practice of architecting how AI thinks. You're designing the reasoning structures, priority hierarchies, judgment frameworks, and behavioral constraints that enable an AI to advise, decide, and act the way a human expert would.
The word "cognitive" matters. This is about making expert thinking replicable. You're encoding how experienced professionals reason through ambiguous, high-stakes problems into systems that can do it consistently.
The word "systems" matters too. A system holds its shape across thousands of interactions. That's one of the things that separates it from even the best prompt.
"Design" is perhaps the most important word. That's because design is the hard part. You have to be able to determine how an expert thinks, make that thinking visible, transferable, executable, and repeatable. And only then can you encode that into a prompt.
CSD Is More Than Prompt Engineering
Prompt engineering is tactical. The goal is to give the AI better instructions, so that it generates better outputs. And it's usually intended to do so in a single interaction, rather than performing as part of a longer conversation. CSD operates at a different level, architecting complete cognitive systems that maintain expert-level performance indefinitely.
That said, prompt engineering is part of the CSD process. The system you design still has to be expressed as a prompt. But the prompt is the last step. The thinking that determines what goes into it is where most of the work happens.
CSD produces something that most prompts don't even attempt: a functioning intelligence that thinks, decides, and advises. The output itself thinks. And that's what makes this a distinct discipline. And as CSD starts being applied to autonomous agents, I think that the implications will get even more interesting.
What Goes Into a Cognitive System
Let me walk through two of the components that I think clarify the difference between CSD and prompt engineering.
The first is what I call an Anti-Pattern Library. This is an explicit catalog of how outputs go wrong in a specific domain. The failure modes, the shortcuts, the hallucination patterns, the cliches. And then structural rules that prevent them.
Going back to that financial analysis example: a senior analyst knows that when revenue is growing but margins are shrinking, the growth story might be hiding a cost structure problem. They know that "strong cultural fit" in an acquisition memo usually means "we haven't looked at this closely," and that projecting three years of compound growth from two quarters of data is how bad deals get justified.
An AI doesn't know any of that unless you encode it. An anti-pattern library for financial analysis would contain exactly these kinds of failure modes, named and described, with specific structural rules that prevent the system from making those mistakes. Each one represents a lesson that an experienced analyst learned the hard way over years of practice, made explicit and enforceable.
The second component is what I call an Epistemological Framework - which is a fancy way of saying the system knows what it knows and what it doesn't. A well-designed cognitive system has explicit confidence levels. When it's working with solid data, it says so and proceeds. When the data is incomplete or ambiguous, it flags the gap, tells you what would resolve the uncertainty, and refuses to dress a guess up as analysis.
The prompts in that financial analysis tool that I reviewed never once specified what to do in cases where it didn't have enough information. It should have. In at least four places. And it's that honesty that makes output trustworthy rather than just plausible.
Looking Ahead
I think that the organizations that will see real, immediate benefits from AI will be those that figure out how to encode their expertise into systems that reason at a professional level. They'll have access to virtual professionals at a fraction of the cost of human experts. And for smaller organizations, this will open up a level of expertise that was previously out of reach.
The models are going to keep getting more capable, and my experience so far is that more capable models benefit more from well-designed cognitive architecture. CSD becomes more valuable with each model generation.
And the discipline itself compounds. Every system I build teaches me something that makes the next one better. The anti-pattern libraries get deeper, the cognitive moves catalog grows, and the methodology for extracting expertise from a domain gets faster and more reliable. Organizations that invest in this kind of work early will build an advantage that's difficult to replicate later.
That's what Cognitive Systems Design is about. The underlying discipline is designing how AI thinks.
I've published a longer treatment of Cognitive Systems Design — its intellectual foundations, all six components of a cognitive system, and the full framework. If you want the complete picture, that's where to find it.