Your CRM data belongs on your phone, not someone else's server

Open Gong. Open Sybill. Open Clari, People.ai, Chorus, or any other sales AI tool that has launched in the last five years. They all work the same way. You connect your CRM. They copy your data to their cloud. They run their models on their infrastructure. Your deals, your contacts, your call transcripts, your pipeline, all of it sitting in someone else's database, accessible to their engineering team, their data pipeline, and whatever third-party sub-processors they use.

For most SaaS tools, this is fine. Your project management data living on Asana's servers is not a material risk. But CRM data is different. It contains the names and phone numbers of your buyers. The internal pricing you quoted. The objections they raised on the last call. The deal amount and close date for every opportunity in your pipeline. That is competitive intelligence. And you are handing it to a vendor who also sells to your competitors.

We built Chief of Staff to take a different approach. Your CRM data syncs to your phone. The AI runs on your phone. Nothing leaves the device. Here is exactly how that works.

Step 1: OAuth Connection

You connect HubSpot, Salesforce, Zoom, or Google Calendar using standard OAuth. Same flow you have used to connect any tool to any other tool. You authorize once, and Chief of Staff gets read access to the data you specify. No passwords stored. No credentials on our servers. The OAuth tokens live on your device, encrypted by the iOS or Android keychain.

We do not proxy the connection through our backend. Your phone talks directly to the HubSpot API, the Salesforce API, the Zoom API. We never see the data in transit. We never store it. The connection is between your phone and your CRM, period.

Step 2: Nightly Delta Sync

Every night, while your phone is charging, Chief of Staff fetches what changed since the last sync. Not your entire CRM. Just the delta. If three deals were updated and one new contact was added, it pulls those four records. For a typical pipeline of 20-50 active deals, this sync takes under 30 seconds.

For Zoom transcripts, it pulls any new recordings since the last sync. For Google Calendar, it fetches the next two weeks of events. The sync runs as a background task on iOS and Android, so you do not need to open the app. You wake up and your data is current.

Step 3: Local Chunking and Embedding

Once the new records arrive, they get broken into chunks of roughly 200 tokens each. A deal record might produce 3-5 chunks. A 30-minute call transcript might produce 40-60 chunks. Each chunk gets a 384-dimensional vector embedding using MiniLM-L6-v2, a 22MB model that runs on-device in milliseconds.

These embeddings are what make search work. When you ask "what did Sarah say about the procurement timeline," your question also gets embedded into the same 384-dimensional space. The system finds the chunks that are closest to your question in that space. That is semantic search, and it happens entirely on your phone.

The total size is small. 50,000 chunks with their embeddings take up roughly 73MB in the local database. That is less than a single podcast episode. You will not notice it on a modern phone with 128GB+ of storage.

Step 4: sqlite-vec on Device

The vector database is sqlite-vec, a SQLite extension purpose-built for vector search. It is fast, lightweight, and runs natively on iOS and Android. No server component. No network dependency. Your embeddings sit in a local SQLite file that is encrypted at rest by the operating system.

Query time is around 1 millisecond for a typical search across 50,000 chunks. You ask a question, the system embeds it, searches the vector store, and retrieves the 10 most relevant chunks before you finish blinking. That context gets fed to the on-device LLM, which generates the response. The total round trip from question to answer is under one second.

Why This Matters for Specific Industries

If you sell into defense or government, you already know the constraints. SCIF environments mean no external data transmission. Your security team will never approve a tool that sends deal data to a third-party cloud. But your reps still need meeting prep and deal intelligence. Chief of Staff works in airplane mode. It works in a SCIF. The data is on the phone and never leaves.

Financial services has similar requirements. Regulatory frameworks around client data, SOC 2 audits that scrutinize every vendor with data access, compliance teams that take months to approve new tools. When the data never leaves the device, most of those conversations become simple. There is no vendor data processing agreement to negotiate because we do not process your data.

Healthcare sales teams deal with HIPAA. If your CRM contains patient-adjacent information, provider contacts, or deal notes that reference clinical workflows, sending that to a third-party server creates compliance exposure. On-device processing eliminates that exposure entirely.

And even if you are not in a regulated industry, you probably have a security team that reviews vendor data practices. We have talked to dozens of sales leaders who wanted to deploy Gong or Sybill and got blocked by infosec for six months. Our architecture skips that bottleneck. There is no data to review because we never have it.

The Trade-off

I want to be honest about what you give up. Running on-device means smaller models. We use Apple Foundation Models on iOS 26 and Gemma on Android. These are capable models, but they are not GPT-4. For call summarization, deal prep, email drafting, and coaching, they are more than good enough. For writing a 4,000-word strategic analysis with nuanced reasoning, a cloud model would do better.

You also give up team-wide analytics. Chief of Staff is a personal tool. Your manager cannot see your conversations with the AI or pull aggregate data across the team. Some people will see that as a limitation. Others will see it as the entire point.