Agent-Enabled Modernization of a Regional Insurer's Claims Platform 0. Supplied Facts and Explicit Assumptions Supplied facts are treated as authoritative: a 15-year-old platform with tightly coupled batch jobs and manual reviews; a mainframe claims database; COBOL batch services; REST APIs; a document management system; an OCR service; a policy administration platform; a fraud database; a payment gateway; a cloud analytics environment; limited mainframe change capacity; mandatory human approval above defined settlement thresholds; zero tolerance for unauthorized payments; and agent actions limited to explicit low-risk authorization boundaries. The following are assumptions, not facts. A1: threshold values and dispute definitions exist but were not supplied, so the design treats them as externally governed configuration. A2: change-data-capture or message-queue extraction from the mainframe database is technically feasible without altering COBOL logic. A3: the existing REST APIs cover some, not all, claim operations. A4: fraud screening currently combines database lookups with rules, and its exact logic is undocumented. A5: a cloud-hosted model service is permitted to process sensitive data under the insurer's regulatory posture, ideally in a private tenancy. Each assumption should be validated in Phase 0. 1. Legacy Assessment and Transformation 1.1 Reconstructed Workflow Claim intake receives submissions and creates a claim record. Document review is largely manual, supported by OCR, which converts documents into text stored in the document management system. Eligibility checks compare the claim against policy data held in the policy administration platform. Fraud screening consults the fraud database, with batch jobs and manual review behind it. Adjuster assignment is batch-driven. Settlement calculation runs in COBOL services. Payment approval precedes release through the payment gateway. The actors are claimants, intake staff, document reviewers, adjusters, fraud analysts, approvers, and operations staff running batch schedules. Data flows are batch-oriented: the mainframe claims database is the apparent system of record for claim state, while policy, document, fraud, and payment data live in adjacent systems. 1.2 Hidden Dependencies and Modernization Risks Batch coupling means a claim's progress depends on job schedules rather than on its own readiness, so latency is structural. COBOL services likely embed business rules that exist nowhere else, including rounding, coverage precedence, deductible ordering, and exception handling. These must be treated as undocumented until proven otherwise. Manual reviews probably carry implicit judgment, such as which document defects are tolerable, that never reached a written rule. The REST APIs and batch interfaces may have undocumented ordering assumptions, for example a job expecting a record to be in a particular status. The principal risks are silently changing settlement behavior, breaking batch sequencing, and losing audit lineage that the old process produced as a side effect. 1.3 Disposition by Responsibility Claim intake is split. Capture and record creation are wrapped behind a deterministic service, while classification of free-form content is delegated to an agent, since it is interpretation under ambiguity. Document review is split three ways. OCR is preserved as a service. Summarization and inconsistency detection become agent capabilities. Final acceptance of a document as evidence remains with humans for disputed or high-value claims and is automated only for defined low-risk document types. Eligibility is wrapped and exposed as a deterministic service. It is authoritative and rule-based, so no agent decides eligibility. Agents retrieve and present the evidence behind it. Fraud screening is retained as deterministic. The agent contributes cross-document inconsistency findings as additional signals, but it can neither clear nor suppress a fraud flag. Fraud analysts decide flagged cases. Adjuster assignment is refactored from batch into an event-triggered workflow step. A deterministic policy of skills, capacity, and conflict rules makes the assignment. The agent recommends it, and the workflow executes it only inside authorization limits. Settlement calculation is preserved in COBOL initially and wrapped as a deterministic service. Reimplementing it before characterization testing proves equivalence is a primary risk, so it is explicitly deferred. Payment approval is retained as a deterministic control with human approval above thresholds. No agent holds payment authority. The payment gateway is reachable only through the approval control. Manual coordination between specialists is automated through workflow, with an agent preparing review packets. The batch scheduling layer itself is eliminated progressively, only after its duties are re-homed. 2. Target Architecture and Mapping 2.1 Architectural Shape The architecture is a hybrid. A durable, deterministic workflow orchestrator owns the claim case lifecycle and state. Agents are invoked as bounded steps inside that workflow rather than as free-roaming coordinators. This choice follows from the regulatory and zero-unauthorized-payment constraints: the control flow must be auditable, replayable, and not model-determined. An event backbone carries claim events between components. A policy-enforced tool gateway is the only path by which any agent causes a side effect. 2.2 Agents and Their Boundaries Three agents are justified, and a fourth would add coordination cost without value. The Intake and Classification Agent reads incoming claim content and attachments and proposes claim type, apparent severity indicators, completeness gaps, and a structured intake record. Its tools are read access to the claim submission, OCR output, and a classification taxonomy. It may write only a proposed classification to case state. The Evidence Analysis Agent retrieves policy and claim evidence, summarizes documents, and detects inconsistencies, for example dates, amounts, or parties that disagree across documents or against policy data. Its tools are read-only retrieval over the document management system, the policy administration platform, and the claim read model. It produces cited summaries and findings, where every statement references a source document and location. The Case Coordination Agent recommends routing and next actions, drafts review packets for specialists, and requests low-risk workflow actions. It consumes the outputs of the other two agents and deterministic service results. It can submit action requests only to the tool gateway. Eligibility, fraud screening, settlement, and payment are not agents. The orchestrator itself plays the supervisor role, so no agent supervises another. 2.3 Mapping from Legacy to Target The mainframe claims database stays authoritative for claim state during migration. The workflow orchestrator becomes authoritative for case process state, meaning where a claim is in its journey, with synchronization to the mainframe through the adapter. COBOL settlement logic remains authoritative for settlement amounts, now behind a service wrapper. The policy administration platform remains authoritative for policy data. The fraud database remains authoritative for fraud indicators. The document management system remains authoritative for documents. Agent outputs are derived and advisory, never authoritative. Batch jobs shrink as their duties move: intake triggers and assignment first, other jobs later. 3. Data, Knowledge, Integration, and State 3.1 Data Classes Authoritative data comprises claim records, policy data, fraud indicators, documents, settlement results, and payment records, each owned by its existing system. Derived knowledge comprises OCR text, summaries, classification proposals, inconsistency findings, and embeddings or indexes for retrieval, all regenerable and stamped with provenance: source document version, model version, prompt version, and timestamp. Temporary context comprises per-step agent working context, discarded after the step except for what is written to the audit record. 3.2 Memory and Knowledge Agents carry no cross-claim memory about customers. Each invocation receives only that claim's authorized context, which limits data leakage and stale-context risk. Business knowledge, such as coverage guidance, handling procedures, and the classification taxonomy, is held in a versioned knowledge store with controlled publication. Retrieval for claim evidence is scoped to the claim's own documents and its policy. Retrieved material carries version identifiers, and the orchestrator invalidates and refreshes context when a source changes during the case. 3.3 Integration Layer An anti-corruption layer sits in front of the mainframe. Reads are served from a cloud-side read model fed by change-data-capture or queue extraction (A2), so agents and analytics never query the mainframe directly, which protects its limited change capacity and availability. Writes go through narrow adapters that call existing REST APIs or place messages for COBOL consumption, each carrying an idempotency key and a correlation identifier. Unrestricted legacy access is not offered to any agent. The cloud analytics environment receives events and the read model for reporting and for monitoring agent quality, and holds no authority over operations. 3.4 Consistency, Failure, and Transactions Cross-system consistency uses the saga pattern: each step has a defined compensating action or a defined escalation to a human where compensation is impossible, such as a released payment. Every write is idempotent, with timeouts and bounded retries using backoff, and a dead-letter path routes unresolved items to a human queue instead of retrying indefinitely. Read-model staleness is bounded and measured. Any action whose precondition depends on current mainframe state revalidates against the authoritative system at execution time. Schemas for events and tool contracts are versioned, and consumers tolerate additive change. 3.5 Retention and Data Protection Sensitive customer data is minimized before any model call, with redaction of fields not needed for the task. Retention follows regulatory schedules (assumed, to be supplied by compliance). Agent prompts, retrieved context references, and outputs are retained as audit evidence for the same period as the claim record, though content may be stored as references to documents rather than copies. 4. Autonomy, Security, Reliability, and Governance 4.1 Autonomy Tiers Agents may observe within a claim's authorized scope, reason, summarize, and recommend. They may execute only actions classified as low-risk, reversible, non-financial, and internal, for example attaching a summary to a case, setting a document-type tag, placing a claim in a work queue, or scheduling a review task. Templated customer communications requesting missing documents are customer-impacting, so they begin in human-approved mode and move to autonomous only after measured accuracy justifies it (a governance decision, not an assumption of capability). Agents may never approve or release payment, change settlement amounts, clear or suppress fraud flags, deny or approve eligibility, alter policy data, change thresholds or their own permissions, or close disputed claims. High-risk, irreversible, financially significant, and security-sensitive actions always require a human decision. Settlements above the defined thresholds require mandatory human approval, and the approval control enforces this independently of any agent output. Disputed claims route to humans regardless of value. Autonomy expands only per action type, based on observed reliability, such as override rates and error rates in shadow and supervised operation, together with confirmed observability and authorization coverage. Autonomy can be revoked per action type instantly through configuration. 4.2 Security Controls Each agent runs under its own service identity with least privilege: read scopes limited to the claim in context and write scopes limited to proposing results. Authorization is enforced in the tool gateway, which validates every request against policy, caller identity, claim scope, action class, and current claim state. The gateway is deterministic code and does not rely on the model to obey instructions. Secrets are held in a managed vault and never appear in prompts. Document content is treated as untrusted input, since claim documents may contain text that attempts to manipulate the agent. Agents therefore have no ability to act outside gateway-mediated tools, tool arguments are schema-validated, and agent outputs are never interpreted as commands. Data in transit and at rest is encrypted, and access to sensitive fields is logged. 4.3 Reliability and Observability Every step emits traces tying together the claim, workflow step, model and prompt versions, retrieved sources, tool requests, gateway decisions, and human actions. Monitoring covers latency, queue depth, retry and dead-letter rates, gateway denials, agent-to-human disagreement, and drift in classification distributions. Failures are isolated by bulkheads: an agent or model outage degrades to the existing manual path and does not halt claims, and the workflow can run with agents disabled. Rollback of a model or prompt version is a configuration change. Incidents involving a wrong action trigger suspension of that action's autonomy, containment by compensation where possible, and post-incident review. 4.4 Principal Agent Risks Hallucination in summaries can mislead reviewers, so every statement carries a source citation, the review interface shows the source alongside it, and uncited claims are rejected. Incorrect tool use is bounded by schema validation, narrow tool scope, and gateway policy. Unauthorized action is prevented structurally, because the capability does not exist in the agent's tool set. Stale context is addressed by version stamps and revalidation. Cascading failure is limited by orchestrator-owned control flow, with agents unable to trigger other agents. Coordination errors are limited by having the orchestrator and not the agents arbitrate. Uncontrolled autonomy is prevented by per-action tiers with central revocation. 5. Decisions, Risks, Migration, and Implementation 5.1 Consequential Decisions First, a deterministic orchestrator rather than an agent supervisor. Alternatives were a supervisor-worker agent mesh or fully event-choreographed agents. Both give more flexibility but weaker auditability and a harder path to proving no unauthorized payment is possible. This choice would be revisited only if workflow variety grows beyond what explicit definitions can express, and even then agents would propose workflow steps without executing them. Second, retaining COBOL settlement logic behind a wrapper initially. Rewriting is tempting but risks silent behavioral divergence in financial outcomes. Revisit after characterization tests give high-confidence equivalence evidence, and then only via parallel run. Third, a read model fed by extraction rather than direct mainframe queries. This protects mainframe capacity and availability at the cost of bounded staleness, mitigated by revalidation on write. Fourth, three agents rather than many. Each exists because its work is interpretive; more would add coordination overhead without distinct capability. Fifth, deterministic eligibility and fraud decisions with agents as evidence providers. The trade is lower flexibility for explainability and regulatory defensibility. Technology selection follows requirements: a durable workflow engine with persisted state and replay for the orchestrator, an event broker with durable delivery for the backbone, a vector or hybrid index only where document retrieval needs it, and a model service meeting the data-residency posture (A5). Specific products should be chosen against the insurer's existing platforms and compliance constraints, which were not supplied. 5.2 Failure Modes and Anti-Patterns Agentizing deterministic rules would add nondeterminism where correctness is required, so eligibility, calculation, and approval stay as code. Excess autonomy risks unauthorized actions and is countered by tiers and the gateway. Duplicated logic between agents and COBOL would create divergence, so rules live in one place. Weak state, such as case state held in prompts, would break recovery, so state lives in the orchestrator. Uncontrolled tools are prevented by the gateway. Over-orchestration, such as many fine-grained steps, raises latency and fragility, so steps map to business milestones. Poor legacy integration, such as direct database access, would threaten mainframe stability, so adapters are mandatory. Hidden coupling to batch ordering is surfaced in Phase 0. Weak observability would make audit impossible, so tracing is a release criterion. Inadequate human oversight is avoided by mandatory approvals and measured override rates. Premature retirement of batch or COBOL components is avoided through explicit exit criteria. 5.3 Migration Plan Phase 0, discovery and baselining, comes first. It documents actual batch dependencies and job sequencing, builds characterization tests around COBOL settlement and eligibility behavior using historical claims, catalogs manual-review decision patterns, validates assumptions A1 to A5, and establishes baseline processing time, error, and override metrics. Nothing in production changes. Phase 1, shadow operation, deploys the read model, the adapters in read-only mode, and the three agents producing advisory output alongside the existing process. Humans see nothing or see it as optional. Measured agent accuracy against human outcomes defines readiness. The legacy flow remains the sole decision path. Phase 2, assisted operation, introduces the orchestrator for intake and document review, with agent summaries and routing recommendations shown to staff, and with low-risk gateway actions enabled one action type at a time. Settlement, eligibility, fraud, and payment remain untouched in legacy. Phase 3 decomposes batch responsibilities that are proven safe: assignment and queue management move to event-driven workflow, and eligibility and settlement are exposed as services through wrappers. The batch jobs run in parallel with the new path, with outcome comparison, until equivalence criteria are met. Phase 4 retires individual batch jobs only after sustained parallel-run equivalence, tested rollback, and operational readiness, with the COBOL settlement logic retained until a separate, evidence-based decision is made. The payment approval control and human thresholds persist indefinitely. Rollback at each phase is a switch back to the legacy path, which remains operable until its retirement criteria are met. Data migration is limited: the mainframe remains authoritative, so migration concerns the read model and derived stores, which are rebuildable. Workstreams run in parallel: integration engineering, workflow and agent engineering, security and compliance, evaluation and quality, operations readiness, and staff change management. Measurable progression criteria include agent-human agreement rates by claim type, gateway denial and error rates, end-to-end cycle time, parallel-run discrepancy rates (target zero for financial outputs), audit completeness, and incident counts. Autonomy expands only when these criteria hold over a defined observation period. 6. Target-State Execution and Rationale 6.1 Target Components Claims enter through intake channels, creating a claim record via the intake service and emitting a claim-received event. The workflow orchestrator creates a case and owns its process state. The integration layer provides the read model, legacy adapters, and an event backbone. The three agents operate through the tool gateway. Deterministic services provide eligibility, fraud screening, settlement calculation (COBOL wrapped), and payment approval. The document management system and OCR service handle documents. The policy administration platform and fraud database remain systems of record. Humans interact through review workspaces for adjusters, fraud analysts, and approvers. The audit and observability layer records every step, and the cloud analytics environment supports quality monitoring and reporting. 6.2 End-to-End Flow A claim arrives and the intake service records it and emits an event. The orchestrator starts the case and sends documents to OCR. The Intake and Classification Agent proposes a classification and identifies completeness gaps. A deterministic validation checks the proposal against the taxonomy and rules. Low-confidence or conflicting classifications go to an intake human. The Evidence Analysis Agent retrieves policy data and claim documents, produces cited summaries, and flags inconsistencies. Meanwhile the orchestrator calls the eligibility service and the fraud screening service. Any fraud flag or high-severity inconsistency routes the case to the fraud analyst, who alone can clear it. The Case Coordination Agent consumes those results and recommends routing, next actions, and specialist reviews, producing a review packet. The orchestrator, not the agent, applies deterministic assignment policy. Low-risk actions the agent requests go through the gateway, which authorizes, validates preconditions against authoritative state, applies an idempotency key, executes, and records the outcome. Disallowed or out-of-scope requests are denied and logged. The adjuster reviews the packet and evidence and makes coverage decisions. The settlement service computes the amount deterministically using COBOL logic. The payment approval control checks the amount against thresholds and dispute status. Anything above threshold or disputed requires a human approver, who sees the calculation inputs, evidence, and flags. Only an approved, validated, idempotent payment instruction reaches the payment gateway. The orchestrator then updates case state, synchronizes the mainframe record through the adapter, emits completion events, and finalizes the audit record. Failures at any step invoke retries, compensation, or human escalation per the defined policy. 6.3 Rationale The highest-value opportunities are in the interpretive, labor-intensive front half of the process: classification, document summarization, inconsistency detection, and routing preparation. These reduce cycle time and improve consistency without touching financial authority. The main constraints are the zero tolerance for unauthorized payment, regulatory auditability, limited mainframe change capacity, and mandatory human oversight, and these drive the central decisions: a deterministic orchestrator, a gateway as the sole route to side effects, wrapped rather than rewritten COBOL, and a read model instead of direct legacy access. The critical risks are silent divergence in financial rules, agent misinformation, prompt injection through documents, and premature autonomy. These are countered by characterization testing and parallel runs, cited and verifiable outputs, structural capability limits, and per-action autonomy that grows only on measured evidence. The governing principles are that agents recommend while deterministic controls decide, that authority is never inferred from model output, that every action is traceable, and that legacy components retire only when the evidence says they can.