How to analyze a credit agreement with AI

A credit agreement is not a document you read once. It is a rulebook that gets consulted — under time pressure, usually about one specific question — for as long as the credit exists. "Can the borrower incur this debt?" "Does this asset sale trigger a sweep?" "Could lenders be primed here?" The document was written to answer those questions, but it was not written to make them easy to find.

That gap is what makes credit agreements a natural target for AI, and also what makes most attempts at it disappointing. The useful framing is narrow: the job is not to understand the agreement in some general sense. The job is to locate, extract, and cite the provisions that govern a specific decision.

What does analyzing a credit agreement actually mean?

Ask a credit analyst what they do with a new agreement and the answer is rarely "read it." It is closer to: find the baskets, size the capacity, check the guarantor structure, look at what the voting provisions protect, and see which of the known structural vulnerabilities are blocked.

That work is more mechanical than it sounds. The questions are largely the same across agreements. What differs is where the answers live, how the defined terms are constructed, and what the negotiated exceptions carve out. This is why "summarize this credit agreement" is close to useless as a task — a summary tells you the document has a restricted payments covenant. It does not tell you how much room is in it.

So the unit of work is a provision, not a page. And the deliverable for each provision is a value plus the language that supports it. An answer without its source language cannot be checked, and anything that cannot be checked cannot be relied on in a credit decision.

Which provisions are worth extracting?

Below is the field schema we extract against for a credit agreement — a representative view of a 72-field structured schema, grouped by what each group answers. It is not a generic outline; it is the actual working set, and the specificity is the point. "Debt covenant" is not a field. "Ratio debt capacity, tested pro forma, with the incurrence test and its exceptions" is.

Two things about that list are worth drawing out.

First, the LME blockers are named after transactions, not concepts. J.Crew, Serta, Chewy, Envision, Pluralsight, NYDJ, Incora, At Home — each entered the vocabulary because a borrower found a path the drafters had not closed, and subsequent agreements began closing it explicitly. Their presence or absence in a given agreement is a factual question with a specific answer, and it is one of the highest-value things to know about a credit. This is also why the list keeps growing: the taxonomy is downstream of what actually happened in the market.

Second, the voting section carries seventeen separate fields rather than one. "Requires 100% consent" is not an answer, because agreements differ on precisely which actions get sacred-right protection. Whether releasing all or substantially all collateral requires unanimity, and whether open-market purchases carry voting rights, are different questions with different consequences, and an analysis that collapses them is not usable.

Why do general-purpose models struggle with the document?

The common assumption is that the model is not smart enough. It usually is. In our experience the problem is usually that it never saw the governing language.

Three specific mechanisms:

Defined terms. The operative meaning of a sentence in Section 7.02 frequently depends on a definition in Section 1.01 that has itself been negotiated. "Consolidated EBITDA" in one agreement is not the same quantity as in another — the addbacks, the synergies cap, the lookback period are all bespoke. A model reading the covenant without resolving the definition is reading a different covenant.

Cross-references. Baskets reference other baskets. An exception in the negative covenant points at a schedule; the schedule points at a defined term; the defined term carries a proviso. Answering the original question requires following the whole chain, and a model working from a retrieved excerpt does not have it.

Amendments. The operative document is usually not one document. It is the original agreement plus a stack of amendments, each restating some provisions and leaving others intact. Answering a question about current capacity means knowing which version of a section is live — which is a document-lineage problem before it is a reading-comprehension problem.

None of these are reasoning failures. They are retrieval and structure failures, and they are fixable by giving the model the right material rather than a better prompt.

How should the work be structured?

The pattern that holds up:

1. Resolve the document set first. Establish which agreement governs and which amendments are operative before extracting anything. An answer from a superseded section is worse than no answer.
2. Extract against a fixed schema, not an open prompt. A known field list makes results comparable across credits and makes gaps visible. An open-ended summary hides what it missed.
3. Require a citation per field. Every extracted value carries the quoted language and its location. This is the single most important constraint, because it converts a claim into something a person can check in seconds.
4. Treat absence as a finding. "This agreement has no J.Crew blocker" is a real, valuable answer. A system that only reports what it found cannot distinguish absence from failure to look.
5. Verify quotes against the source. A quotation that does not appear verbatim in the document should be caught mechanically rather than trusted. Verification of this kind is necessary but not sufficient: a genuine quote can still be superseded by an amendment, drawn from an inapplicable subsection, or normalised into the wrong value.

The through-line is that the useful output is not prose. It is a structured, cited set of values that a person can audit quickly and disagree with specifically — which is exactly what a credit memo needs and exactly what a chat transcript is not.

Where this leaves the tooling question

If you are evaluating whether to use AI on credit documents, the question to ask is not how good the model is. It is what the system does about defined terms, cross-references, and amendment lineage, and whether every answer arrives with language you can check. Those are the parts that determine whether the output survives contact with a real credit decision.