A new data agent treats evidence—not prose—as the interface between SQL, RAG and graph queries
The young LangGraph project is notable less for its model layer than for a typed evidence contract, explicit execution boundaries and unusually candid validation limits.
A newly published open-source project offers a useful architectural answer to a recurring data-agent problem: how should one system combine SQL results, retrieved documents and graph records without collapsing everything into untraceable prose?
The Apache-2.0 Multi-Source Data Agent routes questions through separate Text-to-SQL, PostgreSQL/PGVector retrieval and Neo4j graph tools. Each tool returns a common ToolResult; citable facts are then represented as Evidence, aggregated into an EvidenceContext, and consumed by a shared answer generator. The project’s web console exposes SQL or Cypher, sources, citations and execution state rather than presenting only a final answer. The repository README documents that pipeline and its synthetic retail demonstration.
The interface is the interesting part
The repository separates product routing from tool choice. A top-level router distinguishes general, clarification, file-ingestion and data questions; a planner then decomposes data work before selecting SQL, retrieval or graph tools. That distinction matters because it makes evidence—not any one database or model—the stable boundary between execution and answer generation.
The SQL path also treats generated SQL as a candidate rather than permission to execute. The documented controls include SQLGlot AST validation, schema and table allowlists, a separately configured read-only business database account, row limits, timeouts and at most one controlled repair attempt. Application persistence and business-query connections are deliberately separate. The project’s security release notes describe the database split, JWT ownership checks, bounded uploads and sanitized client errors.
Strong engineering checks are not an accuracy benchmark
The launch includes more validation detail than most one-day-old repositories. Its security record reports 394 passing deterministic Python tests, including 77 newly added security tests; frontend lint/build checks, an npm audit with zero reported vulnerabilities, and isolated five-service container verification also passed. Those are repository-reported results, not an independent audit.
Crucially, the authors do not convert those checks into a model-quality claim. They say the deterministic suite uses mocked tool calls and that the release did not run a complete paid-model, embedding and reranker smoke test. The three published demo timings—26.9 seconds for SQL, 13.5 seconds for graph and 22.4 seconds for retrieval—are labeled local observations rather than production SLAs or benchmark scores.
That restraint is the project’s most reusable lesson. Multi-source agents need two separate ledgers: one for whether the system respected identity, execution and evidence boundaries, and another for whether the generated answer was actually correct. This repository has put unusually concrete work into the first ledger. Its next test is whether reproducible end-to-end evaluations and outside users can fill the second.
sources
comments · 0