Knowledge graphs + LLM agents (GraphRAG) for credit agreements

Ask a plain retrieval-augmented (RAG) chatbot "how much debt can the borrower incur?" against a 250-page credit agreement and you'll usually get a confident answer built from whichever chunks scored highest for "incur" and "Indebtedness." It will often miss the ratio debt basket's dependence on the definition of Consolidated EBITDA, the add-back cap buried three definitions deep, the reclassification language, and the fact that the general basket "grows" with EBITDA. That isn't really a model problem. The answer depends on a network of definitions and cross-references, and chunk retrieval doesn't follow networks.

A credit agreement is already a graph

Illustrative structure

• Lender / BDC
• Fund / vehicle
• Borrower
• Facility / loan
• Sponsor
• Agent bank
• Amendment
• Filing

Look at a credit agreement structurally and you find:

• Defined terms (nodes) that use other defined terms. "Available Amount" uses "Consolidated Net Income," which uses "Consolidated EBITDA" carve-outs, and so on. A typical agreement has hundreds of defined terms.
• Cross-references (edges): "subject to Section 7.02(k)," "as permitted under Section 7.06," "notwithstanding anything to the contrary in Section 7.05."
• Baskets (nodes with attributes: fixed dollar amount, grower percentage of EBITDA or total assets, ratio test, builder) attached to covenants: debt, liens, investments, restricted payments, asset sales.
• Interactions (edges between baskets): reallocation between RP and investment capacity, reclassification, shared capacity, "usage under X reduces Y."
• Parties and roles: borrower, guarantors, restricted and unrestricted subsidiaries, agents, required lenders, affected lenders.
• Amendments as dated events that modify specific nodes.

Here's a toy extraction from an illustrative, invented agreement (not a real deal):

(Investments covenant 7.02) -[HAS_BASKET]-> (7.02(n) general: greater of $50m and 25% EBITDA)
(7.02(n)) -[USES_TERM]-> (Consolidated EBITDA)
(Consolidated EBITDA) -[USES_TERM]-> (Pro Forma Basis), (Run-Rate Synergies, cap 25%)
(7.02(t) Unrestricted Sub investments) -[REALLOCATES_FROM]-> (7.06 RP general basket)
(Unrestricted Subsidiary) -[DEFINED_IN]-> (Section 1.01)
(Required Lenders) -[VOTE_FOR]-> (amend 7.02); (each Affected Lender) -[VOTE_FOR]-> (pro rata sharing 2.13)

Once the agreement is in this form, "how much can be invested in unrestricted subsidiaries?" turns into a walk: the investment covenant → every basket that permits investments in non-guarantors → each basket's size definition → the terms those definitions use → any reallocation edges into that capacity. An agent can then read the actual text of each node it visited and compute or explain the answer with citations.

Liability management: blocker detection as a graph query

LME transactions (drop-downs, uptiers, double-dips) exploit paths through the document. Most of the familiar protective provisions are about blocking a specific path:

• Drop-down / unrestricted sub transfers. Capacity to move material IP or assets outside the credit group comes from investment baskets, designation mechanics and asset-sale permissions. A blocker (often called a "J.Crew" provision in the market) cuts those edges for material IP.
• Uptiers / non-pro-rata exchanges. Depend on whether subordination and pro rata sharing can be amended by Required Lenders or need each affected lender ("Serta"-style protection), and on open-market purchase language.
• Guarantor release. Depends on whether a guarantor becoming non-wholly-owned releases its guarantee ("Chewy"-style concerns).

Represented as a graph, the screening question becomes: is there a path from "material asset of a Loan Party" to "entity outside the collateral package" using only permitted edges, and does any blocker node sit on every such path? Also: which voting thresholds govern the nodes on that path? A plain search for "J.Crew" won't answer that, because blockers are drafted many ways and their effectiveness depends on definitions ("Material Intellectual Property," "Transfer," "Unrestricted Subsidiary") that may be narrow.

Use this as a screening aid with human review, not a legal opinion. The agent's output should list the paths it found, the nodes it couldn't resolve, and the exact clause text, so a lawyer or credit analyst can check it in minutes rather than hours.

When a graph beats plain RAG, and when it doesn't

Microsoft Research's GraphRAG paper (Edge et al., 2024; blog; code) frames the distinction clearly. Vector RAG works for questions whose answers are "localized within a small set of records." It fails on "global" questions about a whole corpus. Their approach has an LLM build an entity graph, cluster it into communities, and pre-summarize those communities. In their evaluation on roughly 1-million-token corpora, GraphRAG beat a vector RAG baseline on comprehensiveness and diversity of answers, while vector RAG gave more direct answers. Those were LLM-judged comparisons on podcast and news datasets, not legal documents, so treat them as directional.

For credit documents, we'd put it this way:

A graph tends to help when: - The answer depends on chains of definitions or cross-references (capacity calculations, EBITDA definitions, voting thresholds). - You need to compare structure across many agreements: "which of our 120 deals lack a guarantor-release protection?" is a corpus-level question. - You need to track amendments over time against specific provisions. - You want auditability, showing exactly which clauses were traversed.

Plain RAG is usually fine when: - The question is local: "what's the maturity date," "what's the applicable margin step-down," "who is the admin agent." - You're working on a single short document. - The cost of building and maintaining the extraction isn't justified.

There's also a middle path that many teams will find more practical than full GraphRAG: a light structural graph built deterministically (section hierarchy, defined term → section where defined, "Section X.YY" references parsed with regex), with LLM extraction used only for baskets and their parameters. The deterministic part is cheap and reliable. The LLM part is where review effort should go.

Building blocks

• Microsoft GraphRAG (GitHub): open-source pipeline for LLM graph extraction plus community summaries. It's designed for general corpora, so expect to tune prompts and entity types for legal text. The paper notes it used exact string matching for entity matching. In credit, normalize defined terms carefully ("Consolidated EBITDA" vs "EBITDA").
• Neo4j GraphRAG tooling (ecosystem overview, neo4j-graphrag Python package docs): graph construction from text, retrievers that combine vector search with graph traversal, and text-to-Cypher.
• Frameworks such as LangChain and LlamaIndex, which the GraphRAG paper notes also offer GraphRAG-style integrations.

A practical agent design

1. Parse the agreement into sections and clauses, keeping section numbers as stable IDs.
2. Deterministic pass: defined terms and where they're defined; every "Section X" reference as an edge.
3. LLM pass: for each covenant, extract baskets with type, fixed amount, grower percentage, ratio test, and reallocation/reclassification links. Store the source span for every extracted fact.
4. Validate: every edge must point to a node that exists, and every basket must cite text. Unresolved references go to a queue.
5. Query: the agent picks between a graph traversal (capacity, path or blocker questions) and plain retrieval (local facts), then answers with clause citations.
6. Diff on amendment: re-extract the amendment, attach a MODIFIES edge with an effective date, and show what changed in capacity or voting.

Caveats

• Extraction errors compound along paths. One wrong edge in a definition chain corrupts every answer that passes through it. Validation and review aren't optional.
• Capacity figures depend on financial inputs (EBITDA, total assets) that live outside the document. Link them explicitly and date them.
• None of this replaces counsel on a live LME situation. It tells counsel where to look first.

Next: graph use cases by sector, covering CLOs, secondaries, sponsor networks, fund finance and SRT.

Sources

1. arxiv.org ↗ https://arxiv.org/abs/2404.16130
2. www.microsoft.com ↗ https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
3. github.com ↗ https://github.com/microsoft/graphrag
4. neo4j.com ↗ https://neo4j.com/developer-blog/graphrag-ecosystem-tools/
5. neo4j.com ↗ https://neo4j.com/docs/neo4j-graphrag-python/current/

Educational content, not investment advice. Figures derived from SEC filings may contain errors: verify against the filing. Found an error? See the corrections log.