It works. It ships. It has paid salaries for a decade. And it has slowly crossed the line from understood to inherited. The developer who knew why OrderProcessor has three separate retry paths took that knowledge to another company. The reason the scheduler lives in its own process became a story that shrank with every retelling. Now it is a sticky note that says don't touch the scheduler.

You know this codebase. You might be its maintainer. That job teaches a particular kind of care. You move slowly. You read twice. You carry a private map in your head of which floors creak. That knowledge in your head is the real asset. It is also the thing that walks out the door with every resignation.

Memory decays. Code doesn't.

Here is the asymmetry that makes legacy software feel haunted: the humans forget, but the code never does. The three retry paths still know exactly who calls them. The scheduler still knows exactly which types it touches. Every dependency, every override, every subscription is still there, fully determined, sitting in the source.

The knowledge did not vanish. It just stopped being legible to people.

The participant that never forgot

And here is the strange part. One participant in your team re-derives all of that knowledge, perfectly, several times a day: the compiler.

Every build, it resolves every reference, binds every call to its exact target, and checks every implementation against its interface. The result is a complete, correct graph of how the whole 120-project organism fits together. The compiler must build that graph, or it could not compile a single file.

Then it throws the graph away.

The most complete institutional memory your codebase has ever had is built and discarded on every build, while the humans get by on folklore and sticky notes.

That leaves a question which, once asked, refuses to leave. What if that graph were not thrown away? What if it were readily accessible — not only to the compiler, but also to the newest reader on your team: the agent in your editor, about to plan an edit in a codebase it has never seen?

Everything the veterans took with them is still derivable. Who calls the three retry paths. What the scheduler actually touches. Why project 87 is in the solution at all. Hand the agent the graph, and day one starts to look like year five.

That question is the idea that got us to found GraphSlice: stop throwing the graph away, and give it to the agent that needs it most.

Are we still talking loops or did we shift to graphs yet?

Peter Steinberger (@steipete), 18 July 2026 · 2.5M views · 362 reposts

It got 1,200 replies. We read a lot of them. Nobody agreed on what he meant. That is exactly why we can't stop thinking about it.

Who's asking

If you've spent any time with the openclaw crowd, you know what's going on here. These are the people who point a coding agent at their own repo and yell go. Peter is not selling anything with that tweet. That's what gives it weight. When the godfather of the loop starts wondering, in public, whether the loop was ever the whole story, you don't scroll past it. You screenshot it.

So we did. And then we did the thing you're not supposed to do with an ambiguous tweet: we tried to figure out what it meant.

What could it mean?

Honestly? Nobody knows, including the author, probably. "graphs" is one of those words that is specific enough to feel like a thesis and vague enough to be four different ones. Read the replies and you'll find at least these camps, each convinced they're the one he meant:

Four readings, one shape. Notice what they have in common: every single one is a quiet admission that the loop, on its own, is running blind.

The loop was never the problem. The blindfold was.

Let's be fair to the loop. The loop is great. The model calls a tool, reads the result, decides what to do next, goes again. That inner engine is most of why 2025 felt like magic. Nobody sane wants to throw it out.

But a loop is an engine, and an engine is not a map. Point a tireless agent at a million-line C# solution and tell it to loop. What you get is a machine that can grep, guess, and grep again — very fast, forever — and never ship. It doesn't know that IPaymentProcessor has four implementations, or that one of them only appears in a DI container three projects away. It learns that the expensive way: it loops into the wall until the wall gives.

That's the itch under Steinberger's question. "Did we shift to graphs yet?" is the polite version of how long will we let these things run in circles because we never handed them the map?

We've been the graph the whole time

We'll say the quiet part, because it's the only part we're qualified to say: for GraphSlice, this was never a "shift." There was no loop era we're now leaving. We started with a graph.

GraphSlice is a compiler-grade semantic code graph of your C# solution. Real types, methods, references, inheritance, calls edges (CALLS), package boundaries. The compiler builds this graph on every build and then throws it away. We keep it. And we don't hand the agent the whole graph, because that just bloats the context. Instead, we hand the agent a context slice: the minimal connected subgraph that answers one question, and nothing else.

> 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)

Put that in front of the loop, and the loop stops being a blindfolded sprint. It becomes what it was always meant to be: a fast engine with its headlights on. The graph does not replace the loop. It is what the loop should have been running over the entire time. And because the graph is served over the Model Context Protocol (MCP), any agent already stuck in a loop can ask for it without changing a thing about how it loops.

So what did he mean?

Honestly? He probably didn't mean us. He didn't @ us, he didn't link us, and a tweet that vague is a Rorschach test. Everyone selling a graph this week will read it as a horoscope written personally for their launch. We know how that looks. We're doing it right now, on purpose, with a wink.

But here's the thing about tea leaves: sometimes the arrow really does point somewhere. "Are we still talking loops or did we shift to graphs yet?" is not a neutral question. It has a direction baked in. The direction is away from run it again and hope, and toward hand it the graph. Six words, and every reasonable reading of them lands next to the thing we've been quietly shipping since before it was a tweet.

So, are we still talking loops, or did we shift to graphs yet?

Homer is proof that we're not the first people to reach for -slice. But we like to think we're the first with a good reason.

We're actually in the slicing business

Nobody in that episode could say what Compu-Global-Hyper-Mega-Net did. Not Homer, not Marge, not Bill Gates himself. That was the whole joke: pure 1998 internet vaporware, headquartered in a dining room, selling nothing but air and momentum.

We can name what we sell in one sentence. GraphSlice serves context slices: the minimal connected subgraph of your codebase that answers one question about the code, and nothing else.

The -slice in our name isn't a suffix we bolted on because it sounded provocative. It is the product. An agent asks "who calls this method?" or "what breaks if I change this interface?" We don't hand it your repository and hope. We walk the graph, cut the exact context slice that answers the question, and serve it. The name is the spec.

And the graph- half is every bit as literal. Underneath is a Roslyn-grade semantic code graph of your C# solution: real types, methods, references, and calls edges (CALLS), all resolved by the compiler. Not a bag of text that happens to sit near your cursor. Homer never could explain his company. Ours is two nouns, and both of them are true.

The part where Bill Gates trashes the office

You know how the episode ends. Gates turns up at Evergreen Terrace. He cheerfully admits he can't figure out what the company does, and he offers to buy Homer out. Homer accepts gleefully. Then comes the line:

"Oh, I didn't get rich by writing a lot of checks." — Buy 'em out, boys!

And his men take the dining room apart.

It's one of the sharpest cold jabs at 1990s Microsoft ever put on television. The OS giant doesn't so much compete with the little guy as disassemble him — then bills it as an acquisition.

Why Microsoft would get it — and why we'd play along

Which is exactly why the joke is safe for us to make. Point that scene at GraphSlice and it stops being a threat and becomes a wink. Everything we build sits on Microsoft's stack, not across the table from it:

• The graph is Roslyn's. We read your solution with the same compiler platform Microsoft ships. Our fidelity is their fidelity. Every C# feature they add, we understand for free the day it lands.
• The language is theirs. GraphSlice exists to make C# and .NET legible to agents. The better an agent can reason about a million-line .NET codebase, the safer a bet it is to keep writing .NET at all in the AI era. We make Microsoft's languages age well.
• The protocol is the one they've adopted. We serve over the Model Context Protocol (MCP) — the same MCP that VS Code, GitHub Copilot, and Azure now speak natively. Serving structural code context over MCP isn't slipping past the platform. It's walking in the front door they built and left open on purpose.

Add it up and the cartoon inverts. If Gates walked into our dining room, he wouldn't need the goons. He'd just get it. GraphSlice runs on-premise: your source never leaves your building, and your agents give better answers along the way. The entire point is to make the Microsoft ecosystem more valuable in the age of AI, not to carve a piece off it. (Well, one piece. Per question, per context slice. That's our product.)

So we'll happily play the homage straight, TTS and all. A company genuinely afraid of Redmond couldn't afford this joke. We can, because we know which side of the office-trashing we're on. We named ourselves after the one thing Homer never could explain. Then we built it on the very stack the man with the checkbook would recognize on sight.

Homer, roll the tape.

We spend a lot of time thinking about what to feed a coding agent. That's the whole point of GraphSlice. But the thing on the other end of the pipe matters too: the harness that holds the model, runs the tools, and decides what to do with the context it gets handed. Lately, the one we keep reaching for is Goose.

One agent, two front doors

Goose ships in two forms. The relationship between them is the part worth understanding.

There's a CLI: a proper terminal agent that runs shell commands, edits files, and drives multi-step work from where you already live. And there's a desktop app, which the marketing quite reasonably presents as a separate "distro." Install one or the other, pick your interface, off you go.

Here's the bit that made us trust it: the desktop app isn't a fork, it's a face. Both front doors read the same config.yaml: your provider, your model, your enabled extensions, your keys. Configure them once and both the terminal and the GUI pick them up. The desktop app is a graphical skin over the same engine and the same configuration. It's not a second product that happens to share a name. That isn't obvious at first glance, and it isn't a bug. It's a feature.

It's a small architectural decision with a big payoff in trust and UX. You never have to wonder which Goose you're talking to. There's one agent. You just choose whether to look at it through a prompt or a window.

Batteries included, and the batteries are MCP

Most agents make you go shopping before they're useful. Goose ships with a set of built-in extensions that are really just Model Context Protocol (MCP) servers wearing a friendlier name. The defaults are unusually good:

• developer does the core loop: run shell commands, write and edit files, walk the directory tree. This is the one that makes Goose an agent and not a chat window. (docs)
• computercontroller gives you platform-aware control of the machine itself. Its instructions adapt to the host OS.
• memory keeps durable preferences and facts across sessions, split between a project-local .goose/memory and a global store.
• tutorial and autovisualiser round out the defaults.

Because these are MCP servers, adding your own is the same motion as everyone else's. Goose exposes official servers for GitHub, Postgres, Slack, and Jira. The community has built a hundred-plus more. The out-of-the-box catalog is wider than most competitors expose on day one. "Install and it does something real" is true before you've configured anything.

This is also where Goose and GraphSlice speak the same language. GraphSlice serves context slices over MCP, and Goose consumes MCP. Point Goose at GraphSlice and the agent stops hallucinating answers about your architecture. It starts asking structural questions instead: who calls this? and what breaks if I change that? That's exactly the kind of context a developer extension can't grep its way to.

Why people actually love it

Read around and the enthusiasm keeps landing on a few themes. They're not the usual hype:

• It runs on your machine. Goose executes locally and is LLM-agnostic across 15+ providers: Anthropic, OpenAI, Google, Ollama, Bedrock, and more. Pair it with a local model and your code never leaves the building. For regulated work, that's one of the few viable ways to have an AI coding agent at all.
• It goes beyond suggestions. The pitch on the tin is "install, execute, edit, and test." It does the work, not just the autocomplete.
• It's extensible by design. Goose is MCP-native from the ground up, so you never fight the tool to make it talk to your stack.

And then there's the provenance. Goose comes out of Block, Jack Dorsey's company (the one behind Square and Cash App), and it's open source under Apache 2.0. But the part that actually sold us is why it exists. As Wired reported, Block didn't build Goose to ship a product. They built it to make themselves faster. They ran it internally for something like a year and a half before opening it up. By the company's own numbers, roughly three-quarters of its engineers say it saves them eight to ten hours a week. A majority of the whole company reaches for it weekly. That's the opposite of a launch-day demo. The tool had to earn its keep in-house first, which is a much better reason to trust it than any pitch deck.

The newer development is the interesting one. Block has handed Goose to the Linux Foundation's Agentic AI Foundation. That puts it under neutral, community-driven governance, with backing from AWS, Anthropic, Google, Microsoft, and OpenAI. So it's not just open source in the license sense any more. It's fully open, out from under any single vendor's roadmap. A tool you build into your daily work deserves governance you can trust, and Goose just moved in the right direction on exactly that axis.

The short version

Goose is a well-built open-source agent with one brain and two faces. It has a genuinely useful default toolkit, local-first execution, provider freedom, and governance headed somewhere durable. It also speaks MCP, the same protocol GraphSlice serves context slices over. That makes it a natural harness for putting the right context in front of a model.

We like Goose. If you haven't given it a real afternoon, give it one.

The two default strategies, and why they fail

Strategy one: dump the files

The brute-force approach hands the model whole files — the one you are editing, plus whatever looks related. It fails in both directions at once:

• Too much: most of every file is irrelevant to the question. You pay for tokens that carry no signal.
• Too little: the behavior you ask about usually lives between files — an interface here, three implementations there, a decorator registered in a DI container nobody remembers.

Strategy two: embeddings

Embeddings retrieve text that resembles the question. But resemblance is not relevance. The method that breaks when you change an interface does not share vocabulary with that interface. It shares a compile-time relationship with it. No embedding captures that reliably, and the index goes stale the moment the code changes.

What the compiler already knows

Here is the thing: a complete, precise graph of your codebase already exists. The C# compiler builds it on every compilation — every symbol, every type, every call, every dependency. Then it throws that graph away the moment it has emitted IL.

GraphSlice builds that graph and keeps it. A purpose-built tree walker reads your solution's source directly. It resolves symbols, types, and calls across projects, then writes the result as a semantic code graph: nodes for solutions, projects, types, and methods; edges for the relationships between them — calls edges (CALLS), inheritance, references, and package dependencies.

Context slices, not searches

A graph that cannot fit in a context window is no better than a repo that cannot fit in a context window. The unit of delivery matters. GraphSlice serves context 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 is the whole answer. Four dependency paths, a few hundred tokens — instead of forty files and a prayer.

Why MCP is the right delivery channel

GraphSlice serves context slices over the Model Context Protocol (MCP), so any MCP-compatible agent can request them as tools:

• The agent asks a structural question ("who calls this?", "trace this dependency") instead of a text query.
• The graph does the reasoning about structure, so the agent 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. It becomes an engineer with the graph in hand.

Anatomy of a context slice

Every context slice has three parts:

The anchor

The symbol the question is about — a method, a type, an interface, a project. Anchors resolve 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 the question calls for:

The traversal is bounded — by depth, by project boundary, or by relevance. A hub symbol with ten thousand references cannot flood the window.

The rendering

The subgraph is rendered in a form the agent consumes efficiently: compact, hierarchical, deduplicated. File-and-line anchors let the agent jump from structure to source when it needs the actual code.

What a context slice deliberately leaves out

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

• Method bodies that are not on the dependency path.
• Symbols that merely share a file with 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 is tempting to pad context "just in case". But every irrelevant symbol in the window can pull the agent toward the wrong thing. Precision in, precision out. Minimal context slices keep token costs flat as the repository grows: the graph gets bigger, but the answers do not.