Smart Context System: Give Your AI a Long-Term Memory for Real Projects

The Problem: Your AI Has Amnesia

Imagine you just joined a new project. You open Cursor, ask it why a certain tax calculation works the way it does — and it has no idea. It sees the code, but it doesn't know the story behind it.

Now imagine a senior developer sitting next to you. They'd say: "Oh that? We had a nasty bug last quarter — ticket #456 — where the luxury tax was being applied after VAT instead of before. Took us two days to trace. Here's the commit."

That's the gap. AI coding assistants are brilliant at reading code, but they have no memory of why things were built the way they were.

The Smart Context System is a hackathon idea that closes this gap — by giving Cursor AI a long-term memory fed by two sources your team already uses every day: Git history and Azure Boards.

What Does It Actually Do?

In plain terms:

• Every time a developer commits code → the system quietly saves a summary of that commit.
• Every time a ticket moves to Done in Azure Boards → the system saves the ticket title, description, and discussion thread.
• When you later ask Cursor about a bug or a feature → the system finds the most relevant past commits and tickets, and feeds them into your prompt automatically.

The result: Cursor can say "This looks similar to ticket #456 where LuxuryTaxCalculator needed to run before VAT — here's the relevant commit."

A Real-World Scenario

Let's walk through what this looks like day-to-day.

Day 1 — A bug is fixed

A developer fixes a tricky tax calculation bug. They close ticket WI-456 in Azure Boards (state → Done) and push a commit a3f9c1 with the fix.

Behind the scenes, the Smart Context System:

1. Receives a webhook from Azure Boards: "WI-456 is now Done."
2. Fetches the ticket fields and comment thread from the Azure DevOps API.
3. Fetches the code diff for commit a3f9c1 from Git.
4. Optionally summarizes both with a small LLM call.
5. Converts them into vectors and stores them in a Vector Database.

No manual work. It all happens in the background.

Day 30 — A new developer hits the same area

A new team member opens Cursor and types: "I'm seeing unexpected results in the tax calculation for imported luxury goods."

Cursor (via the Retrieval API) searches the vector database, finds WI-456 and commit a3f9c1, and surfaces this context automatically:

📎 Related past fix: WI-456 — "LuxuryTaxCalculator must run before VAT to avoid double-compounding on imported goods." Commit: a3f9c1 · Author: dev@company.com · Jan 15, 2025

The new developer doesn't need to search Jira, dig through git log, or ping the senior dev on Slack. The answer comes to them.

How It's Built — The Big Picture

Here's the architecture, simplified for beginners:

  Git Repository          Azure Boards
  (new commits)           (ticket → Done)
       │                       │
  Scheduler              Webhook listener
  (checks every N min)   (fires instantly)
       │                       │
       └──────────┬────────────┘
                  ▼
               Queue
          (jobs wait here)
                  │
               Worker
          ┌────────────────┐
          │ 1. Fetch data  │  ← diff from Git / fields+comments from Azure
          │ 2. Normalize   │  ← clean up metadata
          │ 3. Summarize?  │  ← optional LLM call for long text
          │ 4. Chunk       │  ← split into searchable pieces
          │ 5. Embed       │  ← convert to vectors
          └────────────────┘
                  │
            Vector Database
                  │
          Retrieval API / MCP
                  │
           Cursor IDE Context

Each piece has a simple job. Nothing is magic — it's just a well-connected pipeline.

Two Types of Jobs

The Worker handles two distinct flavors of job:

Commit Job

Work Item Job

What "Retrieval" Looks Like in Practice

When you prompt Cursor, the retrieval flow is:

1. Your query is converted to a vector.
2. The Vector DB finds the Top-K most similar stored chunks.
3. Those chunks — with source links (SHA, Azure URL) — are injected into your Cursor context.
4. You get an answer grounded in your project's actual history.

This works via two integration options:

• MCP Server — Native Cursor support, deep integration, minimal config once set up.
• HTTP Retrieval API — More flexible, can be called from .cursorrules or a custom tool.

Why Only Git + Azure Boards?

A common question: why not also index PRs, deploy logs, Slack messages?

The short answer: those two sources cover 80% of the value.

• Git diffs answer "what changed and how."
• Done tickets answer "why it changed and what the team decided."

Adding more sources adds complexity without proportional benefit — especially for a hackathon prototype. Keep it simple, prove it works, expand later.

What You Need to Build This

For a hackathon: start with ChromaDB + FastAPI + GPT-4o-mini. You can have a working prototype in a weekend.

The Impact — Before vs After

Final Thought

The best AI assistant isn't the one with the biggest model. It's the one that knows your project — the bugs you've fixed, the decisions you've made, the tickets that kept the team up at night.

The Smart Context System is a practical, buildable idea that any team can prototype in a hackathon and grow into a real productivity multiplier. The infrastructure is standard. The data is already there. You just need to connect the dots.

Git + Done tickets → vector memory → Cursor context. That's the whole idea.