Whyline: Company Memory for Cursor

Whyline is an open-source company memory engine by Sunradiance that connects workplace decisions to AI coding tools through the Model Context Protocol. It deals with the annoying question behind many code changes: “Why do we do it this way?” The useful Cursor, Anysphere's AI code editor, takeaway is simple: keep cursor rules small, wire memory through a read-only MCP boundary, and make the agent show receipts before it changes code. Whyline is a self-hosted “why layer” for decisions, links, and explanations that developers can query from Cursor.

Ask the repo why before changing the repo

Whyline’s pitch is not “chat with your docs.” It is closer to “ask why, get the trail.”

The GitHub project describes a server-side SQLite store, BM25 retrieval, and answer receipts from systems like Slack, Jira, GitHub, email, Teams, Linear, Notion, Confluence, Google Docs, and meeting transcripts. As of the July 2026 source signal, the repo is small and early: mainly Python, one GitHub star, and last pushed on July 6, 2026. That matters because this is not a mature enterprise search product. It is a sharp open-source sketch of a workflow many engineering groups already want.

BM25 is a classic lexical search ranking method that scores documents by how well their terms match a query. In Whyline’s design, that means the system does not need to shove the whole company archive into every prompt. It can retrieve a smaller set of likely-relevant decision records, then point back to the Slack permalink, Jira key, PR, or document that supports the answer.

A real example: a Cursor agent is asked to update billing logic for Germany. Before editing pricing_policy.py, it asks Whyline, “Why don’t we support annual billing in Germany?” The useful answer is not a confident paragraph. It is a paragraph with receipts: the product decision, the compliance concern, the support burden, and the link trail a human can check.

The trap is assuming memory is the same as truth. Whyline can surface old reasoning. It cannot decide whether that reasoning still applies.

Put MCP between Cursor and the memory store

MCP is the integration layer that lets an AI client call external tools and data sources through a defined server interface. In this story, Whyline becomes a memory source that Cursor can query while the agent works inside the editor.

That changes the coding loop in a small but important way. Instead of pasting context into chat, a developer can ask the agent to look up the reason behind a constraint while it is already reading the code. The agent can then propose a change with both code references and company-memory references.

This fits the broader pattern behind the related training topic: Cursor subagents, Cursor skills, rules, and MCP are most useful when each piece has a narrow job. Rules tell the agent how to behave in the repo. Skills package repeatable procedures. MCP connects the agent to systems outside the repo.

A good first workflow is boring on purpose:

• Ask Cursor to inspect the local code path.
• Ask Whyline for the decision trail.
• Make Cursor summarize both sources before editing.
• Review the diff and the receipts together.

The trap is letting the MCP server become a magic authority. If the agent says “Whyline says so,” that is not enough. The answer should name the originating artifact: PR, Jira issue, Slack permalink, doc URL, or meeting note.

Keep the first server read-only

The safest Whyline experiment is read-only. Let Cursor ask the memory engine questions, but do not let it write new company memory, modify tickets, send Slack messages, or edit documents.

That boundary sounds timid, but it is the difference between retrieval and operations. Retrieval helps the agent understand why a code path exists. Operations can create records, mutate workflows, or accidentally turn a draft idea into institutional memory.

For example, allow this:

• Search captured decisions.
• Fetch a specific receipt.
• Summarize conflicting decision records.
• List source systems used in an answer.

Do not allow this at first:

• Create or edit Jira issues.
• Post to Slack or Teams.
• Mark a decision as approved.
• Update billing, customer, vendor, or compliance records.

This is also where a repo-local Cursor rules file earns its keep. The rule should not explain your whole architecture. It should set the boundary: memory can inform edits, but receipts must be shown and write actions stay off-limits.

If you want another example of MCP as a narrow engineering surface, Scopewalker MCP Measures Code Complexity is a useful comparison: it treats the server as a focused measurement tool, not a general-purpose agent brain.

Copy this safe-start artifact

Use this as a tiny decision table before wiring Whyline into Cursor. It is intentionally small. If you cannot fill it in, the integration is not ready to trust inside a coding session.

Permission-boundary note: treat Whyline as evidence, not permission. A Cursor agent may use Whyline to explain why annual_billing_de_enabled is false, but it should not flip that flag unless the human review includes current product and compliance confirmation.

Here is a starter .mdc rule for a repo using Whyline through MCP:

---
description: Use Whyline memory before changing decision-heavy code paths
alwaysApply: false
---

When a task touches pricing, billing, compliance, vendor logic, customer eligibility, or old feature flags:

1. Ask the Whyline MCP server for the decision trail before editing.
2. Summarize the relevant receipts in the chat before proposing code changes.
3. Prefer primary receipts: PRs, Jira issues, design docs, Slack permalinks, or meeting notes.
4. Do not treat Whyline answers as approval to change policy.
5. Do not call write-capable tools for Slack, Jira, docs, email, or issue trackers.
6. If receipts conflict or are older than the current policy owner’s guidance, stop and ask.

This is not meant to replace AGENTS.md. Put durable repo rules and architectural boundaries there. Use Cursor rules for scoped agent behavior, especially when a specific workflow needs to activate only around risky files or task types.

The old cursor rules file .cursorrules habit can lead to one large, vague instruction blob. The current pattern works better when rules live close to the code they affect and stay short enough that reviewers can understand them.

Common questions

• What problem does Whyline actually solve?

  Whyline tries to solve institutional amnesia: the loss of decision context behind code, product rules, and operational constraints. Its concrete bet is SQLite plus BM25 retrieval plus receipts, exposed through MCP, so a coding agent can answer “why” with source links instead of inventing a plausible reason.

• Should Whyline be the first MCP server I connect to Cursor?

  Yes, if your biggest pain is old decisions that nobody can explain. Start with read-only access to GitHub PRs and engineering docs before adding chat or ticketing systems. If your pain is code metrics or deployment state, a narrower MCP server may be a better first test.

• How should cursor rules mention Whyline?

  Keep the rule behavioral, not encyclopedic. A good rule says when to ask Whyline, what receipts the agent must show, and which actions are forbidden. Do not paste decision history into the rule; that belongs in Whyline or durable repo docs such as AGENTS.md.

• Does a cursor rules file replace AGENTS.md?

  No. Use AGENTS.md for durable repository conventions, architecture constraints, and human-readable boundaries. Use Cursor rules for agent behavior inside Cursor, especially scoped behavior around certain files or tasks. If both exist, keep them consistent and make the Cursor rule the narrower instruction.

• What is the main limitation of a company memory engine?

  The main limitation is freshness and authority. Whyline can retrieve why a decision was made, but it cannot know whether that decision still holds unless the underlying sources are current. For policy-heavy code, old receipts should trigger review, not automatic edits.

Best ways to use this research

• Best for: Cursor users exploring MCP-backed memory for codebases with old product, billing, compliance, or platform decisions.
• Best first artifact: A read-only Whyline MCP connection plus one scoped .mdc rule that requires receipts before risky edits.
• Best comparison angle: Whyline is closer to a receipt-backed memory layer than a generic document chatbot; judge it by answer traceability, not answer fluency.
• Best review habit: Ask the agent to put code references and Whyline receipts in the same final summary so reviewers can check both without replaying the chat.

Further reading

• Cursor — Rules
• Model Context Protocol — specification
• whyline — source

Try one narrow memory path

Pick one confusing policy-heavy code path, connect Whyline read-only, and require receipts before Cursor edits anything. If the receipts help review the diff faster, you have found the useful seam.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.