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

A claims processing agent for payments takes a claim, validates the request against policy and transaction data, checks for fraud or duplication, and routes the case to approval, rejection, or human review. For payments teams, this matters because claims are where money leaves the system under pressure: you need speed, traceability, and controls that satisfy compliance and audit requirements.

Architecture

• •

  Claim intake service

  • •Accepts claim payloads from API, queue, or case-management UI.
  • •Normalizes fields like claimId, paymentId, amount, currency, merchantId, and reasonCode.
• •

  AutoGen orchestrator

  • •Coordinates specialized agents using GroupChat and GroupChatManager.
  • •Keeps the workflow deterministic enough for payments operations.
• •

  Policy validation agent

  • •Checks eligibility rules, time windows, thresholds, and required evidence.
  • •Enforces payment-specific policy constraints before any payout decision.
• •

  Fraud/risk review agent

  • •Flags duplicate claims, suspicious velocity patterns, mismatched identities, and abnormal refund behavior.
  • •Produces a risk score plus explanation for audit.
• •

  Decision executor

  • •Converts the final decision into a structured action: approve, deny, or escalate.
  • •Writes an immutable audit record with model output and rule outcomes.
• •

  Human review queue

  • •Handles exceptions where confidence is low or regulated decisions require manual approval.
  • •Keeps a clean separation between AI assistance and final authorization.

Implementation

1) Install AutoGen for TypeScript and define your claim schema

Use the TypeScript AutoGen package from Microsoft. Keep your schema strict; claims systems fail when the agent starts improvising field names.

npm install @microsoft/autogen openai zod

import { z } from "zod";

export const ClaimSchema = z.object({
  claimId: z.string(),
  paymentId: z.string(),
  amount: z.number().positive(),
  currency: z.string().length(3),
  merchantId: z.string(),
  reasonCode: z.string(),
  submittedAt: z.string(),
  evidenceUrls: z.array(z.string()).default([]),
});

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

2) Create specialized agents with explicit system messages

For payments workflows, don’t use one general-purpose agent. Split responsibilities so each agent has one job and one prompt boundary.

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

const policyAgent = new AssistantAgent({
  name: "policy_agent",
  systemMessage: `
You validate payment claims against policy.
Return only JSON with:
{
  "decision": "approve" | "deny" | "escalate",
  "reason": string,
  "policyChecks": string[]
}
Never invent missing data. If required fields are missing, escalate.
`,
});

const riskAgent = new AssistantAgent({
  name: "risk_agent",
  systemMessage: `
You assess fraud and operational risk in payment claims.
Return only JSON with:
{
  "riskScore": number,
  "flags": string[],
  "recommendation": "approve" | "deny" | "escalate"
}
Focus on duplication, velocity anomalies, inconsistent evidence, and chargeback patterns.
`,
});

const coordinatorAgent = new AssistantAgent({
  name: "coordinator_agent",
  systemMessage: `
You combine policy and risk outputs into a final claim decision.
Return only JSON with:
{
  "finalDecision": "approve" | "deny" | "escalate",
  "summary": string
}
If policy or risk recommends escalate, do not override without strong justification.
`,
});

3) Run the agents in a GroupChat workflow

This pattern gives you traceable multi-agent reasoning without turning the system into an uncontrolled chat loop. Keep max rounds low for production claims flows.

import { GroupChat } from "@microsoft/autogen";
import { GroupChatManager } from "@microsoft/autogen";
import OpenAI from "openai";
import { ClaimSchema } from "./schema";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

async function processClaim(rawClaim: unknown) {
  const claim = ClaimSchema.parse(rawClaim);

    const groupChat = new GroupChat({
    agents: [policyAgent, riskAgent, coordinatorAgent],
    messages: [],
    maxRounds: 3,
    speakerSelectionMethod: "round_robin",
    allowRepeatSpeaker: false,
    });

    const manager = new GroupChatManager({
    groupchat: groupChat,
    llmConfig: {
      modelClientClass: OpenAI,
      modelClientOptions: {
        apiKey: process.env.OPENAI_API_KEY!,
        model: "gpt-4o-mini",
      },
    },
    });

    const initialMessage = `
Review this payment claim:
${JSON.stringify(claim)}
`;

    const result = await manager.run(initialMessage);
    return result;
}

processClaim({
  claimId: "clm_10001",
  paymentId: "pay_90001",
  amount: 49.99,
  currency: "USD",
  merchantId: "mrc_123",
  reasonCode: "DUPLICATE_CHARGE",
  submittedAt: new Date().toISOString(),
});

4) Persist an audit trail before taking action

In payments, the agent output is not the source of truth. Your system needs a durable record of inputs, model outputs, timestamps, policy version, and final operator action.

type AuditRecord = {
  claimId: string;
  inputHash: string;
};

async function writeAuditRecord(record: AuditRecord) {
  
}

async function finalizeDecision(claimId:string,result:any){
 
}

In practice:

• •Store raw input in an encrypted datastore.
• •Hash sensitive payloads before logging.
• •Save model version and prompt version with every decision.
• •Require human sign-off for escalations above a threshold amount.

Production Considerations

• •Deployment isolation

Deploy the agent in a PCI-scoped service boundary if it touches card-linked data. Keep secrets in a vault and restrict outbound network access to approved model endpoints.

• •Monitoring

Track decision latency, escalation rate, false approvals, false denials, and duplicate claim detection rate. Emit structured logs with claimId, paymentId, decision, riskScore, and policy version.

• •Guardrails

Use strict JSON outputs plus schema validation before any downstream action. Add hard rules outside the model for amount thresholds, country restrictions, sanctions screening hits, and refund windows.

• •Data residency

Route claims to region-specific inference endpoints if your payments program has residency requirements. Never send full PANs or unnecessary personal data to the model; tokenize first.

Common Pitfalls

1. •

   Letting the model make final payout decisions

   • •Avoid this by making the agent recommend actions only.
   • •The execution layer should enforce business rules and human approval gates.
2. •

   Using one prompt for policy, fraud review, and execution

   • •This creates brittle behavior and weak auditability.
   • •Split responsibilities across agents with narrow system messages.
3. •

   Logging sensitive payment data in plain text

   • •This breaks compliance fast.
   • •Redact account details, tokenize identifiers, encrypt stored transcripts, and keep audit logs minimal but sufficient.
4. •

   Ignoring deterministic validation

   • •LLMs are not validators.
   • •Validate schema first with Zod or similar tooling before sending anything to AutoGen.

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.