Let your agent pull intent live with the Pathmode MCP server

Copy-paste handoff works once. The spec keeps moving: a constraint lands in review, an edge case gets sharpened, a PM asks for one outcome to change. By the time the agent runs, the pasted prompt describes a spec nobody holds anymore. With the MCP server connected to a workspace, the agent reads the intent at the moment it runs, sees the judgment a person attached to that exact revision, and hands its pull request back to the same record.

This is the connected-workspace flow. For the keyless version, where the spec lives in intent.md and nothing leaves your machine, start with Draft your first intent in your repo and Run a preflight before your agent builds. Every tool below that reads the constitution, handles PM requests, or grades a pull request needs a workspace API key.

The input

A repo whose intent.md syncs to your Pathmode workspace, and a workspace API key for the agent. The file stays the repository's authority for what to build. The workspace holds what a file cannot: evidence, the constitution, open PM requests, and who authorized which revision.

The flow

1. Install once, connect once. In Claude Code:

/plugin marketplace add pathmodeio/claude-plugin
/plugin install pathmode@pathmode

Enter the workspace API key when the plugin prompts for it; it lands in your OS keychain, not in a config file. In Cursor, Codex, or any other MCP client, run npx @pathmode/mcp-server with the key in PATHMODE_API_KEY.

2. Preflight before anything else. The agent's first call is check_intent_readiness. It resolves the intent.md bound to the repository the client is working in, and when it cannot identify the repository it refuses to guess. Six deterministic gates, no model call, the same spec always gets the same verdict. A failing verdict names the exact blockers. The agent repairs them one question at a time, or you accept the named risk explicitly and that acceptance is recorded in the spec as a decision. Readiness is a property of the spec, not permission to build.

3. Read the full context, not a blob. With a passing verdict, get_agent_prompt returns the execution prompt for that intent: objective, outcomes, constraints, edge cases, verification checks, the constitution rules, and the evidence the spec cites, grouped by whether a person has reviewed it. At the top of the prompt, before any instruction, sits the state that decides whether the agent may proceed at all.

4. Stop for judgment. Two things can be waiting there. Open PM change requests: a person asked for a specific change to a specific revision of the spec. The agent applies each one to intent.md deliberately, or rejects it with a concrete reason; it never builds around one. And the authorization itself: a spec the agent drafted stays pending until a signed-in person authorizes that exact revision, and a material edit to the body, including applying a PM request or recording accepted blockers, clears the authorization and asks for it again. The agent cannot clear this gate; the authorization endpoint refuses API keys by design. A passing preflight does not substitute for it, and accepting blockers does not bypass it.

5. Implement and hand back. Inside the authorized scope, the agent builds, runs the spec's verification checks, and names the intent where the merge can find it: branch intent/<id>, or pathmode:<id> in the pull request body. If building reveals the spec was wrong, propose_spec_change records a correction for a person to accept; the agent keeps building against the authorized revision until they do.

6. Let the diff be graded. verify_implementation with the pull request URL makes Pathmode read the diff from GitHub and grade every outcome, constraint, constitution rule, and edge case against what the code shows, with citations into the diff. An advisory review also runs as the pull request opens and changes, so drift shows before the merge. On merge, the same grader moves the intent to shipped and records what the verdict rested on. The agent does not flip the status itself when a PR is involved; an intent marked shipped by hand is one the merge has less to say about.

The output

• A run that starts from the spec as it stands: the agent reads at run time, after the last edit, instead of from a copy
• A build that waited for a person: the revision the agent built against is the one a human authorized, and the record shows it
• Rules in context every run: the constitution travels with the prompt instead of living in someone's memory, and the grader checks the diff against it
• A closed loop: PM requests, corrections, the graded verdict, and the implementation note land on the same record the next reviewer opens
• Scoped access: the agent sees the workspace its key is authorized for, and it can read the gate but never open it

Why this beats pasting the spec

A pasted spec is a photograph. The MCP connection is a window. The difference shows up the moment the spec changes between hand-off and execution, which on any spec worth reviewing it always does. Revision-bound authorization is what gives the window substance: the agent sees more than the current spec, it sees whether a person has stood behind this version of it, and it stops when nobody has.

Try it yourself

1. In Claude Code, /plugin marketplace add pathmodeio/claude-plugin, then /plugin install pathmode@pathmode, and enter a workspace API key when prompted
2. Ask the agent to "preflight the repo intent and implement it"
3. Watch it call check_intent_readiness, then get_agent_prompt, and stop if authorization is pending
4. Authorize the revision in Pathmode; the agent builds and opens a PR that names the intent
5. Have it run verify_implementation against the PR, then let the merge do the rest

Related

• Use case: Draft your first intent in your repo, no account required
• Use case: Run a deterministic preflight before your agent starts building
• Use case: Verify the pull request against the spec it was built from
• Playbook: The Anatomy of an Agent-Ready Spec