How CanyonRift Uses TinyFish for Payer Policy Research

TL;DR

CanyonRift uses TinyFish as a browser-intelligence layer for payer medical-policy research, then turns those findings into structured prior authorization and appeals workflows for hospital utilization-review teams.

In a synthetic local replay, the workflow returned reviewer-usable policy findings in approximately 4 seconds and generated a packet-ready artifact set in approximately 9.3 seconds. It replaced an 8-step manual policy-lookup checklist with 1 routed TinyFish research task for operator review.

“The browser agent should not be the product’s memory. It should be the product’s research instrument.”

The problem

Prior authorization is a browser-heavy workflow hiding inside an administrative workflow.

Hospital utilization-review teams rarely struggle because information does not exist. The problem is that the information is scattered across payer policy pages, PDFs, portal screens, internal evidence packets, spreadsheet trackers, and reviewer notes.

A reviewer often needs to prove two things at once:

1. The patient’s case meets the payer’s stated medical-policy criteria.
2. The authorization packet is complete enough to survive operational review.

That creates a workflow with a surprising amount of browser research hidden inside it. Teams need to locate the correct payer policy, identify relevant criteria, preserve source material, map those criteria to clinical evidence, flag missing documentation, and keep a clear record of what happened.

For serious operational workflows, the issue is not simply whether an agent can find an answer.

The issue is whether the product can preserve what happened after the browser session is gone.

What I built

I built CanyonRift to make prior authorization and appeals workflows more structured.

CanyonRift is a prior authorization and appeals workbench for hospital utilization-review teams. It coordinates:

• case intake
• payer-specific research routes
• evidence-binder generation
• appeal drafting
• audit history
• retry controls
• human review

The workflow starts with a case context, procedure category, diagnosis, payer selection, and evidence-readiness checks.

For the demo, CanyonRift uses synthetic, pre-BAA data only. No PHI, credentials, or live payer submissions are involved.

The workflow has five stages:

1. Synthetic intakeAn operator starts with case context, procedure category, diagnosis, payer selection, and evidence-readiness checks.
2. TinyFish researchCanyonRift sends a bounded browser-research task to TinyFish, such as:“Which public medical-policy criteria apply to lumbar spine MRI prior authorization?”
3. Structured findingsTinyFish returns reviewer-facing findings such as a criteria summary, cited source title, source URL or PDF reference, criteria excerpt, retrieval timestamp, route status, and reviewer notes.
4. Evidence mappingCanyonRift maps the policy criteria to synthetic chart evidence and highlights matched criteria, missing documentation, evidence gaps, and items requiring review.
5. Packet generation and human reviewCanyonRift produces reviewer-facing artifacts such as an evidence binder, prior authorization form, appeal draft, and submission manifest. The final state is packet-ready-for-review, not automated payer submission.

Where TinyFish fit

TinyFish fits into one specific but important part of CanyonRift: public payer-policy research and discovery.

The browser-research task is bounded, but messy.

TinyFish’s job is to:

• search public payer-policy sources
• inspect relevant policy pages and supporting PDFs
• surface candidate criteria and policy context
• preserve enough evidence for a human reviewer to verify the result

CanyonRift’s job is to:

• own the workflow state
• preserve what happened
• track what was generated
• show what failed or retried
• generate reviewer-facing artifacts
• keep the analyst or reviewer in control

The agent is not deciding medical necessity. It is not submitting anything to a payer. It is not replacing the reviewer.

That separation matters.

A browser session is temporary. An operational workflow cannot be.

A synthetic lumbar MRI walkthrough

To make the workflow concrete without exposing sensitive information, the demo uses a synthetic lumbar MRI prior-authorization case.

The synthetic case includes:

• persistent low-back pain with radicular symptoms
• prior conservative therapy
• a clinician order for lumbar spine MRI
• a narrow payer-policy question focused on medical-necessity criteria

CanyonRift sends TinyFish a bounded research task to locate relevant public policy material. TinyFish returns candidate criteria and supporting source references for human verification.

The criteria are then mapped into a reviewer-facing structure:

What worked

Separating browser research from packet generation

The cleanest architecture was not to ask TinyFish to own the entire prior authorization process.

TinyFish is strongest as the browser-research layer. CanyonRift is strongest as the workflow, artifact, and review layer.

This makes the system easier to explain, easier to debug, and safer to operate.

Treating source consistency as a product concern

The workflow should not return a generated answer without preserving the source material behind it.

For each finding, CanyonRift keeps:

• the supporting policy reference
• criteria excerpt
• retrieval state
• reviewer context

That makes it possible for a reviewer to verify the evidence before relying on generated text.

Making retry state visible

A payer-specific browser route can fail, stall, or require a retry.

That should not make the entire workflow look broken.

CanyonRift tracks each route independently so the operator can see which route completed, which route needs a retry, and which result is still safe to trust.

What I’d do differently / Lessons learned

1. Browser automation needs product-shaped state

It is tempting to treat an agent run as a black box: launch it, wait, and display whatever comes back.

For serious operational software, that is not enough.

The application needs to know:

• which route the run belongs to
• whether the result is fresh
• what can be retried
• what evidence was preserved
• what the reviewer should trust

2. Keep the agent’s job narrow

The best architecture was not to ask the browser agent to own the entire prior authorization workflow.

TinyFish handles research.

CanyonRift handles workflow state, artifacts, auditability, and review.

3. Design the demo around what you can safely show

Healthcare demos can easily drift into sensitive territory.

This workflow uses synthetic, pre-BAA data and avoids PHI, credentials, live payer submissions, and production infrastructure details. That keeps the story focused on the product architecture rather than private information.

4. Make stale state impossible to trust accidentally

The first version treated browser research too much like a single generic preview.

That made it difficult to tell:

• which payer route was active
• whether a stream belonged to the latest attempt
• whether an older incomplete state was still relevant
• whether a retry had replaced a previous run

For an operational workflow, stale status is dangerous. It can create false confidence or trigger a false alarm.

The fix was to make retry state explicit. When a retry starts, CanyonRift clears stale preview data, tracks retry tokens, and ignores older stream callbacks if a newer attempt has already replaced them.

That is not the flashiest part of the product, but it is the kind of behavior that matters when operators need to trust the status panel.

Measurable demo outcome

The current MVP uses a synthetic local replay to demonstrate the workflow safely.

These results are scoped to the offline demo environment. They are not production performance claims and do not represent live payer-site completion or submission.

Recommendation for other builders

If you are adding browser agents to a serious workflow, do not start with the agent prompt alone.

Start by deciding what your product needs to remember after the browser session is gone:

• status
• evidence
• screenshots
• generated artifacts
• retry attempts
• audit history
• human-review decisions

Once that record is clear, it becomes much easier to place TinyFish in the stack.

The browser agent should be the research instrument.

Your product should remain the memory.

Try it / Links

CanyonRift is building workflow infrastructure for prior authorization and appeals teams.

If you are building browser-powered workflows that still need source traceability, retry state, artifact generation, and human review, this pattern may be useful:

1. Use TinyFish for bounded browser research.
2. Keep product state inside your application.
3. Preserve source material for review.
4. Make retry and stale state visible.
5. Keep the final judgment with the human operator.

📌 Sign up free → agent.tinyfish.ai

Docs → docs.tinyfish.ai

Open source Cookbook → github.com/tinyfish-io/tinyfish-cookbook