Spec-as-contract tools share one architectural choice: intent is a compiled spec. The spec is rigorous, machine-executable, and feeds an agent. The agent builds. The cycle closes when the code matches the spec.
This is a defensible engineering choice — and inside engineering, it works. Tessl's Usage Specs give experienced devs rigorous control over agent output at the implementation level. OpenSpec is a clean markdown format gaining adoption via training programs. GitHub spec-kit and BMAD-METHOD give engineering teams a structured methodology for AI-assisted coding. These tools solve a real problem: how do you get reliable code out of an AI agent? Their answer — a contract — works for the audience they serve.
But "intent" isn't only a developer-workflow primitive. The most expensive product mistakes don't come from agents writing incorrect code. They come from teams building the wrong thing, correctly. The decision about what to build, who to build it for, and how to know it worked is a judgment — made under uncertainty, with evidence that's partial and competing. That judgment lives upstream of the spec. Spec-as-contract tools assume it's already settled before they enter the picture.
The pattern is visible across the category. Augment Code launched "Intent Workstation" in April 2026 as a flagship product — a workspace for compiling intent into developer-actionable specs. Five weeks later they pivoted to "Cosmos" and archived the Intent Workstation page. The thesis didn't survive contact with real teams: intent isn't a workflow modifier inside a developer tool. It's a judgment layer that sits one level higher.
Pathmode's frame is the inverse. Intent is judgment under evidence, not a contract you compile. The IntentSpec in Pathmode has structured sections — objective, user goal, outcomes, edge cases, constraints, verification — but each one is anchored to the evidence that justified it. A quote from a support ticket. A metric from session analytics. An observation from user research. A requirement isn't a line in a contract; it's a claim about reality, backed by something a builder pointed at and said "this is why we need this."
The audience flips too. Spec-as-contract tools serve engineers writing markdown. Pathmode serves builders making products with AI — PMs, designers, founders, engineers, product ops, anyone whose job is turning evidence into product change. The spec authoring surface is conversational, not technical. The AI's job is to compile the team's evidence into structured intent, not to give engineers another markdown format to learn.
And the loop is closed, not one-way. Spec-as-contract tools end when the agent's code matches the contract. Pathmode keeps reconciling: when code ships, it gets checked against the intent. If a constraint stops being enforced, if an outcome silently regresses, if a requirement gets dropped — Pathmode flags it. The spec doesn't stop being live the moment it compiles.
The two layers fit together for teams that want both. Pathmode produces evidence-anchored intent; spec-as-contract tools translate it into implementation contracts. Tessl, OpenSpec, AGENTS.md, .cursorrules — Pathmode can export to any of them as downstream consumers. The point isn't that compiled specs are wrong. It's that they're downstream. The judgment behind them is what Pathmode owns.