A support ticket is useful in isolation. So is a CRM record, a design file, a spreadsheet row. Most AI tooling treats context as retrieval because most professional context works this way: find the right document, surface the relevant snippet, feed it to the model. The information lives somewhere specific. The challenge is fetching it fast enough.

A function signature, on its own, tells you almost nothing.

Code context is distributed across dozens of surfaces. And the meaning lives in the connections between artifacts. Which functions call which, what depends on what, how a change in one service ripples through twelve others. Strip those relationships away and you have fragments that look like information but can't support reasoning.

Aditi Kothari, who co-founded Potpie AI after product management work at Razorpay, describes the landscape plainly: most knowledge workers operate inside one primary tool. Developers don't. To ship a feature end-to-end, a developer touches 30 or more tools. Code in one place, logs in another, tickets somewhere else, documentation scattered across wikis that may or may not reflect the current system. The context is all there. It's distributed across dozens of surfaces, and the relationships between the pieces carry most of the meaning.

Anyone who has ever tried to trace a production failure across interconnected services knows the shape of this problem. You open a log, which points to a function, which calls another service, which depends on a config that changed three sprints ago in a ticket nobody linked to the deployment. Each artifact is findable. The path between them is where the reasoning actually happens, and no retrieval system built for flat documents reconstructs that path.

A JetBrains and UC Irvine study tracking 151 million IDE window activations found that AI-assisted developers' context-switching actually trended upward over two years. Seventy-four percent of those developers didn't notice the increase. The tools meant to reduce fragmentation were quietly adding to it, because they accelerate work within individual artifacts while leaving the connections between them untouched.

That gap is the logic behind Potpie's knowledge graph foundation, built on Neo4j, mapping every function, class, file, import, and call relationship in a codebase. Kothari calls the approach "ontology-first": build the structural representation of how the system connects before asking an agent to reason about it. The company spent nearly 22 months on this infrastructure before shipping a product. For a pre-seed startup, that's an unusual tempo. But it follows directly from the problem's shape. You can't shortcut a knowledge graph into existence the way you can fine-tune a model on a new dataset. The relationships have to be mapped before they can be reasoned about.

Every tool that skips this step deserves scrutiny. If agent effectiveness depends on structural understanding of the system, then tools retrieving code snippets without mapping relationships are building on a foundation that can't support the reasoning they promise. The infrastructure is the precondition.

Potpie raised $2.2M in pre-seed funding and is early. Whether this specific architecture proves durable at enterprise scale is genuinely open. But the structural observation underneath it holds regardless: developer environments are graphs. Twenty-two months of foundation work reflects that shape. Flat problems get flat solutions. This one required depth.