It learns from what you already have.
No migration. You connect a system, the Brain reads it, and what it finds becomes entities, memory and signals everything else can reason about.
Six systems, one record
Identity is resolved on a natural key, phone before email before a system id, which is what makes the same person arriving from three places one node and not three. Every connector reads and none of them writes.
The four identity rules
This is the part that decides whether any of the rest is useful. A Brain that holds the same person three times is the mess you already have.
| Rule | What it means | Why |
|---|---|---|
| Keyed on a natural key | A phone number, then an email address, then a key scoped to its system. Never a row id where a natural key exists. | A row id is different in every system by definition. |
| The connector does not decide | Gmail reports "this email address"; one shared set of rules decides what that means. | Identity behaves the same across every source instead of being reimplemented four times. |
| It refuses to guess a country | A local number and an international one stay separate until something says they are the same. | A wrong merge shows one customer's history to another, and there is no undo. |
| Running it twice changes nothing | Entities and edges upsert, signals and insights dedupe, memories reinforce. | Safe on a schedule, and safe to press twice. |
The connector says what it saw. One shared set of rules decides what it means. That is the difference between a Brain and four inboxes in a trench coat.
What connects today
Each one read-only. Anything OnDuty does back to the world is an action, and an action goes through the gate.
Google Drive
reads documents, revisions, authors
Documents as entities, linked to the people who wrote and edited them, so an answer can cite the file it came from.
Gmail
reads threads, participants, timing
People matched to customers you already know, conversations as entities, and the observation that a thread has gone quiet.
Uses a scope Google classes as restricted. Verification is in progress, so access is limited until it completes.
Google Calendar
reads events and attendees
Who met whom and when they last spoke in person, which a CRM almost never has.
HubSpot
reads contacts, companies, deals
Companies and people reconciled against everything else, and a deal that has gone quiet as a signal.
Webchat
reads conversations on your site
The same conversation and customer records, with full context on a visitor who has been here before.
Telegram
your own bot, reads and replies
A bot your workspace makes with BotFather in two minutes. People message it and the Brain answers; bind an agent and the agent does, with every reply evaluated before it is sent.
No app review, no business verification, no waiting. The bot token is yours and stays encrypted; each delivery is checked against a secret we set when we registered the webhook.
WhatsApp
your own business number, reads and replies
Conversations and the customers in them, on the number your business already publishes. A reply sent here is an action, evaluated before it is sent.
Built, and not yet exercised against Meta. Meta requires business verification, a registered number, and app review of the messaging permissions before anyone outside your own app can be messaged. We set it up with you.
Custom source: push records
your system posts entities, memories, signals
A token issued in your workspace, for one source. Whatever holds it can send records in the Brain's own vocabulary and nothing else.
Not a developer API. There is no signup, no read surface, and a token opens exactly one route for exactly one source.
Custom source: read an API
any https JSON API, on a schedule
A base URL, an auth header, how it pages, and a mapping from its fields to the Brain's. Read on the same schedule as everything else.
Only https and only public hosts; a private address is refused when the form is saved and again before each read.
Custom source: a file
a CSV export, mapped to entities
The export every system can produce. Upload it whenever you have one; the columns you mapped become entities and memories.
Database: Postgres, read only
one SELECT inside a read-only transaction
Orders, invoices and inventory straight from the table, with a statement timeout and a row budget.
Only a single SELECT is accepted, and the session is read-only before it runs. MySQL and SQL Server are not built: each has its own way to make a session read-only, and claiming them with the Postgres guard would be claiming safety we cannot give.
Outlook Mail
reads conversations, participants, timing
Gmail's treatment on Microsoft 365: people matched to customers you already know and conversations as entities, from the inbox and from sent items, never message bodies.
One Microsoft sign-in serves the three Outlook sources. The consent screen says the app is unverified until Microsoft's publisher verification is done; it works either way.
Outlook Calendar
reads events and attendees
Who met whom and when, from an Outlook calendar, with rooms and equipment left out.
Outlook Contacts
reads the contacts folder as customers
The nearest thing a business without a CRM has to one. A contact with a phone number or an email address becomes a customer by the same rules as everyone else; one with neither is left out and counted.
OneDrive is not read. Mail, calendar and contacts are the three; documents would be a fourth connector on the same sign-in.
Facebook Pages
reads posts, comments, reviews
What the business posts and who answers in public. A review with a name on it is a signal with a name on it; a commenter is a person, kept apart from your customers because Meta hands over no email or phone to match them on.
One Meta sign-in serves the three Meta sources. Each permission needs Meta's App Review before anyone without a role on the app can grant it; until then it works for the app's own admins.
Instagram
reads media, likes and comments
The business account behind each Facebook Page: recent posts with their counts, and the people who comment on them.
Read only. Replying to a comment would be an action, so that permission is not asked for.
Meta Ads
reads campaigns, ad sets, each day's spend and results
The ledger of what was paid and what came back, one fact per campaign per closed day, with no judgement attached. What a good cost per lead is stays your rule.
Meta's Marketing API starts every app on a limited, heavily rate-limited tier; full access is another review. Lead Ads is not read yet.
Google Ads
campaigns, spend by the day, the account they run in
Campaigns as entities, each closed day as a fact with spend, impressions, clicks and conversions. The two signals are what the data states: a status changed, an enabled campaign shown to nobody. No judgement about performance.
Needs Google's approval before the first call: a developer token with Basic access from the API Center, and the adwords scope, which Google classes as sensitive, on the same verification as Gmail and Drive.
Google Business Profile
locations, reviews, the people who left them
A review is a customer saying something in public, which is a signal with a name on it. One or two stars with words under them is a complaint; a reviewer is a person who cannot merge, because Google gives no id.
Needs Google's approval before the first call: access to the Business Profile APIs is granted per Cloud project and the quota stays at zero until it is. The only scope Google offers is read-write; OnDuty only reads with it.
QuickBooks
reads customers, invoices, payments
Who owes what and since when, reconciled against the same people the CRM and the inbox know, and an invoice past its due date as a signal.
Sandbox companies connect now. Real companies once Intuit's app review is passed.
Salesforce
reads accounts, contacts, leads, opportunities
The same reconciliation as HubSpot, against a different system of record; a company is the same node whichever CRM named it.
Connects to any org whose admin allows the OnDuty connected app.
Any MCP assistant
Claude, Cursor, your own model runtime: reads, and if allowed, adds and proposes
The Brain as a Model Context Protocol server. A key issued in your workspace says exactly what the assistant may do: read, add what you tell it, propose what should happen. It can never accept, execute or send; a person does that in OnDuty.
Claude Code, Cursor, Windsurf and the Claude Agent SDK take a key you paste. Claude.ai, Claude Desktop and ChatGPT sign in instead, and OnDuty is the sign-in: you pick the workspace and tick the scopes. An admin can see every call by key and by tool, and shut every assistant out with one switch. Built and tested against the protocol; not yet exercised against a live Claude.ai or ChatGPT connection.
Missing the system you run on? Tell us. A new connector is work rather than a switch, and we would rather quote the work than show a logo.
How a sync behaves
Reading somebody's whole Drive is a job, not a request. Treating it as a request is how an integration becomes a thing people turn off.
| Situation | What happens | Why |
|---|---|---|
| The run reaches its record budget | It saves its position and schedules itself to continue. | Nothing reads everything in one pass and times out at ninety percent. |
| A run fails | It saves its cursor too. | Recovering does not mean re-reading what already worked. |
| A grant is revoked | It stops, and says so. | Retrying cannot fix a revoked authorization, and retrying hides that a person must act. |
| A rate limit or a blip | It backs off and tries again. | A transient failure is a different thing from a revocation. |
Two records about every source
| Record | What it holds | On disconnect |
|---|---|---|
| The live plumbing | The credential, the cursor, the schedule. | Deleted at once. |
| Where knowledge came from | Which source produced each memory and insight. | Survives, marked as no longer connected. |
Connect one system and see what it already knows.
One source is enough to tell whether this is worth the second one.
On duty ·