- Company
- Ramain (ramain.ai), AI employees for business processes
- Backing
- Y Combinator, Winter 2026 batch
- Location
- San Francisco, California
- Customers
- Operations teams in mortgage and lending, insurance, banking, pharma, healthcare operations and logistics
- Work in scope
- Enterprise demos and pilots, security reviews, customer process changes, hiring, investor updates
- Sources
- The founders' email, calendar, team chat, call notes and shared docs, read-only
- Agents
- A Reply Drafter and a Scheduler, every action approved by a founder
- Status
- Pilot in progress; no results published yet
The company and its world
Ramain builds AI employees. A team teaches Ramain a process once, watches it try the work, and then starts it from email, Slack, a text, a schedule or an API. The AI employee works through the same screens a person would, in web portals, ERPs, CRMs and spreadsheets, so the customer does not need an integration project first. Its customers are operations teams with heavy, repetitive work: posting supplier invoices, locking loans at the day's rate, updating claims in carrier portals, checking tax portal notices every morning.
Ramain went through Y Combinator in the Winter 2026 batch and works from San Francisco. Like most companies a few months after Demo Day, it is a small team doing a large number of jobs. The founders run enterprise demos, turn demos into paid pilots, answer security questionnaires, recruit the first go-to-market and research hires, and keep investors up to date.
Enterprise selling makes every one of those jobs longer. A lender or an insurer does not buy after one call. There is a demo, a scoped pilot, a vendor security review, a procurement step and a review with the business owner, and each step has its own thread, its own contact and its own date.
The problem before GeniOS
Ramain's product is very good at doing a defined process every time. The company's own week is the opposite of a defined process. Priorities move with each customer call, and the open items sit across two founders' inboxes, calendars and call notes.
| Thread | Where it lived | How it went cold |
|---|---|---|
| Demo to pilot | One founder's email and call notes | A prospect asked for a pilot proposal after the demo; the founder flew to the next demo and the proposal waited |
| Security review | An attachment in one inbox | A vendor questionnaire had a due date that no calendar knew about |
| Customer process change | A call note | A customer said a cutoff time had moved; the saved process for that customer still used the old one |
| Hiring loop | Calendar and chat | Interview feedback was owed by two people and given by neither |
| Investor update | Shared docs | The monthly update was half written and the date slipped by a week |
None of these is hard. Each one is small, each one belongs to a founder who is busy with something more urgent, and each one costs more the longer it waits. A prospect who waits two weeks for a pilot proposal starts a conversation with someone else. A security review that misses its date moves the pilot by a month.
How Ramain connected its tools
- Founders first
The two founders were the first users. Between them, their inboxes and calendars hold almost every commitment the company makes to customers, candidates and investors.
- Choose the sources
Email, calendar, team chat, call notes and the shared docs where the founders keep pilot plans, customer runbooks and investor updates.
- Read-only
Every source was connected with read access through the provider's own sign-in screen. GeniOS changes nothing in them, and any source can be disconnected at any time.
- Permissions agreed first
We went through the exact access for each source with the founders before anything was connected, including which customer folders and personal threads stay out of scope.
- Ramain's product stays separate
GeniOS does not log into Ramain's platform or its customers' systems. It reads what the founders read: the threads, notes and docs where customer work is discussed.
How GeniOS formed the goals
GeniOS read the founders' recent threads, call notes, pilot plans and investor updates, and drafted the goals the company was already working toward. The founders corrected the drafts in the first week.
| Goal | Where it came from | What GeniOS checks against it |
|---|---|---|
| Turn enterprise demos into paid pilots | Demo threads, call notes and pilot plans | Prospects waiting on a proposal, a document or a next meeting |
| Pass every security and procurement review on time | Questionnaires and vendor forms in email | Reviews with a due date and no owner |
| Keep live customers' processes up to date | Customer calls, runbooks and chat | Changes a customer mentioned that have not reached the runbook |
| Hire the founding go-to-market and research team | Hiring threads, calendar and chat | Candidates waiting on feedback or a next step |
| Keep investors informed | Investor threads and past updates | Questions with no reply and updates that are due |
The goals are what make a thread urgent or not. The same unanswered email matters more when it belongs to a pilot the company is trying to close this month.
The situations GeniOS picked up
Each morning, each founder receives a short brief: the few situations that need them today, in order. These are the kinds of situations the pilot is built to raise.
A demo that is waiting to become a pilot
The operations lead at a mortgage lender watched a demo of rate-lock work and asked for a pilot proposal with scope, timeline and price. The founder who ran the demo has been travelling to the next two demos. The thread has had no reply for six days, and the goal of turning demos into pilots puts it first.
A security questionnaire with a date nobody saw
A prospect's procurement team sent a vendor security questionnaire and asked for it back by Friday. It arrived as an attachment in one founder's inbox. Nothing on the calendar or in the pilot plan shows the date.
A customer whose process changed on a call
On a weekly call, a live customer mentioned that their daily cutoff for submitting locks had moved earlier. The call notes have it. The runbook the team keeps for that customer still shows the old time, so the AI employee would keep working to the old cutoff. This is the situation an execution tool cannot see by itself, because nobody has told it yet.
A hiring loop that stalled
A candidate for the founding go-to-market role finished the final interview. Two people owe feedback, and the candidate has written once to ask about next steps.
An investor update that slipped
The monthly update to investors is half written in a shared doc, a week after the date the founders usually send it. One investor has asked a question in the meantime.
The intelligence, and what happened next
| Situation | Sent to | Answer | What happens next | Closes on |
|---|---|---|---|---|
| Demo waiting on a pilot proposal | The founder who ran the demo | Delegate | A Reply Drafter drafts the proposal email from the call notes and the pilot template; the founder edits and approves it | The proposal sent |
| Security questionnaire due Friday | The founder who owns security | Later | Returns on Thursday morning with the questionnaire and the company's existing security documents linked | The completed questionnaire sent |
| Customer cutoff moved | The founder who owns the account | Done | The founder updates the customer's saved process and the runbook | The runbook showing the new time |
| Hiring feedback owed | The founder running hiring | Delegate | Passed to the two interviewers with a date; a Scheduler proposes a call with the candidate once feedback is in | Feedback recorded and the call on the calendar |
| Investor update late | The founder who owns investors | Delegate | A Reply Drafter answers the investor's question and points to the update going out on Friday | The update sent |
Approval before anything is sent. The agents draft and schedule. No email, invite or document goes out until a founder approves it.
Closed on proof. An item closes when GeniOS sees the sent email, the meeting on the calendar or the changed runbook, not when someone says it is handled.
Execution and judgement, side by side
Ramain and GeniOS work on two different halves of the same problem. Ramain's AI employees do a process the same way every time, once someone has taught it. GeniOS works out which work matters now, who owns it and what has changed, from the company's own threads and notes.
| AI employee (Ramain) | Company intelligence (GeniOS) | |
|---|---|---|
| Starts from | A process someone taught it | The company's goals and its live data |
| Good at | Doing the work the same way, every time, in any system | Seeing which work matters now and what has changed |
| Needs | An up-to-date process and a trigger | Read access to where work is discussed |
| Output | Finished work: an invoice posted, a loan locked | The next step, with one owner and a date |
The customer cutoff in the brief is where the two meet. The AI employee was right to follow its saved process. What it could not know was that the customer had changed the rule on a call. GeniOS caught the change and sent it to the person who owns that customer. For more on this split, read why agents need company context and the concept of the human-AI operating model.
The rollout, week by week
| Week | What the founders do | What GeniOS does |
|---|---|---|
| Week 1 | Connect email, calendar, chat, call notes and docs read-only; review the drafted goals | Reads recent history, drafts the goals and lists what is already open |
| Week 2 | Read the morning brief daily and answer every item | Learns which founder owns which prospect, customer, candidate and investor |
| Week 3 | First delegations to a Reply Drafter and a Scheduler, every action approved | Closes items only on the sent email, the calendar entry or the changed doc |
| Week 4 | Add customer runbooks to the shared sources | Checks what customers say on calls against their saved processes |
| Week 5 on | Bring the first hires in as they join | Keeps learning from answers and hands work to the new owners |
What is next
The pilot is still running, so this page describes how the founders work day to day and does not report measured results. Any figures will be published together with Ramain. As the team grows, the next step is to give each new hire their own brief, so the pilots and customers the founders hand over keep their owner and their date.
If you are a founder running enterprise deals with a small team, read how GeniOS works for founders and the founder morning brief, then book a call.