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. The annoying question behind many code changes: “Why do we do it this way?” The useful Cursor 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.

Don't assume 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 Subagents and skills: 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.

Don't let 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.

Further reading

• Cursor rules
• MCP specification
• whyline on GitHub

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.