How an HR Tech Platform Automated Benefit Plan Ingestion from Unstructured PDFs

This HR technology platform powers benefits administration for employers and their workforces, managing complex data flows across health, dental, vision, and ancillary benefit plans. As its partner network grew, so did the volume and variety of carrier-submitted documents. Manual processing had become a capacity constraint and a source of risk sensitive benefit data demands accuracy and speed that hand-processing cannot guarantee at scale. The platform committed to an automated intelligent document processing pipeline that could scale with its partner network without scaling operational headcount.

Protagona set out to extend an existing intelligent intake platform to treat PDF documents as a first-class input type alongside Excel workbooks. The pipeline needed to ingest, extract, validate, and store plan and rate data from multi-document partner submissions, produce a single consistent output conforming to a defined contract, and route results to a web application for human review.

The core complexity was not simply reading PDFs. Unlike Excel workbooks, where established field conventions guide extraction, PDFs require the system to infer meaning from unstructured prose. A field like 'run-out period' may not appear as a labeled value it may be embedded in narrative text and require contextual comprehension to surface and map correctly. Building a pipeline that handles this inference reliably across a diverse corpus of carrier formats demanded careful separation of AI inference from deterministic control logic. The architecture also needed to handle multi-document uploads where plan files and rate tables arrive as separate PDFs and must be reconciled into a single session-level result, ensuring a problematic section in one document cannot corrupt the broader batch all while keeping per-document latency within a tight budget.

Protagona designed a fan-out and fan-in AgentCore pipeline where a single multi-PDF upload spawns independent per-document processing graphs that run through discovery and extraction stages before converging into a session-level reconciliation step. Each extraction call receives only the page range relevant to its section, so a malformed or ambiguous section cannot affect the rest of the batch a deliberate accuracy decision, not just a performance optimization.

A strict boundary separates deterministic code from AI inference. The LLM is invoked at exactly five call sites: section discovery classification, per-plan extraction, per-rate extraction, optional general-information resolution, and reconciliation. Everything else carrier detection, tier normalization, plan-to-rate pairing, plan ID assignment, inline validation, and output transformation runs as deterministic Python, making defects traceable and fixable in code. Model selection is tiered by task: Haiku handles classification during discovery; Sonnet handles accuracy-critical extraction and reconciliation. The architecture is also positioned for document-level parallelism, which would reduce total wall-clock time from roughly N times one document's latency to approximately one document's latency.