A reusable AI 'rig': from your inbox to appealing insurance claims and doing your taxes

By Nate from Nate's Substack · July 3, 2026.

The article opens with a figure that serves as both a hook and a justification for everything that follows: according to KFF, an independent health policy research organization, of the roughly 85 million claims denied in Affordable Care Act marketplace plans in 2024, consumers appealed less than one percent. Yet when people do appeal, they win far more often than that silence suggests: insurers reverse about a third of internal denials on their own initiative, and if the affected person persists all the way to an independent external reviewer, the figure rises toward half; in the case of prior authorizations, it exceeds eighty percent.

Nate argues that most denials stand not because insurers are usually right, but because almost no one files the appeal. And he adds that the insurer's side is increasingly automated: he cites a 2024 report from the Senate Permanent Subcommittee on Investigations that found the largest Medicare Advantage insurers relied on algorithmic tools while their denial rates for post-acute care rose; according to that report, UnitedHealthcare's rate more than doubled in two years. The core idea is that there is structure plus automation on one side, and just a stack of papers on the other.

From there, the author lays out the newsletter's underlying problem: people already use AI daily, but they almost always stop at the email agent, because it works, it delivers immediate satisfaction, and the next real problem (a medical claim, taxes) seems to demand starting from scratch: new tool, new setup, new trust concerns. As a result, ambition dies in the inbox while the folders that actually cost money stay closed.

Nate's proposal is to change the standard of what gets built: every agent you build should make it cheaper to build the next agent. If that doesn't happen, he argues, you're not building a system but accumulating loose tasks that happen to run on AI, and each one will degrade on its own.

The article promises to develop a concrete alternative: a single reusable 'rig' —a work setup assembled once, tuned through use, and pointed successively at different problems. It would be applied in order to three cases: a calendar/email coordination thread, a denied insurance claim, and a full year's tax preparation. According to the author, the rig runs the same nine stages every time, from deciding what the agent can read to the mandatory stopping point at which the work is handed back to the user. Between one build and the next, only the 'nouns' would change: what goes into the context package and what the final output package looks like; everything else would carry over. The promise is that, by the third build, the effort is a fraction of the first, and that this ratio keeps improving because each component becomes more precise with use.

Nate clarifies that insurance and taxes are 'proofs of concept', not the system's limit: once you've seen the rig work three times, the reader would recognize the same pattern in a dozen more problems —any situation in which life hands over sensitive documents, without structure, and a decision that matters. He mentions he will return to that list later in the full article.

There is one rule that, according to the author, governs the entire system: the agent only drafts and organizes. It never sends, files, pays or signs anything. That boundary, he says, is what allows the system to be pointed at money and health without being a mere legal disclaimer tacked onto an already-capable system, but rather the very reason the system can operate safely in those domains.

The email lists the content the full piece would include (paid, as indicated at the end): the rig explained stage by stage, with nine steps and the reason for each, including why the build deliberately avoids vector search and what legal detail about denial letters makes deterministic retrieval the right choice; three builds on the same rig —first email and calendar as 'training', then the insurance appeal package, and then the tax prep package, with the context packages and export templates for each case—; the mechanics of the 'flywheel', that is, which components carry over between builds, which are tuned through use, and why the third build costs a fraction of the first; and finally two concrete agents plus the 'skills' they run on: the Healthcare Claim Appeals Agent and the Tax Prep Organizer Agent, supported by the Context Engineering and Runbooks Open Skills, each ready to copy with its own setup prompt.

The email closes by noting that paid subscribers get the full analysis and guide, plus access to the author's Slack community.