Agents underwrite inside a lending platform that has to be right.

Lenders in this space work with sellers who issue invoices to buyers and need cash before those invoices are paid. Underwriting has to read the applicant's financials, know the buyers, and understand the terms between them. Funding has to respect facility limits, agreement limits, and the rules each investor placed on their capital. Every movement of money has to be explainable later, to an accountant and to an investor.

The slow, expensive part is the reading. Financial statements, agings, and agreements arrive as PDFs in whatever shape the applicant's accountant produced them, and someone has to turn them into a credit view. That is the work the agents took on. The decisions stayed with people.

Onboarding and requests for information ask a client for specific documents. When the client uploads files through the portal, a model reads each one against the list of documents still outstanding, identifies what it is, records a short summary, and marks the matching requirement as received. The client sees what each upload was recognised as. Staff stop sorting PDFs.

Financial documents then go through a document parser that extracts text and entities, and a classifier that identifies the statement type. Banking data arrives through a direct connection to the client's bank, and accounting data through a connection to their accounting system. The reconciliation flows match an invoice document to a receivable, a bank transaction to a collection, and the client's receivables ledger to the platform's own view, so staff review differences rather than retyping figures.

The credit pipeline runs three agents in sequence. Each one receives the output of the one before it, and each gate can stop the pipeline early, so a weak file never consumes the expensive passes.

1. 01

   Financial analyst

   Reads the extracted statements, spreads them into typed line items and ratios, identifies the period, and returns a verdict on whether the applicant qualifies for underwriting at all.

   Gate A. Underwriting only runs on a qualified file. A decline or a request for more information stops here, before the expensive pass.

2. 02

   Underwriting

   Forms the credit view: a recommendation from a closed set of approve, conditional approve, more information, or decline, a risk rating, the strengths, concerns, conditions, and the information still required.

   Gate B. A declined credit view does not proceed to a risk review.

3. 03

   Risk and compliance

   Checks the proposed deal against policy: concentration against limits, covenant and borrowing-base checks, KYC, AML, sanctions and ownership findings, fraud indicators, and the conditions a deal would need.

   Gate C. The final verdict is clear, clear with conditions, or block. Risk can stop a deal the credit view approved.

The accumulated outputs form a case. In the back office, the analyst, underwriting, and risk verdicts appear in the decision panel beside the actions a credit officer can take. The agents inform the decision. The officer makes it, and the audit log records who did.

A model that sounds confident is not the same as a model that is right. The platform treats agent output as a claim to be checked.

• Every agent returns a structured record through a tool call, not prose. Recommendations and verdicts are enumerations, confidence is a number from zero to one, and findings are typed lists. A person can check the output field by field.
• Every extracted figure is checked against the source text the document parser produced. A number the agent reports that cannot be found in the document is flagged for human review instead of flowing into a decision.
• A deterministic reviewer checks the accounting identities in code, never with a model. A figure can appear in the document and still be mapped to the wrong line, and the identities catch that.
• An evaluation harness scores the underwriting agent against ten synthetic cases, each built to catch a specific failure: a bar that drifts permissive, invented risk on a clean file, a seasonal trough read as steady state, fabricated receivables. Scoring is deterministic, with no judge model, so the gate does not flake. It runs when a prompt or skill changes.
• Every run is stored and keyed by the document, the agent, its version, and a hash of the input. An identical request returns the stored assessment. A changed prompt or model invalidates it. Token usage and estimated cost are logged per agent, per client, and per document.

Sellers and staff see different software served by one API. The client portal covers onboarding, buyer agreements, advance and draw requests, document upload, requests for information, and balances. The back office covers underwriting, funding, collections and reconciliation, investor and SPV management, covenant configuration, and reporting. Internal risk, investor, and covenant data never reaches the client side, and each portal authenticates against its own identity application so a client token cannot call staff routes.

Funding comes from capital providers pooled into special-purpose vehicles. An advance is distributed across the SPV's providers pro rata, capped by each provider's available credit, allocation bounds, and two layers of covenants, with the tightest rule winning and any shortfall reported rather than absorbed. Covenants are also monitored on a schedule, because a book can drift into breach without a new deal. Breaches, late deliverables, and cash dominion events raise facility alerts that reach an officer, and collections can sweep against a revolver when dominion is in force. Covenant evaluation and allocation are pure functions with no database access, which is what makes them testable and legible.

Most of what makes the platform trustworthy is a short list of conventions enforced by the build rather than by memory.

• Money is stored as 64-bit integers in micro-units. There are no decimal columns and no floating-point money.
• Rates and percentages use the same integer convention, so a developer never has to remember which scale applies.
• Every funding, collection, and fee event posts a balanced journal entry. Unbalanced entries are rejected before they are saved.
• Posting is idempotent on the event that caused it, so a retried webhook or a double click cannot double-fund a receivable.
• The lifecycle documents that describe the accounting are generated from the same code that runs in production, and the build fails if they drift.

A funded receivable follows one identity: face value equals the advance paid to the seller, plus the reserve held, plus the fee. The journal records exactly that, every time.

The agents read, extract, spread, assess, and check. They identify documents, turn statements into typed figures, form a credit view, test it against policy, and put a structured case in front of a person. They also refuse to proceed when a gate fails, which is a decision of a kind, but a conservative one that only ever stops the pipeline.

Approving a client, setting a credit limit, funding an advance, releasing a reserve, and anything that changes the terms of a deal stay with a person. So does every movement of money. The ledger, the covenant engine, and the allocation engine are deterministic code with unit tests, not models. Where a wrong answer would cost money or a regulatory finding, there is no model in the loop.

This is the pattern CollectDev builds for clients: practical AI inside a system that already has to be right, with the model doing the reading and the people and the code doing the deciding.

• TypeScript throughout
• Express and Prisma API on Cloud Run
• Two Next.js portals on Vercel
• PostgreSQL
• Clerk authentication, one application per portal
• Anthropic models with tool-calling for the agents, each defined by an instruction file and a set of skills
• Google Document AI for extraction
• Bank and accounting-system connections for client data
• Unit tests for domain math, an evaluation harness for the agents, integration tests against a real database branch

The point of listing the stack is not the stack. It is that each piece is ordinary and well understood, so the unusual parts of the system, the money, the rules, and the agents, get the attention.