Trellis Ai

Why we started Trellis

Before a patient can start a therapy, the prescription has to clear intake, a benefits check, an estimate of what the patient will owe, and prior authorization. The people doing that work are intake coordinators, benefits coordinators, and prior auth specialists. They sit in warehouses across the country, mostly in the Midwest, doing data entry.

The therapies we work on are usually expensive enough that an insurer’s got to approve them first. Without that approval, the treatment might as well not exist. Jacky watched a parent wait a long time for approval on treatment that couldn’t wait.

We met at the Stanford AI Lab, building foundational models for healthcare. Mac was leading AI and diagnostics work at the Stanford School of Medicine on patient identification. Jacky was a healthcare data scientist at the World Bank Group, doing econometrics in its development impact evaluation branch.

Trellis didn’t start out on medication access. We started horizontal, automating document work for anyone with a paperwork problem, but our biggest customers were always healthcare companies. Technically that work isn’t so different from legal, but the nuance in healthcare runs deep enough that going the extra mile takes focus. At some point we were at a crossroads: double down and deliver a lot more value for our healthcare customers, or stay horizontal. We picked the first, because neither of us thinks science is what keeps people from being treated.

What we’re building

Getting one script from written to patient starting treatment takes about a hundred steps. Which hundred depends on the drug, the insurer, and which of a customer’s locations the script came from, and customers revise those procedures about once a quarter. We’re automating every step.

Our agents do that work the way the people in those Midwest warehouses do, through the same screens. They read and write to electronic health records (EHRs) because those systems have no APIs worth using. They fill out insurance portals. Some of our agents aren’t in a browser at all: they drive desktop software directly. Some work the phones with payers, providers, and patients, and those calls get transcribed and summarized back into the record.

Jacky’s shorthand for the end goal is “autopilot, not copilot.” A chatbot on a PDF document isn’t really helpful for this work. Today, autopilot looks like 10 minutes from a new referral to a submitted prior auth, 5 seconds for a benefits check, and 90% of scripts running end-to-end without a person touching them. We process ~30M scripts/year and $10B of therapies across 450+ locations in all 50 states. Some of those customers are Fortune 500 companies. Customer churn = zero.

That last 10% is the cases a person still has to touch: a portal changed overnight or a location that runs its procedure differently. What we’re building toward is one motion: script in, patient ready for therapy.

What you’ll own

We went from 6 to 8 figures of revenue in less than a year. Jacky’s bar for this role is a question: what would someone who’s taken a company from zero to nine figures in two or three years want to change here?

Engineering is 15 people today, in three pods: platform, deployed, and product. We want to 2x the size of the team by the end of the year. You’d set the coding bar, make the high-leverage technical calls on the team’s behalf including vendor selection, and own how engineers here write tests and ship. It’s a player/coach job; you’d still be writing code.

The dev environment. Somewhere an engineer can pull any configuration down from prod into local. Jacky thinks a good one triples an engineer’s output. It’s where he’d want your first ninety days to go. What “as close to prod as it gets” means when prod is thousands of Windows sessions driving portals and EHRs we don’t own is yours to define.

The fleet. Thousands of concurrent browser and desktop sessions run on Windows Server and Remote Desktop Services, around the clock. Keeping them up means:

• Diagnosing runaway processes, memory leaks, and zombie sessions on live hosts
• Handling loopback and local RDP architectures
• Shadowing sessions to debug an agent mid-run
• Maintaining golden images

When a session host hangs or an agent stalls, it isn’t an abstract SLA breach; it’s a clinic waiting on a prescription.

Self-healing. There are thousands of insurance portals, each with a different flow depending on the medication, and they change weekly or quarterly with no warning. We have some version of self-healing today: a failure escalates to someone on our ops team who fixes it by hand. But with thousands of portals, we want the system to do that itself.

Memory. When a portal changes, an agent fails and somebody discovers it. When a payer policy, a clinical guideline, or a customer’s SOP changes, an agent can fill out a prior auth exactly the way it did last quarter and be wrong. Deciding what an agent should know, where that knowledge comes from, and how to catch it going stale would be yours.

Turning customer SOPs into working agents. A customer’s procedures reach us as documents and screen recordings. A recording captures one run, meaning one payer’s portal, one drug, and one path through the form. The agent built from that recording has to handle every payer and every drug the customer submits. When that conversion works, ops ships a new workflow in hours rather than waiting on engineering.

Stack: TypeScript, AWS, Temporal, and the Windows Server and RDS side. Working out where it stops scaling, and what replaces it, would also be yours.

How we’ll measure success

• Whether the team has good dev environments and test suites, and whether coding practices are being enforced
• How well you get the engineering team unblocked
• Whether our infrastructure scales past the $10B of therapies we process today (we should be processing more)

Who you’ll work with

Jacky, whom you’d report to, studied computer science and history at Stanford and worked in Facebook’s real-time ML group before co-founding Trellis. As an undergraduate, he co-wrote an economics paper arguing that the Dow badly understates what investors have actually earned because it ignores dividends. MarketWatch ran a piece on it. If you want a read on how he thinks before you meet him, it here. He and Mac sometimes disagree about how much to build for the moments when a prior auth still needs a person. Mac pushes for more agent; Jacky pushes for whatever makes a deployment land. We’ll look for your input here.

Vikram is our founding engineer. He studied computer science and mathematics with a minor in robotics, and was the youngest engineer at Ramp. He left Ramp to start his own company, ran it for about a year, then spent time at Skydio before coming.

Ellen describes herself as a restless software engineer who’ll work on whatever catches her fancy. Before Trellis she was a senior SRE at Cruise and an engineer at Mux and Microsoft, then was a fellow founder in our YC batch (W24). Ellen joined because she’s been on both sides of the portal and has a compelling POV about it.

Aryamaan trained as a biological engineer. He finished first in his class at IIT Madras, published two papers on how tumors metastasize, and released a generative model for preserved tissue samples that’s still online. He got his master’s in computer science at Columbia, joined us in February, and runs deployments with our largest customers.

Sam spent three years at Applied Intuition writing core simulation software for autonomous vehicles. He’s building the same thing for our agents: a framework that simulates, tests, and evaluates what an agent does before it does it in prod.

Who does well here

Jacky screens for one thing above all: “whether someone’s got a dog in them,” by which he means: will you do whatever it takes to get a patient their medicine. It’s the single best predictor of who works out here. The team is light-hearted and very serious at the same time: you’ll hear it candidly when you aren’t meeting the bar.

You’ll do well here if:

• You find a fleet of Windows session hosts interesting rather than beneath you
• You’re willing to learn the rules that determine whether a payer approves a drug in enough detail to argue about them
• You want to be in the code while you set the bar for a team doubling in a year
• You’d spend real time with the ops people whose manual work you’re removing

You’ll be unhappy here if:

• You need clean APIs and documented interfaces. The EHRs have none worth using, and the portals change without telling us.
• You need a system that’s provably right. We measure ours against how often people get it wrong today.
• You want to work remotely. We’re together five days a week.

We ask a lot and take care of people in return, with a monthly $75 “fun budget” you can only spend with a teammate, Brex cards for lunch, and boba during show and tell.

The hiring process

1. Intro call with Jacky
2. Systems design interview with one of our engineers
3. Product engineering interview with another
4. Onsite. Jacky says you can feel how “locked in” people are when you walk into the office. This is where you find out whether he’s right (and whether you like it).
5. Offer, pending references

When you ship something here, thousands of patients feel it the next day. If that sounds like your kind of problem, we’d love to talk with you.

- Mac Klinkachorn (Co-founder & CEO) and Jacky Lin (Co-founder & CTO)

Trellis offsite

Team lunch

Favorite pizza place on Friday

Zaza, our favorite believer and investor

Our customer favorite partners

The most expensive meal we all had