The Next Product Discipline Isn't Context Engineering. It's Intent Engineering.

Everyone is talking about context engineering.

How to structure your prompts. How to pack the right documents into the context window. How to wire up RAG pipelines, tool schemas, memory systems, and system instructions so the model performs reliably.

This matters. Context quality directly affects AI output quality. No argument there.

But most teams don't have a context problem first. They have an intent problem.

They are optimizing how they brief the machine before they have figured out what they are asking it to do. Better context just helps the AI fail more efficiently.

Context isn't judgment. You can package a decision perfectly and still be packaging the wrong one.

Intent Engineering vs Context Engineering: Two Disciplines, One Stack

The difference in one line: context engineering structures how an AI receives a task; intent engineering defines what the task is and how you'll know it worked.

Context engineering is the practice of structuring prompts, retrieval, memory, tools, and system instructions so an AI can perform a task reliably. It answers: how do we package information so the model interprets it correctly?

Intent engineering is the practice of defining the objective, outcomes, constraints, edge cases, and verification criteria — each grounded in evidence — so a team or an agent solves the right problem. It answers: what exactly are we asking the system to accomplish, and how will we know it worked? A PRD asserts what to build. An intent spec ties each decision to the evidence behind it — so when the evidence changes, the spec is wrong on purpose, not by accident. Intent is judgment under evidence, not a contract you compile.

Context engineering improves transmission. Intent engineering defines direction.

These are not competing ideas. They are layers in a stack. Intent is upstream. Context is downstream. You define what success looks like, then you engineer how to communicate that to the system.

The order matters. Reverse it, and you get teams with pristine RAG pipelines delivering features nobody asked for.

The Judgment Problem

Context engineering became popular because AI exposed a communication problem. Models are powerful but literal. They need the right information in the right format at the right time. Engineers who figured this out got dramatically better outputs.

Intent engineering matters more because AI exposed a judgment problem.

When a human developer receives a vague ticket, they compensate. They walk over to the PM's desk, check Slack, read between the lines, make reasonable assumptions. AI agents don't compensate. They execute. Give an agent an ambiguous objective and it will confidently build exactly the wrong thing — with excellent code quality.

What's new isn't the ambiguity. Vague tickets always produced bad work. What's new is that an agent resolves the ambiguity instantly, at scale, in code that passes review, with total confidence. A human's hesitation was a bug report. The agent's certainty is a shipped feature.

The bottleneck isn't how the model receives information. It's whether the team has decided — clearly, structurally, verifiably — what problem they are solving, what success looks like, and what must not break.

No amount of retrieval-augmented generation fixes a team that hasn't made those decisions.

Why This Lands on Whoever Owns the Spec

If you build products with AI — whether you write the spec or write the code — you've felt this even if you haven't named it:

• Vague tickets that generate technically correct but product-wrong code — the reason Jira tickets fail AI agents
• "Improve the checkout flow" tasks where the agent optimizes the wrong thing
• Happy-path implementations that miss constraints, edge cases, and integration points
• Pull requests that pass every test and still generate support tickets

These often look like context failures — missing architecture docs, omitted constraints in retrieval, incomplete system prompts. But the deeper failure is usually intent. The instruction itself was incomplete. No amount of better packaging fixes a specification that never defined success.

A stronger context window cannot rescue a weak product brief.

This is also why the artifact itself is changing. Teams used to write documents optimized for human interpretation — PRDs, one-pagers, Notion docs — whose purpose was to create shared understanding through narrative. The document was a starting point for conversation. Ambiguity was acceptable because humans would resolve it through discussion, whiteboarding, and iteration.

Agents don't do any of that. An agent reads the spec, interprets it literally, and executes. There is no hallway conversation. There is no "I assumed you meant..." follow-up.

The difference is visible in the artifacts themselves:

PRD-style: "Improve onboarding completion rates."

Intent-style: "Reduce drop-off at address entry without increasing fraud-review failures. Completion counts at the identity-verified state, not form submission — and the target traces to the friction we logged there."

The first is a direction. The second is a specification an agent — or a team — can execute against and verify. It names the metric, the constraint, the boundary, and the evidence behind it.

This isn't a PM skill or a developer tool. Whoever holds the evidence for what the product should do, and the authority to decide what "done" means, owns the intent. On most teams that's shared — and that's the point: the spec is the one place both have to agree before the agent runs.

When you have a structured intent spec — objective, success criteria, constraints, edge cases, verification steps, each anchored to evidence — the agent doesn't just code better.

It decides better.

It knows why the feature exists, what counts as done, and where the boundaries are. That's fundamentally different from having more documents in the context window. Traditional specs describe what to build. Intent specs define what success looks like — while deliberately leaving the implementation open. The difference is the difference between a blueprint and a mission brief.

The Verification Gap

This is the sharpest distinction between the two disciplines.

Context engineering alone does not define product correctness. You can add evals, test harnesses, and structured output validation — and those help — but they verify that the model followed instructions well. They don't verify that the instructions were worth following. Without upstream intent, you're testing execution quality, not product quality.

Intent engineering bakes verification into the process. Because you defined outcomes, constraints, and edge cases upfront — and tied them to evidence — you have something to check against. Did the feature meet the success criteria? Did it respect the constraints? Did it handle the specified edge cases? Did it actually move the thing the evidence said was broken?

Without intent, "did the AI do the right thing?" has no structured answer. You're left eyeballing outputs and hoping. That works for a solo developer on a weekend project. It does not work for a product team shipping to customers.

The Trap

Here's the failure mode to watch for.

A team adopts better context engineering. Prompts are cleaner, retrieval is sharper, tool use is well-structured. Outputs improve immediately. Everything looks better. Everyone feels more productive.

But the team never clarified what problem they were solving, who it was for, or how they'd know it worked.

They are now building the wrong thing faster, with more confidence, and with better-formatted code. The AI didn't fail. The specification was never written.

This is the danger of optimizing the downstream layer first. Better execution creates false confidence. The outputs look polished, so the team assumes the direction is right.

Intent has its own trap, and it's only fair to name it. Specifying success up front feels slow and produces nothing you can demo. Write it as a frozen contract and you've just built a slower waterfall. The discipline isn't writing everything down — it's keeping the spec to the slice that compiles into action, and to the evidence that earns it.

Intent First, Context Second

For teams building with AI, the stack looks like this:

First, engineer intent. Define the problem, the outcomes, the constraints, the edge cases, and the verification criteria — grounded in evidence. Get alignment on what success looks like before a single line of code is generated.

Then, engineer context. Structure how that intent reaches the AI — through system prompts, retrieved documents, tool schemas, memory, or whatever your stack requires.

Then execute. Let the agent build.

Then verify against intent. Not against whether the output "looks good." Against the success criteria you defined in step one.

Context engineering is not overhyped. It's essential infrastructure — the same way database optimization and API design are essential, skilled work that every team needs. But it is downstream of intent. It is the implementation layer, not the judgment layer.

You're not wrong to care about context. You're just starting one layer too low.

This is the same pattern that plays out at runtime: curated context still rots when the intent underneath it was never settled. That rot starts upstream.

In the AI era, the scarce skill is no longer producing software. It is specifying what software should accomplish — clearly enough that autonomous systems can build it without guesswork.

That specification discipline has a name. It's intent engineering — and Pathmode is the product judgment layer where it becomes executable: scattered evidence compiled into agent-ready intent, then followed through to shipped code.

The operational shift is straightforward. Product reviews start with outcomes and constraints, not feature descriptions. Agent workflows are evaluated against defined success criteria, not output quality. And the question "is this done?" has a structured answer — traceable to the evidence behind it — before the first line of code is written.

Engineer the context all you want. It still can't make the decision you skipped.

Context isn't judgment — and judgment is the artifact you're actually building.

Start with the method: how to run an Evidence Board.