What is the Intent Layer?
The Intent Layer is the system layer that sits between two sides of modern software development:
On one side: signal tools — Intercom, Dovetail, analytics platforms, user research — everything that tells you what users need.
On the other side: execution tools — Claude Code, Cursor, GitHub Copilot, CI/CD pipelines — everything that turns instructions into working software.
The Intent Layer bridges the gap. It takes raw friction signals, structures them into specifications, and pushes that context to every agent and team member downstream. It's the infrastructure that makes intent engineering systematic rather than ad hoc.
Why the gap matters
Without an Intent Layer, the translation from "what users need" to "what gets built" happens informally — in a PM's head, in a Slack thread, in a Jira ticket that captures 30% of the actual requirements.
This worked when human engineers were on both sides of the handoff. Engineers compensate for missing context with experience and the ability to ask questions.
AI coding agents don't compensate. They assume. And assumptions compound: a missing constraint produces a wrong architectural choice, which produces code that passes every test while solving the wrong problem.
The Intent Layer makes the translation explicit, structured, and machine-readable.
What it contains
The Intent Layer isn't a single tool — it's a function that any tool can serve. It handles three things:
1. Signal capture. Collecting friction signals from multiple sources: support tickets, analytics, user research, feature requests. Every signal arrives unreviewed and keeps its provenance until a person judges it.
2. Spec generation. Translating those problem statements into structured specifications — IntentSpecs — with explicit objectives, outcomes, constraints, edge cases, and verification criteria.
3. Context distribution. Pushing the resulting specs to wherever execution happens — as MCP context for Claude Code, as .cursorrules for Cursor, as documentation for human engineers, as acceptance criteria for QA.
The handoff problem it solves
In traditional product development, context degrades at every handoff:
Customer tells Support → Support files a ticket → PM reads the ticket → PM writes a spec → Engineer reads the spec → Engineer writes code.
Each step is a lossy compression. By the time the code is written, the original user problem has been translated four times. Critical nuance is lost.
The Intent Layer compresses this chain. Friction signals feed directly into structured specs. Specs feed directly into agents. The context travels intact from the user's problem to the code that solves it.
How Pathmode implements it
Pathmode is built as an Intent Layer. Evidence captures friction signals and records who reviewed each one. The spec editor structures the problem into IntentSpecs whose claims state what backs them. The MCP server distributes those specs to AI coding agents.
The result: a closed loop from user friction to shipped software, with structured intent at every step.