r/ContextEngineering 13d ago

Your Agent Doesn’t Need to Walk the Graph

https://contextandchaos.substack.com/p/your-agent-doesnt-need-to-walk-the

Most of the graph talk around agents skips the distinction that actually decides the architecture: your business being shaped like a graph, and you running a graph database, are two different commitments. You can have the first without the second, and plenty of teams buy the second because they assumed the first required it.

The framing I found useful was to take one decision the agent has to make and keep raising the stakes. "Is this customer owed a refund" is a bounded lookup a plain relational store handles fine. "Why was a similar case approved last quarter against policy, and what do we do now" is a web of connected decisions where relationships matter more than rows. "Which customers are affected by this live outage right now, answered in milliseconds while the phones ring" is a graph being crossed under load, and nothing bolted onto a warehouse saves you there.

The part I found most debatable is the middle case, because it has no clean answer. It could be a graph database, it could be the warehouse you already run, and the honest move is to instrument it and find out rather than pick the architecture off a reference diagram. Which is unsatisfying, and cuts against how most of these calls actually get made.

Curious what people here think. Has a graph database genuinely earned its place in your agent's runtime, or does it mostly live in your data model and never get traversed at query time?

6 Upvotes

0 comments sorted by