The two default strategies, and why they fail

Strategy one: dump the files

The brute-force approach is to hand the model whole files — the one you're editing, plus whatever looks related. It fails in both directions at once:

• Too much: most of every file is irrelevant to the question, so you pay for tokens that add noise, not signal.
• Too little: the behavior you're asking about usually lives between files — an interface here, three implementations there, a decorator registered in a DI container nobody remembers.

Strategy two: vector search

Embeddings retrieve text that looks like the question. But code similarity is not code relevance. The method that breaks when you change an interface doesn't share vocabulary with the interface — it shares a compile-time relationship with it. No embedding captures that reliably, and the index drifts out of date the moment the code changes.

What the compiler already knows

Here's the thing: a complete, precise map of your codebase already exists. The C# compiler builds it on every compilation — every symbol, every type, every call edge, every dependency. It just throws the map away when it's done emitting IL.

GraphSlice keeps that map. It compiles your solution with the same semantic model the compiler uses and materializes the result as a semantic code graph: nodes for solutions, projects, types, and methods; edges for calls, inheritance, references, and package dependencies.

Slices, not searches

A graph you can't fit in a context window is no better than a repo you can't fit in a context window. The unit of delivery matters. GraphSlice serves slices — the minimal subgraph that answers one question:

> what breaks if I change IPaymentProcessor?

IPaymentProcessor (interface, Billing.Core)
├── implemented by StripeProcessor       (Billing.Stripe)
├── implemented by InvoiceProcessor      (Billing.Invoicing)
├── injected into CheckoutService..ctor  (Web.Checkout)
└── mocked in PaymentProcessorTests      (Billing.Tests)

That's the whole answer. Four dependency paths, a few hundred tokens — instead of forty files and a prayer.

Why MCP is the right delivery channel

Slices are served over the Model Context Protocol, which means any MCP-compatible assistant can request them as tools:

• The model asks a structural question ("who calls this?", "trace this dependency") instead of a text query.
• The graph does the reasoning about structure, so the model can spend its reasoning budget on intent.
• Your repository is never uploaded or indexed by a third party — the graph runs where your code runs.

The payoff

Correct context, not just nearby context. Smaller windows, flatter costs as the repo grows, and answers grounded in how the software actually fits together. Your AI assistant stops being a very confident text search and starts being an engineer with the blueprints in hand.

Anatomy of a slice

Every slice has three parts:

The anchor

The symbol the question is about — a method, a type, an interface, a project. Anchors are resolved by real symbol identity, not by name matching, so Process on OrderService never gets confused with Process on ImagePipeline.

The traversal

From the anchor, GraphSlice walks the edges that the question type calls for:

The traversal is bounded — by depth, by project boundary, or by relevance — so a hub symbol with ten thousand references doesn't flood the window.

The rendering

The subgraph is rendered in a form an LLM consumes efficiently: compact, hierarchical, deduplicated, with file-and-line anchors so the assistant can jump from structure to source when it needs the actual code.

What a slice deliberately leaves out

The discipline is in the omissions. A slice does not include:

• Method bodies that aren't on the dependency path.
• Symbols that merely live in the same file as something relevant.
• Anything retrieved because it was textually similar to the question.

Proximity in a file is an accident of formatting. Proximity in the graph is a fact about your software.

Why "minimal" is a feature

It's tempting to pad context "just in case" — but every irrelevant symbol in the window is a chance for the model to anchor on the wrong thing. Precision in, precision out. Keeping slices minimal is what keeps token costs flat as the repository grows: the graph gets bigger, but the answers don't.