Agents

Three places this claim-triage POC would break at enterprise scale The first two posts in this series covered where I draw the line between deterministic code and LLM judgment in a claim-triage agent, and the infrastructure that makes a “pause for a human” step durable enough to survive a process restart. Those were about what the system does and how it stays reliable. This one is about what it deliberately doesn’t do yet — because a proof of concept that only shows what works is a demo, and I want this repo to signal architectural judgment, not just implementation competence. ...

Reliability is an infrastructure problem, not a prompt problem In the first post of this series, I focused on where to draw the line between deterministic code and LLM judgment. Once those boundaries were set, the next challenge was making the system actually reliable. In the context of a claim triage agent, reliability isn’t just about the model giving the right answer—it’s about the system surviving the reality of how humans actually work. ...

I’ve been trying to build an agentic app, to understand the various trade offs design considerations involved. One thing I decided early on was to focus more on the design decisions and architecture, while letting Claude Code handle the coding bit. 🏢 Business Context In the insurance industry, the triage phase of a claim—determining coverage, verifying identity, and assessing eligibility—is often a primary operational bottleneck. Traditionally, this process relies on manual review or rigid legacy rules that fail when faced with the nuance of unstructured policy documents. The business challenge is balancing high-throughput processing with the absolute necessity of accuracy; in a regulated environment, a single “hallucination” in a coverage determination can lead to significant financial leakage or regulatory non-compliance. ...