How to Build a claims processing Agent Using AutoGen in TypeScript for lending

A claims processing agent for lending takes in borrower claims, checks the claim against loan records and policy rules, asks for missing evidence, and routes valid cases to the right downstream system. It matters because lending operations are full of exceptions: payment disputes, hardship claims, fee reversals, insurance-backed claims, and servicing complaints all need consistent handling with a clear audit trail.

Architecture

• •

  Ingress API

  • •Receives claim payloads from a lending portal, CRM, or servicing platform.
  • •Normalizes fields like loanId, borrowerId, claimType, attachments, and jurisdiction.
• •

  Policy retrieval layer

  • •Pulls lending policy snippets, product terms, and jurisdiction-specific rules from a controlled source.
  • •Keeps the agent grounded in approved language instead of free-form reasoning.
• •

  AutoGen agent pair

  • •A claims triage agent classifies the claim and decides what evidence is missing.
  • •A review/approval agent validates compliance-sensitive decisions before anything is finalized.
• •

  Tool layer

  • •Functions for loan lookup, document verification, case creation, and audit logging.
  • •Tools should be deterministic and return structured JSON.
• •

  Audit and supervision

  • •Every decision gets logged with timestamps, input hashes, model version, and tool outputs.
  • •Human review is required for denials, write-offs, or any adverse action.

Implementation

1) Install AutoGen and define the claim schema

Use the TypeScript AutoGen package and keep your input contract strict. For lending workflows, schema discipline matters because bad input becomes bad decisions.

npm install @microsoft/autogen typescript zod

import { z } from "zod";

export const ClaimSchema = z.object({
  claimId: z.string(),
  loanId: z.string(),
  borrowerId: z.string(),
  claimType: z.enum(["payment_dispute", "fee_reversal", "hardship", "insurance_claim"]),
  jurisdiction: z.string(),
  amount: z.number().nonnegative(),
  evidenceUrls: z.array(z.string().url()).default([]),
});

export type ClaimInput = z.infer<typeof ClaimSchema>;

2) Create tools for loan lookup and audit logging

The agent should not “guess” loan status. It should call tools that hit your servicing system or a read replica. In production lending systems, these tools are where compliance boundaries live.

import { AssistantAgent } from "@microsoft/autogen";

type LoanRecord = {
  loanId: string;
  status: "current" | "delinquent" | "charged_off";
  productType: string;
  state: string;
};

async function getLoanRecord(loanId: string): Promise<LoanRecord> {
  // Replace with a real service call
  return {
    loanId,
    status: "current",
    productType: "personal_loan",
    state: "CA",
  };
}

async function writeAudit(event: unknown): Promise<void> {
  console.log(JSON.stringify(event));
}

const triageAgent = new AssistantAgent({
  name: "claims_triage_agent",
  systemMessage:
    "You triage lending claims using only provided facts. If data is missing, request it. Never approve adverse actions without escalation.",
});

3) Build the AutoGen workflow around structured inputs

The pattern here is simple: validate input, fetch authoritative data, send a constrained prompt to AutoGen, then persist every step. Use the model for classification and next-step recommendation; keep policy enforcement in code.

import { ClaimSchema } from "./schema";

export async function processClaim(rawClaim: unknown) {
  const claim = ClaimSchema.parse(rawClaim);
  const loan = await getLoanRecord(claim.loanId);

  const prompt = `
Claim:
${JSON.stringify(claim)}

Loan record:
${JSON.stringify(loan)}

Task:
1. Classify the claim.
2. Decide whether more evidence is needed.
3. Return JSON with keys:
   - decision: "approve_review" | "needs_info" | "escalate"
   - reason
   - missingEvidence: string[]
   - complianceFlags: string[]
`;

  const response = await triageAgent.sendMessage(prompt);
  const text = typeof response === "string" ? response : JSON.stringify(response);

  await writeAudit({
    claimId: claim.claimId,
    loanId: claim.loanId,
    modelResponse: text,
    jurisdiction: claim.jurisdiction,
    productType: loan.productType,
    timestamp: new Date().toISOString(),
  });

  return text;
}

4) Add a human-review gate for sensitive outcomes

In lending, an automated agent can prepare a recommendation, but not all decisions should be auto-executed. Denials, fee reversals above threshold, hardship exceptions, and anything tied to fair-lending risk should go to a human queue.

type Decision = {
  decision: "approve_review" | "needs_info" | "escalate";
};

export async function routeDecision(resultText: string) {
  const result = JSON.parse(resultText) as Decision;

  if (result.decision === "escalate") {
    return {
      nextStep: "human_review",
      reason:
        "Sensitive lending outcome requires manual review before customer communication.",
    };
    }

  if (result.decision === "needs_info") {
    return {
      nextStep: "request_borrower_documents",
      reason: "Missing evidence must be collected before adjudication.",
    };
  }

  return {
    nextStep: "prepare_case_summary",
    reason: "Claim can move to supervised review.",
  };
}

Production Considerations

• •

  Data residency

  • •Keep borrower PII inside the required region.
  • •If your lender operates across states or countries, pin model endpoints and vector stores to approved jurisdictions.
• •

  Auditability

  • •Store the exact prompt context, tool outputs, model version, and final routing decision.
  • •Regulators care about why a claim was handled a certain way months later.
• •

  Guardrails

  • •Block unsupported outcomes in code.
    • •Example: no automatic denial on incomplete evidence.
    • •Example: no write-off above threshold without approval.
• •

  Monitoring

  • •Track escalation rate, missing-document rate, average time to resolution, and override frequency by reviewer.
  • •A spike in overrides usually means your prompts or policies drifted.

Common Pitfalls

1. •

   Letting the model make final compliance decisions

   • •Don’t ask AutoGen to “decide if this violates policy” without code-based rules around it.
   • •Use the model for extraction and summarization; use deterministic logic for thresholds and approvals.
2. •

   Passing raw borrower data into every prompt

   • •Minimize PII in prompts.
   • •Send only what’s needed for triage and keep sensitive fields behind tool calls with access control.
3. •

   Skipping jurisdiction-specific logic

   • •Lending claims vary by state law, product type, and servicing agreement.
   • •Build rule branches for state-level disclosures, notice periods, fee treatment, and adverse action requirements before you scale beyond one market.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.