Klyr for Cursor and Claude Code: the memory your agent forgets

Cursor and Claude Code are excellent at reasoning over the evidence in front of them. The problem is what happens after the context window clears. The agent that read your churn interviews on Monday has no idea on Friday why you prioritized the export feature, which customer quote justified it, or what you shipped last quarter and whether it worked. Every session starts cold.

That gap is expensive in two directions. The agent builds against guesses instead of the evidence that justified the work, and the reasoning behind a decision evaporates the moment the session ends, so it cannot inform the next bet. Klyr is built around the loop that fixes this: evidence becomes a ranked Feature Bet, the bet becomes a Build Pack your agent executes, and the shipped outcome is written back into Product Memory: a durable evidence-to-outcome graph that survives across projects and quarters.

Citations themselves are not the moat. NotebookLM, your coding agent, and Klyr all link claims to sources. Klyr puts a floor under it (a theme needs at least two verified source quotes or it auto-drops) and then keeps the whole chain: which quote, which bet, which Build Pack, what shipped, what happened. That is the memory your agent loses every time the window clears.

A Build Pack is the handoff artifact Klyr generates from a ranked Feature Bet. It is designed to be read by a coding agent, not just a human, so the agent builds the right thing against the evidence that justified it.

Every Build Pack carries the full chain from problem to code, and the underlying Feature Bet keeps the counter-evidence and risks alongside the case for building, so the agent sees both sides, not just the pitch.

The fastest path is copy-ready and works today, with no setup. Open the Build Pack in Klyr, copy the handoff markdown, and paste it into Cursor or Claude Code as your task brief. Because the prompt and acceptance criteria are already structured for an agent, you go straight from paste to a working pass at the change, with the customer evidence sitting right next to the instructions.

A typical loop looks like this: pick the top-ranked Feature Bet, generate its Build Pack, copy the handoff, paste it into your agent, let it scaffold against the suggested files and test plan, then check the result against the acceptance criteria the pack listed. When the work ships, you record the outcome back in Klyr so Product Memory remembers what that bet actually produced.

To reproduce the full flow end to end before you commit anything, the proof page walks a real run from evidence to bet to Build Pack, and the docs cover the handoff step by step.

Be clear on what is automatic today versus what needs configuration, because the line matters when you are choosing how to wire Klyr into your workflow.

The Build Pack payload is always copy-ready: the markdown handoff and per-issue payloads are generated and available to paste or pull regardless of any integration setup. That is the path that works for everyone, immediately.

Native creation is the optional upgrade. Klyr can create the issue for you in GitHub or Linear, but only when server credentials are connected for that workspace (a GitHub token plus owner and repo, or a Linear API key plus team). Without those credentials, a push returns a prepared payload rather than a created issue: the content is identical, you just paste it yourself. Other providers such as Jira and Notion are payload-only for now, prepared as structured payloads until OAuth credentials are connected. Nothing is created in your tools silently, and nothing is blocked on an integration you have not set up.

Pasting a Build Pack is the manual handoff. The programmatic one is the agent-context endpoint: a read-only JSON view of a project at /api/projects/[projectId]/agent-context, authenticated with a bearer token. It returns a versioned payload with the project, ranked Feature Bets, Build Packs, current work, PRDs and plans, and the evidence graph (Product Memory) behind them.

Crucially it ships with explicit guardrails baked into the response: treat the context as planning input, not permission to mutate production data; keep evidence citations attached to generated work; and ask for human review before changing tasks, docs, code, or customer-facing behavior. It is a read surface by design.

The direction this points is an MCP server, so your agent can pull this context as a tool instead of you pasting it. The server is built and wraps that same read-only endpoint, with three tools: klyr_get_project_context for the full picture, klyr_list_feature_bets for the ranked bets, and klyr_get_build_pack for the PRD-plus-prompt handoff. It is the memory your agent forgets, exposed where the agent already works. To set expectations honestly: today the Build Pack copy-paste is the supported path, the agent-context endpoint is live and read-only, and the MCP server (and a hosted remote endpoint with per-workspace API keys) is the direction, not yet a deployed product.

If you only need synthesis or single-session reasoning over a corpus, your coding agent and free tools like NotebookLM already do that well, and Klyr will not pretend otherwise. The case for Klyr starts the moment synthesis is step one rather than the finish line.

Use Klyr when you need to get from customer evidence to a ranked bet, to a Build Pack your agent can execute against acceptance criteria, to an outcome that gets remembered. The agent writes the code; Klyr keeps the why, and remembers it after the window clears. See the side-by-side on the Cursor and Claude Code comparison, or start free from pricing.