The Intent Layer

Updated August 2026. The original version of this post described the Intent Layer as a system that computes intent centrally and pushes context downstream. Eight months of building it taught us the layer is a file. The argument for the layer stands; the architecture below is the corrected one.

The software stack has a gap.

On one end: tools that capture signal. Dovetail, Intercom, user research platforms, everything that tells you what users need. On the other end: tools that execute. Cursor, v0, Claude Code, everything that turns instructions into working software.

The middle is compressing. And that middle is where the most important work happens: deciding what gets built and why.

Most teams skip it. They go straight from customer feedback to a prompt in Cursor. The result: code that solves the wrong problem, or solves it without context.

We call this missing middle the Intent Layer.

Prompts Are Not Intent

A prompt is a request. Intent is a specification.

When a developer opens their editor, they should not be inventing context from scratch. The context should already be in the repository they have open: a file that says what needs to be built, why, and how everyone will know it worked.

Prompts can generate code. Intent specs give an agent a stable basis for building the right thing, asking better questions, and checking what it changed.

Why the Gap Exists

Today, intent is scattered across your organization:

• Research lives in Dovetail.
• Specs live in Notion or Google Docs.
• Tasks live in Jira or Linear.
• Context lives in someone's head.

Each of those is a place the work is not. The agent implementing the change reads none of them at the moment it starts writing code, so every handoff between the tools introduces drift, and every interpretation introduces error.

The original version of this post said the fix was a layer that sits above these tools, synthesizing signal and pushing context to every downstream agent. That was wrong in a way that matters. A layer above the stack is one more place the work is not: one more destination to keep in sync, one more tab nobody has open when the agent starts.

The fix is a layer that travels with the work.

The Three Layers, Corrected

1. An open format

An IntentSpec is a structure for a decision: objective, outcomes, evidence, constraints, scope, edge cases, health metrics, verification. It renders as intent.md, plain markdown, committed to the repository next to the code it governs.

---
id: checkout-payment-timeout
status: approved
scope:
  inScope:
    - Payment processing status and recovery
  outOfScope:
    - Cart, catalog, and payment-provider migration
evidence:
  - id: checkout-funnel
    type: metric
    source: "Checkout funnel dashboard"
    excerpt: "23% of checkout sessions abandon at the payment step."
    anchors:
      - objective
      - outcome:2
---
# Reduce payment-step abandonment

## Objective
Shoppers abandon checkout when payment processing exceeds three seconds
without feedback, costing completed orders and creating duplicate retries.

## Outcomes
- Shoppers see processing status until the provider returns a result
- Failed payments show an actionable retry without losing the cart
- Payment-step abandonment falls from 23% to below 15%

## Constraints
- A retry must never create a second charge
- The existing payment provider must remain in place

## Edge Cases
- **Network timeout during payment**: Show retry only after confirming no charge completed
- **Session expires during payment**: Preserve the cart and return the shopper to checkout

## Verification
- Automated check: timeout and retry tests pass without duplicate charges
- Shipped signal: payment-step abandonment remains below 15% for two weeks

This is more than free-form prose, and it is not a contract you compile. It is a record of judgment under evidence: precise enough for an agent to plan and check work against, clear enough for a human to review, and open to amendment when the build proves part of it wrong. The format is open and the file is useful with no account, because a format you can only read through one vendor is a lock-in scheme wearing a standards costume.

2. A workflow in the agent's loop

A file nothing reads is documentation. The layer only exists if the file participates in the work:

• Drafted in conversation, increasingly by the agent itself. In our own workspaces, agents already author specs through the API; the human turn has moved from writing to judging.
• Preflighted before implementation. A deterministic check names what is missing (a vague objective, an unmeasurable outcome, no edge case with defined behavior) before an agent spends hours building against the gap.
• Read where the work happens. The agent starts a session in the repository, and the intent is already there.
• Written back to. What the build reveals, a contradicted assumption or a decision made under pressure, lands in the record instead of evaporating with the session.
• Checked at the end. The implementation artifact is compared with the agreed outcomes and constraints, not with whatever the last prompt happened to say. That establishes implementation fidelity; it does not prove the user outcome happened in production.
• Measured after shipping. Production signals test whether the observable outcome actually happened. The result is recorded as a measurement for human judgment, not silently promoted into evidence for the next decision.

And one gate holds the whole thing accountable: an agent-authored spec is a proposal until a person authorizes it. That is what keeps "the agent wrote the spec" from quietly becoming "nobody decided this."

3. A narrow service for what a file cannot do

Two things genuinely cannot live in a repository.

The evidence. Interviews, support conversations, named quotes, sensitive metrics: the material a claim rests on does not belong in a tree that contractors, forks, and every agent can read. The file carries a reference; the source lives outside it.

The people. The ones who know whether a claim is true often never open a repository. They need a way to see the spec and respond to it without an account and without git.

That is the whole hosted product, and the boundary in one sentence: the repo gets the decision, Pathmode keeps the evidence and judgment behind it.

Why This Matters Now

AI has made execution cheap. You can prototype a working solution in the time it used to take to argue about the wireframe. This is powerful, but it creates a dangerous illusion.

When building is instant, teams skip the hard work of defining what they're building. Fast execution masks poor intent. A shiny AI-generated feature ships in a day, only to increase drop-off because no one asked whether users actually needed it.

This is what we've been calling The Vibe Coding Hangover. Solo developers can hold context in their head. Add a PM, a Designer, and three AI agents, and context fragments. Prompts become requests with no shared definition of success.

The bottleneck has shifted. It's no longer writing code. It's defining what code to write.

The PM's Role is Changing

The PM's job used to be translation: talk to customers, synthesize problems, write specs, hand them to engineers. The value was in the compression, taking noisy, qualitative input and producing structured output.

But that compression step is exactly what language models do well. When agents can take a well-formed problem and produce working code, the spec becomes the product. The PM's job shifts from writing handoff documents to judging what the agents propose: challenging the draft, confirming what is actually known, refusing what is not.

This is not a demotion. Clarity is harder than verbosity. Judgment is harder than prose.

What an Intent Layer Does

1. Captures friction from real user signals, and keeps the raw material out of the repository. The spec cites evidence; it does not embed a customer's name in your git history.
2. Structures intent into a versioned, machine-readable spec with explicit success criteria, constraints, and edge cases, in a file that merges like everything else.
3. Meets agents where they already read. At implementation time there is no separate fetch or second tab: the repository is the distribution channel.
4. Checks implementation fidelity against the defined spec. Does the diff satisfy the outcomes and respect the constraints it actually touches?
5. Measures outcomes after shipping. Did the friction actually decrease? The measurement informs later judgment; it does not become evidence for another decision without someone making that call.
6. Preserves memory in the repository's own history, so the team knows why something was built, and what building it revealed rides forward to the next session instead of dying with this one.

Who Owns Intent?

John Moriarty wrote about the shift from products to systems. His framework for the new design role is "Systemic Orchestration": designers provide the bricks, blueprints, and building codes, not the finished house.

This applies to product work broadly. Designers, PMs, and engineers are all converging on the same discipline: defining intent with enough structure that agents can make implementation choices without inventing the product decision.

Someone has to own that layer. Our answer changed while building it: the team owns it, in their repository, in a file that is theirs with or without us. What we build is the open format, the workflow that keeps the file alive inside the agent's loop, and the narrow service that holds what a file cannot.