Member ops, run for you · Health plans and benefits administrators
We run member operations. Same-day, right-plan adjudication.
Antino builds an operations brain — your plans, benefits, and adjudication rules as an executable graph — and runs onboarding, benefits administration, and reimbursement on it. Multi-tenant by design, so each client plan stays isolated and correct.
Below: the whole pipeline — playable
01 · The problem
Every plan is a snowflake, and every snowflake is manual.
Each employer group has its own benefit design, eligibility quirks, and reimbursement rules. Onboarding a new client means weeks of configuration and a spreadsheet someone hand-checks. Adjudication leans on people who memorized the edge cases. Margins erode with every group you add instead of improving.
02 · How we'd run it
The benefits brain: every claim in, two ways out.
Intelligent decisions. Zero busywork. Every exception, owned.
Requests in
Nine plan designs. One front door.
Member & enrolment data
Who's covered, under what
Plan design per group
Each employer's rules
Bills & receipts
Provider claims, reimbursements
Coverage history
Utilization, prior approvals
The benefits brain
Eligibility. Adjudication. Payout.
- Eligibility check
- Plan-design resolution
- Benefit calculation
- Duplicate & fraud screen
- Adjudication rules
- Co-pay & limits
every decision logged · every outcome written back
Straight-through
~85%Adjudicated against the right plan, paid on cycle.
Exception
~15%Routed to a benefits ops owner
Complex cases. Human judgment — with the case pre-packaged:
Executable plan rules
Each group's design, encoded
Auditable by design
Every adjudication logged
Continuous learning
Resolved edge cases become rules
Tenant isolation
Groups never bleed into each other
Scales by default
New groups without new headcount
Shares are illustrative of a typical mature benefits book.
03 · The pipeline, end to end
The science of shipping, stage by stage.
Nine stages, nine tenant plans, one brain. Drag the agentic-depth dial to see how each stage behaves as the agents absorb more of the routine — and hover any stage for a worked example. Notice what never moves: the plan-exception ruling stays on a human desk at every depth.
Agentic depth — drag it
0%Enrol & resolve
Benefits brain · resolve0%stage 01 · dossier
Group onboarding
A new employer group's benefit design becomes executable, isolated config — not a configuration project.
- Encodes the plan document into executable benefit rules
- Cross-checks the encoding against the source design and flags conflicts
- A benefits analyst signs off the encoded design against the contract.
Client number ten goes live
The pattern from running nine enterprise tenants on one platform: the tenth group's design is encoded, conflict-checked and test-adjudicated in days — because the brain has done this nine times and remembers all of it.
Weeks of spreadsheet configurationA benefit design encoded in days
click the stage to collapse
stage 02 · dossier
Member enrolment
Members are onboarded against their group's own rules — eligibility windows, dependents, waiting periods.
- Validates enrolment data against the group's plan rules
- Catches configuration and eligibility errors before they reach a claim
The error caught at enrolment, not at the claim
A dependent added outside the group's window is flagged on day one — instead of surfacing eight months later as a denied claim and an angry call.
Forms re-keyed into three systemsEnrolled once, correct everywhere
stage 03 · dossier
Claim intake
An invoice or provider claim arrives and is parsed: provider, procedure, date, amount, member.
- Reads invoices and bills from any format into structured claims
- Matches provider and procedure codes to the network and tariff
09:14, a physiotherapy invoice
A member photographs a ₹3,200 invoice in the app. Seconds later it's a structured claim — provider, procedure, amount — with no data-entry desk in between.
An email inbox and a data-entry queueA receipt photo becomes structured data
stage 04 · dossier
Plan resolution
The single load-bearing step: which tenant, which design version, which rules. Isolation is the data model, not a policy.
- Resolves the member to exactly one plan design and version
- Loads that tenant's rules in a sealed context — no cross-tenant leakage possible
Group K's world, and only group K's
Physio at 80%, cap ₹25,000, no prior-auth under ₹5,000 — loaded as executable config. Group J's rules cannot leak in, because tenant isolation is structural, not procedural.
Process discipline and hopeThe wrong plan structurally cannot fire
stage 01 · dossier
Group onboarding
agenthumanA new employer group's benefit design becomes executable, isolated config — not a configuration project.
- Encodes the plan document into executable benefit rules
- Cross-checks the encoding against the source design and flags conflicts
- A benefits analyst signs off the encoded design against the contract.
Client number ten goes live
The pattern from running nine enterprise tenants on one platform: the tenth group's design is encoded, conflict-checked and test-adjudicated in days — because the brain has done this nine times and remembers all of it.
Weeks of spreadsheet configurationA benefit design encoded in days
click the stage to collapse
stage 02 · dossier
Member enrolment
agentMembers are onboarded against their group's own rules — eligibility windows, dependents, waiting periods.
- Validates enrolment data against the group's plan rules
- Catches configuration and eligibility errors before they reach a claim
The error caught at enrolment, not at the claim
A dependent added outside the group's window is flagged on day one — instead of surfacing eight months later as a denied claim and an angry call.
Forms re-keyed into three systemsEnrolled once, correct everywhere
stage 03 · dossier
Claim intake
agentAn invoice or provider claim arrives and is parsed: provider, procedure, date, amount, member.
- Reads invoices and bills from any format into structured claims
- Matches provider and procedure codes to the network and tariff
09:14, a physiotherapy invoice
A member photographs a ₹3,200 invoice in the app. Seconds later it's a structured claim — provider, procedure, amount — with no data-entry desk in between.
An email inbox and a data-entry queueA receipt photo becomes structured data
stage 04 · dossier
Plan resolution
agentThe single load-bearing step: which tenant, which design version, which rules. Isolation is the data model, not a policy.
- Resolves the member to exactly one plan design and version
- Loads that tenant's rules in a sealed context — no cross-tenant leakage possible
Group K's world, and only group K's
Physio at 80%, cap ₹25,000, no prior-auth under ₹5,000 — loaded as executable config. Group J's rules cannot leak in, because tenant isolation is structural, not procedural.
Process discipline and hopeThe wrong plan structurally cannot fire
Adjudicate & pay
Benefits brain · decide & learn0%stage 05 · dossier
Eligibility & benefit calculation
Coverage, co-pay, caps and utilization are computed against the resolved plan, with the clause attached.
- Computes the eligible amount: covered rate, deductible, remaining cap
- Attaches the exact plan clause that authorizes the result
₹2,560 eligible — and here's the clause
80% of ₹3,200, member at 40% of her annual cap, no exclusion triggered — and the clause number rides along with the approval, so nobody has to take the system's word for it.
Whoever memorized the edge casesCovered rate and cap, computed and cited
stage 06 · dossier
Duplicate & fraud screen
Duplicates, unbundling and anomaly patterns are screened across the tenant's full history.
- Screens for duplicate submissions and split billing
- Flags utilization anomalies against the member's and provider's history
- Flagged providers are reviewed by ops before any network action.
The same invoice, twice, ten days apart
A resubmitted bill with a new date is matched to the paid original by provider, amount and procedure — caught at intake instead of at the year-end audit.
Spot checks when time allowsEvery claim screened, every time
stage 07 · dossier
Adjudication
Clean claims adjudicate straight through against the right plan. Anything ambiguous refuses to guess.
- Executes adjudication rules with the full decision trace logged
- Detects ambiguity — codes straddling exclusions — and routes instead of guessing
The brain that won't guess on benefits
A procedure code straddles an exclusion in group M's design. The brain doesn't pick a reading — it packages both plausible interpretations with the policy reference and routes the case out.
A judgment call per snowflake planRules decide; ambiguity routes out
stage 08 · dossier
Plan-exception ruling
Ambiguous benefits, appeals and grievances are ruled on by a named ops owner — and the ruling is remembered.
- Prepares the case file: member history, plan clause, the ambiguity highlighted, both readings
- The benefits ops owner decides. The brain records the ruling as precedent.
Decided once, remembered for every tenant
The ops owner rules on the straddling code in minutes because the case arrived built. Next quarter, the same ambiguity doesn't escalate — the ruling became a rule.
Escalations lost in a shared inboxA named owner, both readings laid out
stage 09 · dossier
Payment run
Approved claims queue for the payment cycle; the member sees invoice, covered rate and remaining cap.
- Queues payment on cycle with the full audit trail attached
- Shows the member the calculation before they think to ask
The call-centre question, pre-answered
Invoice ₹3,200, covered at 80%, ₹2,560 paid, cap remaining shown. The question that used to be a queue is answered in the app before it's asked.
"Why this amount?" call queuesThe member sees the maths first
stage 05 · dossier
Eligibility & benefit calculation
agentCoverage, co-pay, caps and utilization are computed against the resolved plan, with the clause attached.
- Computes the eligible amount: covered rate, deductible, remaining cap
- Attaches the exact plan clause that authorizes the result
₹2,560 eligible — and here's the clause
80% of ₹3,200, member at 40% of her annual cap, no exclusion triggered — and the clause number rides along with the approval, so nobody has to take the system's word for it.
Whoever memorized the edge casesCovered rate and cap, computed and cited
stage 06 · dossier
Duplicate & fraud screen
agenthumanDuplicates, unbundling and anomaly patterns are screened across the tenant's full history.
- Screens for duplicate submissions and split billing
- Flags utilization anomalies against the member's and provider's history
- Flagged providers are reviewed by ops before any network action.
The same invoice, twice, ten days apart
A resubmitted bill with a new date is matched to the paid original by provider, amount and procedure — caught at intake instead of at the year-end audit.
Spot checks when time allowsEvery claim screened, every time
stage 07 · dossier
Adjudication
agentClean claims adjudicate straight through against the right plan. Anything ambiguous refuses to guess.
- Executes adjudication rules with the full decision trace logged
- Detects ambiguity — codes straddling exclusions — and routes instead of guessing
The brain that won't guess on benefits
A procedure code straddles an exclusion in group M's design. The brain doesn't pick a reading — it packages both plausible interpretations with the policy reference and routes the case out.
A judgment call per snowflake planRules decide; ambiguity routes out
stage 08 · dossier
Plan-exception ruling
agenthuman ownsAmbiguous benefits, appeals and grievances are ruled on by a named ops owner — and the ruling is remembered.
- Prepares the case file: member history, plan clause, the ambiguity highlighted, both readings
- The benefits ops owner decides. The brain records the ruling as precedent.
Decided once, remembered for every tenant
The ops owner rules on the straddling code in minutes because the case arrived built. Next quarter, the same ambiguity doesn't escalate — the ruling became a rule.
Escalations lost in a shared inboxA named owner, both readings laid out
stage 09 · dossier
Payment run
agentApproved claims queue for the payment cycle; the member sees invoice, covered rate and remaining cap.
- Queues payment on cycle with the full audit trail attached
- Shows the member the calculation before they think to ask
The call-centre question, pre-answered
Invoice ₹3,200, covered at 80%, ₹2,560 paid, cap remaining shown. The question that used to be a queue is answered in the app before it's asked.
"Why this amount?" call queuesThe member sees the maths first
Depth bars are illustrative of a mature benefits book. The plan-exception ruling is a permanent human gate — the brain prepares the case; it never decides the ambiguous ones.
04 · One brain, two engines
How the function runs on top of the brain.
Revenue OS
Onboard and configureWe stand up new client plans on the operations brain. Benefit designs get encoded as executable config, enrollment runs itself, and a new employer group goes live in a fraction of the usual setup time.
- Multi-tenant plan setup: each client's benefits isolated and machine-readable
- Member onboarding and enrollment automated against the plan's own rules
- New-group go-live measured in days, not multi-week configuration projects
- Configuration errors caught before they reach a member or a claim
Delivery OS
Administer and reimburseWe run benefits administration and reimbursement on the live operations brain. Clean claims adjudicate straight through against the right plan; anything ambiguous routes to a human with the policy reference in hand.
- Benefits administration run against the correct tenant's plan, every time
- Reimbursement and claim adjudication automated with the policy cited
- Member and provider questions answered from the plan, not from tribal memory
- Edge-case and appeal cases escalated to a named owner with full context
05 · What actually changes
The same function, before and after the brain.
06 · The outcome
Figures are illustrative unless tied to a named proof engagement.
07 · Live reference · HCL Healthcare
Multi-tenant benefits administration across 9 enterprise clients, run for 2+ years.
More use cases
The same brain, a different function.
09 · Run a function
Stop renting hours. Start running functions.
Pick the function you want off your plate. We'll map the brain and name the outcome we'd commit to — before you do.