Best practices for agentic PBM and pharmacy benefits data: a field guide for pharmacy benefits data teams

Ask the head of data at a pharmacy benefit manager what the week looks like and the answer is rarely analytics. It is the price file that landed Monday with a column in a new position, the replaced NDC that is still on last month's claims, the rebate variance that nobody can trace and the plan sponsor who wants one net cost figure explained down to the claim. The pharmacy benefit moves on files, and every file has a downstream reader that nobody listed.

The mandate is clear: tie rebates to claims, show where any number in a client report came from, and do it on data full of PHI. Plan sponsors ask for more transparency every year, and contracts keep adding per-client terms. Without automation, the team reconciles the same rebate file one more quarter and never ships the client analytics it exists to build.

Our view: the work that keeps pharmacy benefit data correct is repeatable, and agents should own it. They compare what the file, the claim and the contract each say, every day, and tell a named person when they differ. They do not decide what a manufacturer owes, what a price should be or what a client is told. That line is the design of everything below.

The old world

It is the Monday before quarter close. A price and MAC list landed overnight. The load succeeded, so nobody looked; three NDCs dropped out and one column moved. On Wednesday a pharmacy disputes a payment and an analyst spends the afternoon working out which claims edit read the changed rows. Meanwhile the rebate team starts the tie-out by hand, matching claims, reversals and contract terms in spreadsheets. Invoices go out on Friday with questions still open. Two weeks later a manufacturer disputes a line, and a sponsor asks how its rebate share was calculated.

The new world

Same Monday with Data Workers. The price file was compared with last week's on arrival, and the Data Context & Catalog agent listed every claims table, contract line and report that reads the rows that changed. The pricing owner approved a diff, not a surprise. Rebate-eligible claims have been tied to invoice units every morning, so each variance arrives with a cause attached. The rebate finance lead reviews a short list and issues the invoices herself. The wider set of teams on this path is on the health and life sciences data teams page.

Here is that new world as a chain of hand-offs between agents:

The full playbook walks through this scenario in depth. Eight practices make that morning possible:

The practices, one by one

1. Check every pricing and MAC file on arrival, before it touches a claim

A price that moves by a few cents changes what a pharmacy is paid and what a client is billed. A file that is wrong for a week is wrong on every claim adjudicated in it.

Why it's harder than it looks: A bad file rarely fails the load. A column shifts or NDCs drop out and the load reports success; the effect surfaces when a pharmacy disputes a payment. No single system sees the claims, the contract lines and the reports built on them.

1. 1.The Connectors agent calls get_connector_status and get_dbt_run_history to confirm the file landed and the models built.
2. 2.The Schema Evolution agent runs detect_schema_change and assess_impact on what reads the layout.
3. 3.The Quality Monitoring agent runs run_quality_check against the previous file, so a dropped NDC or unusual jump is a finding and routine movement is not.
4. 4.The Data Context & Catalog agent runs blast_radius_analysis to list every claims table, contract line and report that reads the changed rows.
5. 5.The Autonomous Data-Conductor holds the file back and routes one decision to the pricing owner, who approves the diff or sends the file back. Setting a price stays with the pricing team.

2. Map NDC changes to contract lines the day the reference file moves

The FDA's National Drug Code Directory is updated daily, and products are replaced and inactivated all the time. Old codes keep appearing on claims after the reference file moves on.

Why it's harder than it looks: A replaced NDC breaks nothing. The claim still pays; the rebate line it should have fed simply does not match, and the gap shows at invoice time. The FDA page also notes a final rule adopting a 12-digit NDC format from March 7, 2033, which will touch every table that stores a code.

1. 1.The Quality Monitoring agent writes the test once with create_quality_tests_for_pipeline: every rebate-eligible claim's NDC maps to a contract line. It runs run_quality_check on every load.
2. 2.When a code stops matching, get_anomalies lists the claims and contracts affected.
3. 3.The Data Context & Catalog agent runs blast_radius_analysis to show which invoice files and client reports read those lines.
4. 4.The Pipeline Building agent drafts the mapping with generate_pipeline and proves it in staging with validate_pipeline.
5. 5.The change is held for the rebate finance lead, with the tie-out before and after and how to roll it back.

Across the routine work these practices cover, here is the difference in elapsed time:

The biggest change is rebate reconciliation: from about 3 weeks to about a day.

3. Tie rebate-eligible claims to invoice units every morning

A tie-out done once, at quarter close, finds problems when there is least time to fix them.

Why it's harder than it looks: The tie is claims to invoice units by NDC, manufacturer and contract, netted for reversals that keep posting after the cut-off. The Medicaid program shows the shape: manufacturers pay rebates to states on a quarterly cycle. Commercial rebates run on your own contracts, so a variance is often a contract term read two ways.

1. 1.The Connectors agent confirms the claims extract and reference data landed.
2. 2.The Quality Monitoring agent runs the tie-out tests daily with run_quality_check and sets a deadline per manufacturer group with set_sla.
3. 3.For each variance, the Incident Debugging agent calls get_root_cause and get_incident_history to show whether it is a replaced code, a late reversal or an old rule.
4. 4.It sorts each variance into a data fault, fixed through the normal change route, and a contract question for the analyst who owns the manufacturer.
5. 5.The rebate finance lead reviews the explained variances and issues the invoice. No agent sends one.

The wider reconciliation pattern is in data reconciliation, and the claims side of the same discipline is in best practices for agentic claims data.

4. Check each client report against its contract's rules before it leaves

Sponsors rely on per-contract reports of guarantees, reconciliations and rebate share. A rule that drifts for one client is a financial error that reaches a customer.

Why it's harder than it looks: The same measure is calculated differently for each client, and the rules live in a mix of contracts, SQL and spreadsheets. Nobody can say which version of the logic was in force on a given fill date.

1. 1.An analyst states each contract's rule once, such as how an admin fee is netted. The Data Context & Catalog agent records it with define_business_rule.
2. 2.The Quality Monitoring agent turns each rule into tests with create_quality_tests_for_pipeline and runs them on the report model with run_quality_check before publish.
3. 3.generate_documentation writes the plain-English page for each report: its logic, owner and sources.
4. 4.A report that departs from its contract's rules is held. The failed check is a finding for a person.
5. 5.The client reporting lead approves the report before it goes to the sponsor.

5. Govern one definition of net cost, rebate share and guarantee

Net cost, rebate share and guarantee each have a version in finance, client service and analytics. An assistant pointed at the wrong one repeats the wrong number to everyone.

Why it's harder than it looks: The definitions are not wrong; they serve different purposes, and the conflict appears only when one figure must serve all three. Settling it in a meeting does not survive the next contract.

1. 1.The Data Context & Catalog agent records each definition, and each contract-specific variant, with define_business_rule and serves it through resolve_metric.
2. 2.mark_authoritative flags the trusted table for each concept, so analysts and AI assistants stop using the wrong copy.
3. 3.A change to a definition goes to its owner as a proposal showing every report it would move.

6. Scope PHI access by role and record every grant

Pharmacy claims identify members and conditions. The HIPAA Security Rule sets safeguards for electronic PHI, including access control and audit controls, so every grant needs a reason and a record.

Why it's harder than it looks: Most requests ask for more than the task needs, because member-level tables are the easy thing to share. Tickets cannot show who holds access today, and revoking it is rarely anyone's job.

1. 1.The Data Access & Governance agent runs scan_pii on the tables it is pointed at to find member-level fields.
2. 2.For each request it calls check_policy and proposes the least access that answers the question. Member-level tables can be left out of an agent's scope entirely.
3. 3.request_governance_review routes the request to the data owner, and enforce_rbac applies the role rules once it is approved. provision_access leaves the record.
4. 4.The owner approves each grant, and it is time-boxed by default. See data governance for healthcare.

7. Hold invoices, client financial reports, pricing changes and audit responses for a named approver

These four carry money owed, money billed and the PBM's word to a sponsor or regulator. A person must own each.

Why it's harder than it looks: Either everything waits for review and the benefit disappears, or a fix goes straight through and is reversed after a complaint. The workable rule separates reversible work (reruns, staging fixes, documentation) from work that changes a number somebody else relies on.

1. 1.The Data Access & Governance agent assembles each proposal with its evidence and lineage, and calls request_governance_review.
2. 2.The Autonomous Data-Conductor routes one decision to the named owner, with the diff and how to roll it back.
3. 3.The rebate finance, pricing or client reporting lead approves or declines. Unanswered requests expire and escalate.
4. 4.A person issues the invoice, publishes the report, changes the price or sends the response.

How approvals work is in how approvals work for AI data agents; undoing a change afterwards is in how to roll back an agent's change. By task class, the balance looks like this:

Lineage and docs upkeep closes autonomously 87% of the time. For pricing changes, client reports and rebate invoices, and audit and transparency responses, autonomous closure is 0% by design.

8. Capture audit evidence as the work happens

A sponsor audit or transparency request should be a query, not a project. Plan sponsors filing the annual RxDC report with CMS often need pharmacy data from the PBM behind it.

Why it's harder than it looks: An auditor wants a rebate share traced to claims. The definition, the logic in force and the source files each live somewhere different, and the answer ends up in a spreadsheet that is correct only on the day it is written.

1. 1.The Data Context & Catalog agent runs trace_cross_platform_lineage from the reported figure back to the source claims, and resolve_metric returns the governed definition in force.
2. 2.The Observability agent surfaces get_audit_trail: what changed in the logic, who approved it and when, held in a tamper-evident audit trail.
3. 3.The Data Access & Governance agent packages it with owners and approvals through generate_audit_report.
4. 4.The person who owns the sponsor or regulator relationship reviews the pack and decides what is sent. Your compliance and legal teams decide whether it satisfies the request.

Fraud and abuse findings stay a human judgment: see fraud, waste and abuse and audit evidence on demand.

Designing the autonomy ladder

Autonomy is set per task class, not per tool (the levels in full). Every deployment starts at L1. L0 to L2 run today. L3 and L4 are where a domain can go on evidence, never on a date, and a class that touches money or a client's number stops at L2.

"On evidence" means the receipts for that class are clean and the domain owner chooses to raise the level.

The operating model: who owns what

Agents change who does the work, not who is accountable for it:

The swarm behind the practices

No single agent delivers these practices. Each one is a hand-off between specialists, coordinated under the autonomy you set per domain.

Data Context Wizard holds one governed definition of net cost, rebate share and guarantee, so finance, client service and analytics read the same meaning. Autonomous Data-Conductor verifies the numbers that matter before the invoice run. Spellbook Data Catalog makes each rebate and pricing data set discoverable with owner and lineage.

What disappears

• •The price file that loaded fine and moved claims.
• •The replaced NDC found at invoice time.
• •The quarter-close rebuild of the tie-out in spreadsheets.
• •The client report with a rule that drifted unseen.
• •The argument over which net cost figure the sponsor sees.

Bad data is caught where it enters, and fixes are rerun, verified and explained before the rebate lead opens the variance list. Every action leaves a signed receipt, so the team can see what happened and reverse anything reversible.

A Head of PBM Data's scorecard

These are targets, set against a baseline you measure first:

• •Rebate reconciliation: about 3 weeks to about a day
• •Weekly pricing file change checked: about 6 h to 15 min
• •NDC reference update mapped: about 16 h to about 1 h
• •Client report checked per contract: about 24 h to about 2 h
• •Audit evidence pack: about a week to about 3 h
• •Lineage and docs upkeep closed autonomously: targeting 87%
• •Money and client-facing outputs with a named approver on record: 100%

Where this goes next

Once one manufacturer group runs these practices, a new manufacturer contract or client becomes a mission with a checklist, because tie-outs, contract checks and documentation already run. The manufacturer-facing view is in best practices for agentic pharma commercial data.

The climb: from assisted to autonomous to agentic

Our thesis is that the data platform climbs in stages, and that the hard part of data work was never knowing what to do but doing it. For pharmacy benefits data teams:

• •Assisted. Agents read the whole stack and propose every fix with a receipt; changes to rebate and client report logic go to a named approver.
• •Autonomous, under your governance. Routine work runs on its own: files checked on arrival, claims tied to invoice units every morning. Your team governs the agents instead of doing the upkeep.
• •The agentic enterprise. Pharmacy benefit data becomes continuous, and an audit request a query. People set direction, and approvers decide with the evidence ready.

You choose the altitude, and the pilot below is the first rung.

The pilot: how pharmacy benefits data teams start

The pilot is how your team proves the value on its own data before committing.

• •What we connect. Adjudicated claims, NDC reference and price files, rebate invoice data; Snowflake or Databricks; Airflow or Dagster; dbt; over MCP, inside your infrastructure. Nothing migrates.
• •Scope. Rebate-to-claims tie-out for one manufacturer group and one quarter at L2.
• •First week. Agents run at L1 across the scoped domain. They map every pipeline, definition and lineage path and show the fixes they would have made, with receipts, before anything changes.
• •By week two. Daily tie-outs and pricing and NDC file checks start running on reversible work. Mapping changes and client report logic stay at L2 with a named approver.
• •At day 30. We review the impact metrics against your baseline:

• •Rebate reconciliation: about 3 weeks to about a day
• •Weekly pricing file change checked: about 6 h to 15 min
• •Audit evidence pack: about a week to about 3 h
• •the share of lineage and docs upkeep closed autonomously, targeting 87%

• •What you decide. Whether to expand to the next manufacturer group or to client report checks. The pilot fee is credited in full against the first year.
• •The guarantee. In a 90-day pilot, ten engineering hours per data engineer per week are recovered against a baseline both sides sign on day one, or the $7,500 fee is refunded.
• •Cost. Start with a pilot ($7,500 one time, a 6 to 12 week pilot, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.

The pilot is the start of a longer curve:

By month 12, more than 34% of agent actions run fully autonomously while invoices, client financial reports, pricing changes and audit responses stay with named approvers.