Chapter16

Chapter 16: What Comes Next\index{future work}¶

BFS-QL as it exists today solves a specific problem: making a single knowledge graph accessible to an LLM through a minimal, well-defined interface. The solution is complete in the sense that it works -- the medlit demo graph, the DBpedia SPARQL endpoint, any kgraph-derived Postgres database can be served, connected, and queried. But complete does not mean finished. Several directions are visible from here.

Multi-Graph Federation¶

The composition model in Chapter 13 is manual: the LLM navigates across graphs by carrying identifiers and calling search_entities in the destination graph. This works, but it requires the LLM to be aware of which graph to query at each step, to manage the bridging operation explicitly, and to handle the case where a canonical ID in one graph does not resolve in another.

A federation layer would make this automatic. Given a set of registered BFS-QL graphs and a query, the federation layer would identify which graphs are relevant, issue parallel BFS queries, and merge the results -- resolving identity conflicts using shared canonical IDs and presenting the union as a single logical graph. The LLM would see one set of six tools, not N sets.

The technical foundation for this exists. Shared canonical IDs provide the merge key. The GraphDbInterface ABC provides the interface that every backend already implements. The CachedGraphDb wrapper provides the session-scoped caching that would extend naturally to a cross-graph scope. What does not yet exist is the federation engine itself: the identity resolution pass, the union semantics for conflicting metadata, the query routing logic.

Schema-Aware Query Optimization¶

BFS-QL currently fetches all edges from all nodes in the frontier at each hop, then applies stub/full filtering to the results. For a well-connected graph with many predicates, most of those edges may be irrelevant to the query -- they will become stubs regardless. The traversal still issues the backend calls, still acquires pool connections, still processes the rows.

Schema-aware optimization would use the predicates filter to prune traversal before it happens. If the caller specifies predicates=["treats", "inhibits"], the backend's edges_from query can include a WHERE predicate IN (...) clause, eliminating irrelevant edges at the database level rather than after retrieval. The GraphDbInterface would need to support optional predicate hints, or a specialized edges_from_filtered method could be added for backends that can use it efficiently.

This optimization matters most for large, densely connected graphs where the majority of edges are structural noise for any given query. For the medlit demo graph (99 edges total), it is irrelevant. For a Wikidata subgraph or a large pharmaceutical compound graph, it could reduce traversal time by an order of magnitude.

Richer Traversal Primitives¶

BFS is the right primitive for LLM-driven graph exploration today, for the reasons Chapter 3 argues: it starts from what the model knows, expands outward, and produces a bounded, interpretable result. But BFS is not the only useful traversal primitive, and as LLM context windows grow and models become better at structured reasoning, richer operations become viable.

Shortest-path queries -- "what is the shortest connection between compound A and disease B?" -- are structurally different from BFS but expressible as a composition of BFS calls. A dedicated shortest_path tool would be more efficient and more explicit. Aggregate queries -- "which entity type appears most frequently in the 2-hop neighborhood of this seed?" -- are currently inexpressible in BFS-QL; they require the LLM to aggregate BFS results manually, which is error-prone for large result sets.

These are not arguments to add these tools now. The six-tool surface is correct for current LLM capabilities and context constraints. The argument is that the eight-method ABC is designed to remain stable as the surface above it evolves: new tools can be added to the MCP server without changing any backend implementation. The ABC is the stable layer; the tools are the variable layer. intersect_subgraphs is an example of how this works in practice: it was added to the server layer without any changes to the three existing backends.

The Interface Contract as the Stable Layer¶

This is worth stating directly. Backends and LLMs will both evolve. Postgres will add new features. SPARQL endpoints will grow. Neo4j's query language will change. LLMs will get better at structured reasoning, larger context windows, more reliable tool use. Any of these changes might motivate changes to how BFS-QL works.

The eight-method ABC is designed to absorb these changes without propagating them. A new backend for a new graph store implements the same eight methods it would have implemented today. A new LLM with larger context windows gets larger BFS results from the same bfs_query tool; the interface does not change. A new traversal primitive can be added as a seventh tool on the MCP server; existing backends continue to work unchanged because the new tool is implemented in the server layer in terms of the existing eight methods.

The design principle -- all intelligence in the server layer, all backend-specific logic behind the ABC -- is what makes this possible. The boundary between server and backend is not just an organizational choice. It is the line along which the system can evolve without breaking the parts that work.

What Would Have to Change¶

It is worth asking what would have to happen for BFS-QL to become inadequate as an interface. Several scenarios are plausible:

LLM-native graph reasoning. If future LLMs could natively reason over graph structures -- not just flat text, but labeled property graphs with adjacency semantics -- then the BFS-QL interface might be bypassed in favor of direct graph access. This seems distant; the transformer architecture has no graph inductive bias, and graph-native reasoning would require architectural changes beyond what current scaling achieves.

Context windows that eliminate the working-set constraint. If context windows grew to the point where dumping an entire knowledge graph was computationally reasonable, the argument for selective BFS traversal would weaken. At ten million tokens, you could load DBpedia. But the quadratic attention cost means this is not merely a hardware scaling problem -- it is structural. The working-set constraint does not go away with larger windows; it becomes more expensive, not less.

A better traversal primitive. If a different graph access pattern -- not BFS, not random walk, not shortest path, but something not yet named -- turned out to be more natural for LLM-driven reasoning, BFS-QL would need to change. This is possible. BFS is motivated by the analogy to how LLMs construct reasoning chains, but analogies are not proofs.

None of these scenarios is imminent. What this analysis reveals is that BFS-QL's longevity depends most on the durability of the working-set constraint. If context windows remain scarce relative to graph size -- which the transformer architecture strongly suggests they will -- then selective, bounded traversal from known seeds will remain the right model. The interface built around that model will remain correct.