We get this question a lot: isn't Ada just ChatGPT with your data? It is not. And the difference is the entire product. Ada is the AI operator inside FounderOS — a conversational chief of staff that reads your portfolio, drafts your briefings, proposes status changes, executes low-risk work autonomously, and asks for approval before doing anything consequential. But the surface that people see — a slide-out chat dock on the right side of the screen, opened with ⌘J — is the least interesting part of how Ada actually works. The interesting part is everything underneath.
The four modes
Ada operates in four explicit modes, and which mode she's in is always visible to you: ModeWhat Ada doesDefault use AdviseReads, reasons, never writes"What matters this week?" ProposeDrafts pending actions, never executesNew initiatives, status changes, follow-ups Execute (low-risk)Acts directly, then logs the changeNotes, reminders, task creation Execute (approved)Acts only after you approveStage changes, outbound messages, connector writes A new account starts in Propose by default. Ada can read everything, but she does not write anything without you. As you watch her drafts and approve or reject them, you choose — explicitly, per category — what she's allowed to do autonomously. Most chatbots have one mode: say something back. Ada has four, and three of them result in real state changes to your business.
Every Ada capability is a typed contract
This is the part that matters most, and the part you can't see in the chat UI. Ada cannot do arbitrary things. She cannot "figure something out." She has a fixed, narrow set of typed function tools that look like this: os.update_venture_status({ ventureId, health, rationale }) os.create_initiative({ ventureId, title, ownerId, priority }) os.create_task({ ventureId, title, dueDate, assignee }) comms.draft_email({ threadId, intent, tone }) delivery.create_jira_issue({ projectKey, title, body })Every capability is a contract. Every contract has a schema. Every call is validated before it ever touches your data. If Ada tries to do something that isn't on the list, she fails — loudly — instead of improvising. This is the opposite of how most "agent" products are built. The fashionable design in 2024 was give the LLM access to everything and trust it. In practice, that's how you ship a product that occasionally deletes your CRM. We chose the opposite philosophy: Ada cannot do anything she does not have a tool for. That is a feature. The benefit is that every single thing Ada is capable of can be:
- Audited. Every tool call writes a structured log entry.
- Permissioned. Tools are gated by role.
- Risk-classified. Low-risk tools execute; high-risk tools require approval.
- Replayed. Approved actions are run against the system with the exact original payload, so what you approved is what gets executed.## The action request UX
When Ada wants to do something consequential, she does not just do it. She generates a structured action request:
- The exact field-level diff (health: yellow → red).
- The rationale ("last touched 11 days ago, two threads went cold, milestone slipped").
- The risk level (low / medium / high).
- An Approve / Reject button.You see it. You decide. If you approve, the change is committed with the original payload. If you reject, your reason is logged. The rejected actions are not wasted. They're training data — not for the model in the abstract sense, but for your Ada. Over time, she learns your taste: which kinds of drafts you reject for being too long, which integrations you don't trust her with yet, which decisions you always want to make yourself. This is what makes Ada usable in the long term. The first week, she'll be wrong about a lot of things. By week six, she'll know that you never let her touch the energy venture's blocker list, that you always rewrite her follow-up drafts to be 30% shorter, and that you reject every status change to red unless three independent signals agree.## Durable memory
Ada has memory. Real memory. Threads persist across sessions. The conversation you had last Thursday is still there next Thursday. The decision you made on the fundraise call is referenced when she drafts your next pre-read. Notes you captured into the system three weeks ago are retrievable when she's reasoning about a new initiative. The system of record is your MongoDB workspace — not the LLM's context window, not a vector database alone, not a fragile in-memory thing. Ada is a conversational surface on top of a durable, typed, queryable state. If the LLM provider went down tomorrow, your data, your audit log, your action history, and your venture state would all be untouched. Ada is replaceable. Your operating system is not.
What this means in practice
When you ask Ada:
- "Bring me up to speed" — she reads the Situation Room and answers from your state, not from priors.
- "Draft follow-ups for the financing threads" — she generates them as pending actions, you approve, they send.
- "Why is the dev-tools company yellow this week?" — she explains using the signals that triggered the flag.
- "What am I forgetting?" — she scans waiting-on items, neglected ventures, and unanswered threads.She is not impressive in the demo-day sense. She is useful in the Tuesday-afternoon sense. That's the bet. Founders don't need another AI that's amazing in a screenshot. They need one that's quietly correct on a Tuesday afternoon when they're running four ventures and have not slept enough. That's the job Ada has.