AI business models
that can endure

1. What makes a business worth investigating?

A useful AI technique is not yet a business. Separate attention (people discuss it), capability (it performs a task), adoption (people use it repeatedly) and economics (customers pay enough to cover delivery). Funding, stars and an accelerator badge answer none of the last question by themselves.

Our preferred starting point is one buyer, one recurring exception queue and one verifiable outcome. Restaurant supplier-credit reconciliation and dealer repair-order evidence completeness are promising hypotheses because they can begin read-only, preserve incumbent systems and leave consequential decisions with employees. Customer research must still establish unmet need and willingness to pay.

Durability comes from reliable execution, lawful access to useful operational history, integrations, evaluation data and distribution. Domain expertise matters when it changes measured outcomes. A prompt library alone is weak protection as model capabilities spread. A profitable owner-operated service can be worthwhile even when it does not offer venture-scale growth.

2. Three models hiding inside “AI company”

YC’s Fall 2026 Requests for Startups includes AI-native compliance infrastructure and collaborative agents. This is evidence of investor interest in operational systems, not proof of margins or product-market fit.

Concrete private-company examples

• Salient, Winter 2023: its YC profile describes lender workflows focused on auto-loan servicing. This illustrates a narrow buyer and recurring workload; it is distinct from dealership service operations.
• HappyRobot, Summer 2023: its profile describes AI operations for supply-chain and industrial customers and lists deployment roles. It illustrates software plus implementation; hiring does not disclose delivery cost.
• Harper, Winter 2025: describes an AI-native commercial insurance brokerage using its own tools. It illustrates owning the service relationship. Premiums written are not brokerage revenue, and neither premiums nor funding demonstrate profit.

Unknown: public materials reviewed do not establish these companies’ current net profitability, cohort retention or fully loaded unit economics. Profile descriptions and automation claims are company claims, not independently reproduced results.

Ranked hypotheses, with ways to disprove them

3. Forward-deployed engineering: discovery or a services trap?

A forward-deployed engineer works close to the customer’s operation: understanding the process, integrating data, building applications and getting a solution into use. Palantir’s Ontology connects organizational objects and relationships to actions, functions and security. Its FDSE role description includes customer collaboration and end-to-end implementation. The combination is a reusable platform with embedded delivery.

What Palantir’s reported results establish

For the quarter ended June 30, 2026, Palantir reported $1.935 billion revenue and $912 million GAAP operating income, a 47% operating margin. Reported gross profit of $1.638594 billion divided by revenue of $1.935464 billion yields approximately 84.7% GAAP gross margin. The separately reported 62% adjusted operating margin is non-GAAP. These are unaudited company-reported quarterly results, published August 3, 2026. SEC-filed earnings release and reconciliations.

The Q2 2026 Form 10-Q says sales cycles often take six to nine months and can last a year or more. Long evaluation and implementation cycles affect cash and staffing before a contract pays back.

Our inference: deployment-intensive software can achieve substantial operating profitability at scale. A new FDE consultancy does not inherit those economics. Gross margin alone misses delivery-related work classified in sales, product development or other operating expenses; examine the whole income statement.

Turn customer learning into shared assets

1. Start with a bounded process and document its exceptions before promising automation.
2. Separate common capabilities from customer configuration. Reuse connectors, evidence schemas, review screens, tests and deployment playbooks.
3. Track engineer-hours per launch, time to first accepted result, support load and account contribution. Include presales and failed pilots.
4. Decline custom commitments that make one account the product roadmap unless the economics intentionally support a services business.
5. Test a second deployment before claiming repeatability. If the learning does not reduce the next implementation burden, reassess the software thesis.

4. Where the margin disappears

Invented example, not company data or a market price: a workflow product charges $3,000 per month. Inference/infrastructure cost $300, review/support $450 and other direct delivery costs $150. Delivery contribution is $2,100, or 70%, before acquisition, implementation, research, administration and taxes.

This is contribution, not GAAP gross margin or net profit. Churn before payback breaks the simplified case. Annual prepayment changes cash timing; it does not repair weak economics. Stress-test usage spikes, discounts, rework, concentration and lost renewals. Cheaper models help competitors too; buyers may demand those savings.

Before calling a business durable, request recurring versus project revenue, cohort retention and expansion, deployment/support hours, fully loaded acquisition cost, customer concentration, cancellation rights and cash burn including founder labor. Separate bookings, annualized run rates, recognized revenue, receipts and profit.

For outcome pricing, define the outcome, denominator, attribution window, reversals and dispute process before charging. A booked appointment is not a completed repair order; a suggested credit is not money recovered. Price against verifiable customer value while accounting for delivery risk.

5. Restaurant opportunities, ranked

These are proposed entry points, not proven market gaps. Interview operators about what their existing tools already solve. An accountable exception queue is a stronger starting hypothesis than a generic AI receptionist.

1. Invoice and supplier-credit exceptions

Buyer: controller or multi-location operator. Match invoice lines with receiving records, agreed prices, credit notes and accounting entries. Flag duplicates, quantity discrepancies, missing credits and unit conversions; return source-linked evidence and a proposed resolution.

Data and control: authorized PDFs/EDI, delivery records, price lists, credit notes and accounting exports. Begin with approved exports. Bookkeepers approve accounting changes; managers approve supplier messages and payments.

Measure: credits actually received, verified duplicate payments prevented and net review time. Toast xtraCHEF already offers invoice automation and cost-management features. Its integration documentation distinguishes direct integrations from CSV exchanges requiring customer action. Investigate unresolved cross-system exceptions, not basic extraction alone.

2. Missed-call recovery with reservation integrity

Buyer: general manager or reservations lead. Triage missed calls and answer approved FAQs; offer actual slots and confirm only after the reservation system returns a booking ID. Escalate allergies, accessibility needs, deposits, complaints and unusual parties.

Data and measure: consented call events, venue policies, live availability and arrival outcomes. Count incremental seated parties, with capacity and no-shows included. SevenRooms Voice AI already serves reservations and FAQs. OpenTable partner APIs offer an access-requested sandbox; public documentation is not production permission. Differentiate on an unresolved language or recovery workflow.

3. Order-accuracy checking

Buyer: operations manager. Compare the confirmed item/modifier recap with point-of-sale and kitchen-display records. Preserve menu identifiers and prices; never invent substitutions or allergen safety. Humans resolve ambiguity. Measure remakes, refunds and verified errors against comparable orders.

Integration trap: the Toast Orders API leaves unavailable-item prevention to the integrator. API-created orders do not dispatch Toast Delivery Services, and the response does not reveal dispatch status. Order creation is not delivery completion. Gift-card and loyalty restrictions also need testing. Where configured, orders can reach the kitchen without manual approval: enforce the intended review boundary before a write.

4. Waste-to-prep recommendations

Buyer: chef or area operations lead. Combine measured waste, yields, purchases, sales and events into suggested adjustments for a few expensive perishables. Chef approval remains mandatory. Measure waste cost per comparable cover with stockouts and complaints as countermetrics.

POS sales alone do not measure waste. Capture and kitchen adoption cost money. Winnow already combines waste capture and operational support; vendor savings claims are not guarantees. Seek a narrower underserved setting or better delivery economics.

5. Staffing exceptions

Buyer: general manager. Flag coverage mismatches and propose qualified replacements using authorized availability, roles, demand and labor rules. Managers approve changes. Measure net manager time and service outcomes, not only fewer scheduled hours.

7shifts already offers scheduling and forecasting, with a forecast-override API. A broad AI scheduler is a weak default entry point; validate a specific exception incumbents leave unresolved.

6. Dealership fixed operations, ranked

Fixed operations means service and parts work. Start from a repair-order (RO) queue and the employee accountable for clearing it. Do not confuse loan servicing, vehicle sales and repair operations.

1. RO and warranty-evidence completeness

Buyer: fixed-operations director or warranty administrator. Before closure, flag missing notes, photos, mileage or timestamps and contradictions among the complaint, findings, authorized work and performed work. Link findings to source evidence and authorized, current OEM rules. Start with one make and claim category.

Data and control: authorized RO exports, technician notes, labor-operation references, inspection evidence and licensed warranty rules. Technicians attest facts; administrators determine eligibility and submit claims. Never fabricate diagnosis, time, evidence or coverage.

Measure: rework minutes and first-pass completeness. Recoveries remain provisional until paid, net of reversals. CDK’s warranty assistance program is relevant competition; establish a distinct pre-submission evidence problem.

2. Parts-readiness and stalled-RO queue

Buyer: service/parts manager. Reconcile appointments and open ROs with confirmed stock, orders, ETA changes and technician prerequisites. Flag likely stalls and prepare reassignment or update options. Humans approve orders, substitutions, cancellations and promised dates.

Measure: avoidable stalled hours, first-visit completion and aged work-in-process, controlling for job mix. Estimated arrival is not confirmed stock. Missing or stale inventory data can invalidate an apparently useful recommendation.

3. Advisor communication copilot

Buyer: service manager. Turn verified milestones into customer-update drafts and flag overdue callbacks. Advisors approve diagnoses, prices, additional work, authorization requests and completion promises. Record customer approval against exact scope and amount.

Technician voice transcripts must be editable and attributable. Measure callback load, update latency, complaints and net advisor time. CDK markets generative-AI inspection insights; the opportunity needs a specific unresolved queue, not autonomous repair advice.

4. Scheduling and no-show recovery

Buyer: service/BDC manager. Offer suitable openings based on skills, bays, parts and loaner capacity through authorized channels. Measure incremental completed ROs and contribution after marginal costs, not appointment counts. Full shop capacity limits demand-generation value.

Xtime covers service communications and appointments, while Tekion advertises Service Scheduler AI. Generic scheduling faces native competition; a specific neglected recovery workflow may still be valuable.

7. Integration constraints are commercial constraints

• Toast: Standard API access is read-only; writes/custom integrations are arranged separately. Verify scopes, locations, subscription eligibility, event behavior and fees before quoting.
• CDK/Fortellis: Confirm which RO fields and read/write operations are included in the proposed integration. Subscription authorization, certification and publisher pricing matter. Exact fees and field access for a proposed customer remain unknown.
• Tekion: Automotive Partner Cloud describes application approval and tiers with different access/rate limits. Confirm endpoint coverage, dealer authorization, cost and production terms.
• Reynolds: RCI involves participant application and certification. Obtain a written scope and quote; do not assume every field or write operation is available.

Tenant separation, least privilege, retention limits, audit trails, idempotent writes and human fallback belong in the product. Customer permission does not remove a platform’s access requirements. Credential sharing or scraping is not a substitute for denied access. Resolve rights to OEM material, call recordings and customer records before use; obtain qualified review of applicable consent and privacy requirements for the actual deployment.

For JayAI, retain Ruby project standards: small changes, provider adapters, tests first, independent review, held-out outcomes and side effects, measured cost/latency and release/rollback checks. The harness guide explains the runtime responsibilities. These are requirements and design choices, not proof that a new integration is installed.

8. Research momentum without mistaking it for demand

The following is a proposed weekly routine, not an active monitoring service. Keep ten candidates attached to specific operating tasks, then narrow to three investigations and one experiment. Include an established non-AI baseline and an unfashionable alternative.

Monday · discover · 60 minutes

Scan three lanes: GitHub Trending, targeted repositories and release notes; Hugging Face papers, models and datasets plus arXiv and OpenReview; then the YC directory, named customer accounts, job descriptions, procurement and practitioner discussions. A discovery signal earns investigation, not a recommendation.

Hugging Face’s download methodology counts requests to selected files, including HEAD requests, and discusses possible duplicate counting. Downloads are not unique customers. Funding and paper votes similarly reveal attention without establishing economics.

Tuesday · verify substance · 90 minutes

Inspect tagged releases, actual changes, tests, maintainers, security advisories, lockfiles, licenses and unresolved failures. Use GitHub’s release, statistics and issue interfaces with pagination and collection timestamps. Separate prereleases and monorepo packages, bots from human contributors, and pull requests from issues. Review substance rather than raw commit counts. The dependency graph helps inspect exposure; a clean scan is not a security guarantee.

Follow paper → code revision → dataset version → evaluation script. Examine baselines, contamination, holdouts, compute budgets, seeds, uncertainty and failure cases. Read model cards and dataset cards for intended use, limitations, rights and provenance. Reproduce one task-sized claim. Clean English-document scores do not establish performance on crumpled invoices or noisy calls.

Wednesday · investigate operating evidence · 60 minutes

Identify the buyer, process, frequency, current spend, integration owner and cost of mistakes. Prefer a named customer’s dated baseline to a logo wall, while remembering case studies select successes. Job postings show investment intent, not deployed value; deduplicate reposts. A SAM.gov opportunity is a procurement process, not an award or evidence of restaurant demand. Corroborate community complaints and record commercial unknowns explicitly.

Thursday · test a workflow · two hours

Use public, synthetic or explicitly authorized redacted examples. Compare manual work, rules/OCR/search and the incumbent product. Freeze holdouts before tuning. Record success, abstention, severe errors, review time, end-to-end latency and full cost per accepted result. Keep failed attempts in the denominator. Do not install an entire stack to evaluate one claim.

Friday · decide · 30 minutes

Write a one-page promote/watch/reject brief with links, counterevidence and next tests. Preserve rejected candidates so the next wave of hype does not restart the same investigation.

9. Six technical candidates to investigate

This is a task-relevant watchlist, not a fastest-growing ranking or a benchmark result. Repository and release references were researched on October 16, 2026; no code was installed, audited or benchmarked for this article. Exact deployed versions, dependencies, model rights and service terms need fresh checks. Framework licenses do not automatically cover model weights.

Choose a capability only when it improves the measured workflow. Layout-aware extraction, structured outputs, retrieval, evaluation, voice orchestration and durable execution are complementary techniques, not a requirement to install six frameworks.

10. Keep an evidence ledger and explicit gates

For every material claim record observation date, event date, source URL, version/hash, source independence, task/cohort, numerator and denominator, time window, baseline, result, limitations, counterevidence, confidence, owner and next test. Label source-reported claims separately from reproduced results.

For momentum analysis, use a stable comparison cohort—say 20 projects segmented by age and capability—with 7/30/90-day windows. Record absolute new stars, percentage growth and starting size. Sample substantive contributors and response times with sample sizes and unresolved issues. Record cohort changes and missing API results. Ten launch-week stars on a ten-star project are not mature adoption.

Score each dimension 0–5. Using weights 25, 25, 20, 15 and 15, total = sum(score × weight) ÷ 5, yielding 0–100. Keep attention metrics outside the score. If material evidence is missing, mark the assessment insufficient and do not calculate an advancement score. Unknown is neither zero nor a favorable assumption.

Illustrative management thresholds: at least 75 advances to a pilot proposal; 50–74 needs a targeted experiment; below 50 stays on watch. These are uncalibrated heuristics, not probabilities. Label confidence separately: claims only, triangulated evidence, or replicated results plus observed buyer behavior.

Regardless of score, block production on unclear rights, unauthorized data, unresolved critical exposure, absent rollback or human escalation, or severe-error failures. An average cannot cancel a failed gate.

11. Thirty days to a narrow paid pilot

Choose one sector and one queue. Start with invoice/credit exceptions or RO evidence completeness, whichever has an authorized data path, accountable operator and verified unmet need. The following activities require their own operational authorization; publication does not initiate outreach, contracts or data collection.

1. Days 1–7: interview five willing operators, map the manual baseline, identify the incumbent alternative and create the evidence ledger and holdout. Confirm the buyer and integration owner.
2. Days 8–14: benchmark two approaches, including a no-LLM baseline. Agree acceptance criteria and severe-error definitions before tuning. Stop if usable data or ownership is absent.
3. Days 15–21: run authorized shadow mode. Staff retain consequential decisions. Measure correction time, downtime recovery and peak-load behavior.
4. Days 22–30: offer a bounded fixed-price paid pilot only if gates pass. Specify scope, price, review owner, data handling, termination, success criteria and rollback. Retain a measurable renewal decision.

Hypothetical customer economics

Restaurant: 200 invoices × 4 net minutes saved ÷ 60 × $30/hour = $400 monthly capacity value. Add $600 independently verified credits for $1,000 gross benefit. Assumed $500 software plus $150 integration/operations costs leave $350 net value. These are invented assumptions, not customer data, prices or benchmarks. Time is cash savings only if paid hours fall, or economic value if capacity is productively redeployed.

Dealer: 400 eligible ROs × 3 net minutes saved ÷ 60 × $40/hour = $800 monthly capacity value. Add only actual incremental recoveries, not total claim value. Subtract recurring software, integration, review, support and error costs. Reject the economics when verified benefit cannot cover them. Do not double-count review labor already deducted from net minutes saved.

For both cases, net value is genuinely saved labor or productive capacity plus demonstrated incremental contribution, minus all incremental costs. Avoid counting total sales as incremental margin. Amortize setup separately when testing investment payback.

Pre-agreed success criteria and stop rules

Illustrative proposed gates: at least 25% lower net handling time, at least 90% precision for actionable flags, zero fabricated evidence or unauthorized writes, and at least 2× verified benefit relative to all-in recurring cost. These are starting points for operator agreement, not industry standards. The restaurant example above yields about 1.54× ($1,000 ÷ $650), so it would fail the proposed 2× gate despite positive net value.

Also measure missed-exception rate or recall, so high precision cannot be achieved by flagging almost nothing. Set sample size and uncertainty before launch. Compare randomized eligible cases or matched locations/shifts, accounting for volume, mix, staffing and seasonality. Report accepted outcomes over all eligible attempts, including failures. Small samples cannot establish rare-event safety; zero observed violations is a release criterion, not proof of zero risk.

Kill or redesign if access is unavailable, review consumes savings, native tools solve the need adequately, attribution is unsupported or the customer cannot fund repeatable profitable delivery. An unpaid demonstration is not product-market fit. Continue only with measured value, acceptable failure behavior and a buyer willing to pay.

12. Reading and next steps

Primary sources are linked beside the claims they support throughout this guide. Start with the SEC-filed Palantir results for reported economics, YC’s current RFS for investor interest, and the platform documentation in integration constraints before pricing a deployment.

The repository watchlist supplies technical candidates, not an endorsement of operational fitness. API eligibility, fees, versions, licenses and capabilities can change. Recheck exact contracts and deployed artifacts before a pilot; private-company profitability and customer-specific access remain unestablished here.

Read Money as a goal for AI for adjacent business questions, the Karpathy field guide for agentic engineering and verifiability, and our collaboration protocol for reviewed releases. This primer’s next useful artifact would be one evidence brief for one workflow—not another broad platform proposal.