Not Like You. For You: Why "Cognitive Engineering" Misses the Point

TL;DR: The AI industry keeps inventing new "Engineering" disciplines — Prompt, Context, Harness, Loop, Graph, now Cognitive. Each one solves the same meta-problem: reliable output. But "Cognitive Engineering" promises something it can't deliver yet. The real opportunity isn't making AI think like you. It's making it think for you — better, faster, and with explicit knowledge of its own limits.

James here, CEO of Mercury Technology Solutions. Wanchai, Hong Kong — July 2026

The Naming Treadmill

Every few months, AI Twitter invents a new "Engineering."

Prompt Engineering. Context Engineering. Harness Engineering. Loop Engineering. Graph Engineering. Now Cognitive Engineering.

The names multiply. The conferences sell tickets. The LinkedIn thought leaders update their bios. And somewhere in the middle of it all, actual engineering gets done.

But here's the thing: the progression is real. Each layer does solve the same meta-problem — how to make AI reliably produce what you actually want — with increasing scope and abstraction.

Layer	What It Controls	The Leap
Prompt	Single call	What the model sees
Context	Single call + memory	What the model knows about you
Harness	Single task execution	Tools, state, safety boundaries
Loop	Multi-turn persistence	Correction until done
Graph	Multi-step orchestration	Flow design, branching, parallelism
Cognitive	Decision-making itself	How it thinks, not just what

Each step is genuinely harder than the last. Each requires new abstractions, new failure modes, new observability. The names aren't the problem. The problem is when people treat them as marketing instead of architecture.

The Engineering Paradox: The more layers we name, the more we risk forgetting that the user doesn't care about our abstractions. They care about outcomes.

What "Cognitive Engineering" Actually Means

A recent post framed Cognitive Engineering as the next frontier: "teach AI how to think." Make it understand your thinking patterns, decision frameworks, judgment criteria, priorities. Not just execute — think like you, then execute.

It's a compelling vision. It's also dangerously underspecified.

When someone says "teach AI how to think," they could mean three very different things:

Interpretation	What It Actually Is	Can We Build It?
A: Reflection Patterns	Chain-of-thought prompting + self-correction loops	✅ Today. See Andrew Ng's 4 agentic patterns.
B: Preference Learning	Fine-tune on your decision traces, learn your trade-offs	⚠️ Hard. Requires data infrastructure most companies don't have.
C: Explicit Cognitive Architecture	Belief states, inference rules, uncertainty handling, meta-cognition	❌ Research frontier. Not a product yet.

Most "Cognitive Engineering" demos will be A dressed up as C. They'll show reflection chains and call it "teaching the AI to think." That's not cognitive architecture. That's good prompting with extra steps.

Real cognitive architecture requires something harder:

• Belief states — what the agent holds as true, with explicit confidence

• Inference rules — how it updates beliefs given new evidence

• Decision frameworks — explicit logic for trade-offs (speed vs. accuracy vs. cost)

• Meta-cognition — knowing what it doesn't know, and saying so

That's not engineering. That's building a mind. And we're not there yet.

The Dimension He's Missing

The progression he lays out is vertical — more capability per layer. But there's a horizontal dimension that matters just as much: scope of operation.

Vertical (his frame): Prompt → Context → Harness → Loop → Graph → Cognitive Horizontal (missing): Single → Multi → Persistent → Distributed → Autonomous → Self-improving

The horizontal axis is about how much the system operates without you:

Stage	Scope	Human Involvement
Single call	One prompt, one response	Every word
Multi-turn	Conversation history	Every session
Persistent	Tasks survive across sessions	Periodic review
Distributed	Multiple agents coordinate	Exception handling
Autonomous	Self-directed goal pursuit	Escalation only
Self-improving	Modifies own architecture	None (theoretical)

At Mercury, we operate at Persistent → Distributed. Our cron jobs run overnight. Our sub-agents work in parallel. But a human still reviews the output, still publishes the post, still approves the strategy.

Cognitive Engineering, if it exists, lives at the intersection of both axes: autonomous scope + explicit reasoning architecture. That's not a feature you ship in a sprint. That's a research program.

The Real Question

"你會想要一個能夠『像你一樣思考，再替你執行工作』的AI嗎？"

No. I want an AI that thinks better than me in domains I've explicitly delegated, and knows when to ask in domains I haven't.

"Like me" is a bug, not a feature. I have biases. Blind spots. Days when I'm tired and make bad calls. An AI that replicates my thinking replicates my failures.

The Yang Wen-li quote applies here: "The most effective way to win is to make the enemy lose their will to fight." In this case, the enemy is unreliability. And the way to beat it isn't imitation — it's augmentation.

What I actually want:

• In domains I delegate: Faster, more consistent, less emotional. No fatigue. No ego. No "I already decided this yesterday, let me stick with it."

• In domains I keep: Clear escalation. "I don't have enough context." "This contradicts your stated priority." "You said never to do this without asking."

• In the boundary: Explicit handoffs. "I've done X. Y requires your judgment. Here's what I recommend."

**The real framing:** Not "like you." **For you.**

What Mercury Is Actually Building

We don't need Cognitive Engineering. We need reliable Graph Engineering that clients trust with real business processes.

Here's what that looks like in practice:

Our stack today:

• L1-L3 loops (report → assisted → unattended) for content and analysis

• L4-L5 coordination (persistent tasks, multi-agent) for audits and research

• Context compaction so long sessions don't lose state

• Retry + fallback routing so failures don't cascade

• Observability layer so we know what broke and why

What we're adding next:

• Preference logging — which leads you prioritize, which risks you tolerate

• Decision tracing — not "what did the AI do" but "why did it choose this"

• Explicit uncertainty — confidence scores on recommendations, not just answers

That's not Cognitive Engineering. That's preference learning + explicit trade-off logging. But it delivers 80% of the value with 20% of the complexity. And it's buildable now.

The Opportunity

The first company to productize even a weak form of "cognitive-like" behavior wins the narrative. Not because it's full AGI, but because it shifts the conversation from "automation" to "judgment."

Think about the pitch:

"Our agents don't just execute your workflow. They learn your decision criteria — which leads you prioritize, which risks you tolerate, which shortcuts you accept — and apply them consistently. When they're uncertain, they ask. When you're uncertain, they recommend."

That's not a research paper. That's a product positioning. And it's defensible because the moat isn't the model — it's the accumulated preference data that no competitor has.

The Action

If you're building with AI, stop chasing the next "Engineering" label. Ask three questions instead:

1. What scope does my system operate at? (Single call? Persistent? Distributed?)

2. What happens when it fails? (Silent error? Escalation? Cascade?)

3. How does it know what I value? (Explicit rules? Learned preferences? It doesn't?)

The answers tell you what to build next. Not what to name it.

Because in 2026, the companies that win aren't the ones with the most advanced cognitive architecture. They're the ones whose agents fail gracefully, escalate clearly, and improve continuously.

The rest is just naming.

Mercury Technology Solutions: Accelerate Digitality.

Not Like You. For You: Why 'Cognitive Engineering' Misses the Point