Jonathon's AI Wiki

The High-Trust Paperwork Agent Skeleton (Nate B Jones)

9 min read

Source: raw/Every_AI_Agent_Demo_Stops_at_Email._I_Pointed_Mine_at_the_Bills_That_Cost_You_Money..md (Nate B Jones YouTube tutorial, youtube.com/watch?v=U4TmrlWEY4M)

Creator: Nate B Jones (“AI News & Strategy Daily”) · Platform: YouTube · URL: https://www.youtube.com/watch?v=U4TmrlWEY4M

Nate B Jones argues that most agent demos stall at email and calendar because builders treat delicate paperwork — insurance appeals, taxes, healthcare — as a different, higher-trust problem that needs a whole new system. His reframe: to an agent, all of it is the same problem — a mess-to-file organization job that turns an unstructured pile into structured, cited insights. He teaches one reusable nine-step agent skeleton that scales from low-stakes email triage up to high-trust paperwork, held together by a single load-bearing safety rule: the agent may read, organize, draft, and cite, but is never allowed to submit, pay, or sign.

Key Takeaways

  • High-trust paperwork is one problem, not many. Health forms and tax folders look different to humans because we organize by domain, but to an agent every paperwork task is the same: extract policy, category, and detail from an unstructured pile. It’s a “mess-to-file organization problem first and then you get structured insights out.”
  • “Lift the load, not click the button.” The value isn’t the agent taking the final action — it’s the agent preparing structured context so the human’s final click is easy. Jones: “I can click the button. I need the agent to get everything ready so that clicking that button is really easy.”
  • The gate is the whole game. Build the guardrail in from step one: the agent can read, organize, draft, and cite, but is never given the option to submit, pay, or sign. The human keeps that guardrail and validates before any real submission.
  • One skeleton scales across stakes. The same nine steps drive three builds — email/calendar (cheap mistakes), insurance appeals, and taxes — with only the nouns changing.
  • Clean, normalized data is the real secret. When “dates are dates and every claim has an address,” you stop needing the most expensive model — lightweight/open-source models handle most of the work.
  • Build a flywheel, not one-offs. Every build adds a reusable primitive to the shelf, making the next build cheaper. The insurance build was slow; the tax build was fast because “nothing in it was new.”

The 9-Step Skeleton

Jones’s agent does nine things, in order. Every build in the video runs this same list:

  1. Context pack — define exactly what the agent is allowed to read (the thread/documents, the constraints, the people involved) and give it one prepare-framed goal. Note the word “prepare,” not “send.”
  2. Ingest — turn documents into text the agent can use, with anchors back to the source.
  3. Chunking — split each document into tagged, addressable pieces. A denial letter isn’t one blob (it has a date, a denial reason, a claim number, a deadline, and an evidence paragraph); a policy isn’t one blob either (sections, definitions, exclusions, appeal rules).
  4. Normalizing — dates become dates, people become people, amounts become amounts, and missing documents become missing documents. Jones calls this boring step the thing that makes high-trust work possible.
  5. Storing — everything saved locally (a small SQLite database plus a folder you can open yourself). Nothing leaves your machine; you never have to ask the model to remember what happened.
  6. Retrieving — pull the structured records back out. For an insurance denial, retrieve by structure rather than by vector search: the insurer is legally required to cite the exact policy language, so “you already know the address of the thing that’s hurting you” and no vector database is needed.
  7. Citing — every claim points back to its source, and a sanity check confirms the cited policy section actually says what the letter implies it says. When it doesn’t, “that’s finding number one.”
  8. Exporting — produce a reviewable packet (timeline, denial/deduction map, exact governing language, evidence checklist, a draft letter, and a list of questions for the expert) — not a submitted form.
  9. Gating — the agent stops before any irreversible action. It leaves the draft, the proposed hold, and a receipt of what sources it used, what it changed, and what still needs human approval.

The Gate: Read, Organize, Draft, Cite — Never Submit, Pay, or Sign

The gate is “the rule from the top of the video” and the reason the whole approach is trustworthy:

  • The agent may read, organize, draft, and cite. It is never allowed to submit, pay, or sign.
  • This is a job given to the agent from the beginning, so the guardrail is designed in — “we’re not giving the agent ever the option to take an unallowed step.”
  • The human keeps the guardrail and is responsible for testing and validating before submitting any insurance claim or tax filing. “It’s on you as the human to submit it. It’s not on the agent.”
  • The receipt at the gate — sources used, what changed, what still needs approval — is what separates “AI handled it” from “I know what happened here and I can trust the AI.” Build for trust from day one.
  • Why it matters: “if an agent sends a bad appeal on its own, now you have two problems. The denial and the mess the agent made.” Citations make your review faster, not optional.

The Bridge Most People Skip

The move that gets you from a toy email agent to real high-trust work — and the reason most people never make the jump:

  • You might think insurance appeals mean starting over with a new tool, a new setup, a new higher-trust system. “It doesn’t if you build it right.”
  • Everything you built in the email build — ingestion, normalization, the receipt, the gate — are primitives that don’t care whether they’re pointed at a scheduling thread or an insurance denial. “It’s the same thing to the agent.”
  • That’s the flywheel: every build adds a skill to the shelf and makes the next build cheaper. Not realizing that build-one primitives transfer is what keeps people stuck at the “101” email demo.

Three Progressive Builds

Same skeleton, rising stakes — Jones frames them as a 101 → 201 → 301 ladder ^[inferred — the auto-captions read “101,” a garbled “2011,” and “301”; 201 is the obvious middle rung].

Build 1 — Email & calendar (mistakes are cheap). The inbox is an unstructured “dumpster fire” — not from disorganization but “because email is effort that other people give to us.” It’s also where high-trust documents already live (your W2, a denial-letter PDF, a doctor’s secure messages). The agent gets a context pack (the thread, calendar constraints, people) and one goal: prepare a reply with a proposed calendar hold. It ingests, normalizes (dates→dates, people→people), drafts the reply, builds the proposed hold — then stops and leaves a receipt. If it’s right, you send; if wrong, you fix.

Build 2 — Insurance appeals (real money). Real published insurer policy language, a synthetic patient for privacy, a masked denial letter; the files stay on your machine. New goal: “I don’t want a vibes-based appeal letter. I want a case file that I can inspect.” The agent chunks the denial and policy into addressable pieces, normalizes (including missing documents, so evidence gaps surface well before a deadline), stores locally in SQLite, retrieves by structure, and cites — sanity-checking whether the cited policy section actually supports the denial. The output is an evidence packet (timeline, denial map, governing policy language, evidence checklist, draft appeal), not a sent appeal. The reframe: “The agent is not winning the appeal for you. It is turning the pile of unstructured information into a case file that makes you able to win… you stopped showing up with bad data.” Then it gates — you are responsible for what you send.

Build 3 — Taxes (fast, because nothing is new). Synthetic W2s, 1099s, invoices, receipts, bank exports, mileage notes — half of which were living in the inbox from build one. Goal: prepare a reviewable packet for you or your CPA, not a filed return. Same order: ingest, chunk into forms (income / expenses / unknowns), normalize into a tax-year ledger (date, vendor, amount, category, source file). A citation guard won’t let a deduction through without evidence — it points at the receipt or flags the line rather than pretending it knows. The export is a packet — income summary, expense ledger, deduction-evidence map, missing docs, and a list of questions for the CPA (“a good agent gives you better questions to ask an expert”). It preps, summarizes, and stops. This build “took a fraction of the setup the insurance one did” — the third turn of the flywheel.

Try It

  1. Pick a low-stakes folder first. Point the skeleton at email/calendar or a similar cheap-mistake domain to learn the nine steps before touching money or health.
  2. Write the gate before the features. Give the agent a prepare-only goal, design out any submit/pay/sign capability from step one, and require a receipt (sources used, what changed, what needs approval) at every stop.
  3. Store locally and cite everything. Keep records in a local SQLite database plus a folder you can open, and make every claim point back to a source so your human review is fast, not optional.
  4. Reuse the primitives (the bridge). Once ingestion, normalization, the receipt, and the gate work on the easy domain, repoint them at a higher-trust folder instead of rebuilding.
  5. Invest in clean, normalized data so you can run cheaper/open-source models for most of the work.
  6. Grab the runbooks. Jones’s accompanying Substack post includes the healthcare-appeals and tax-prep runbooks, the two underlying open skills, and a context-engineering guide. ^[inferred — described in the transcript; not independently verified here]

Open Questions

  • The three builds are demonstrated on synthetic/masked data by a single creator; no independent reproduction of the insurance-appeal or tax-prep results is cited.
  • The stack (local SQLite + folder, “retrieve by structure, no vector database”) is described narratively in the talk; the actual runbooks and open skills live in the linked Substack and aren’t ingested here.
  • Effectiveness is explicitly not guaranteed — Jones says the packet improves your data quality (“you stopped showing up with bad data”), not your odds of winning by itself.

Graph View

Backlinks