Integrations
It learns from what you already have.
No migration, no rebuilding your processes somewhere else. You connect a system, the Brain reads it, and what it finds becomes entities, memory and signals that everything else in the product can reason about.
One customer, however many systems they arrived from
This is the part that decides whether any of the rest is useful. A Brain that holds the same person three times is a filing cabinet with three folders per customer, which is the mess you already have.
- Keyed on a natural key
- An entity is identified by something real about it: a phone number, then an email address, then a key scoped to the system it came from. Never a row id where a natural key exists, because a row id is different in every system by definition.
- The connector does not decide
- The Gmail connector does not get to declare that an address identifies a person. It reports "this email address" and one shared set of rules decides what that means. That is what makes identity behave the same way 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 tells us they are the same. A wrong merge shows one customer's history to another, and there is no undo for that, so the system tolerates a duplicate over risking it.
- Running it twice changes nothing
- The rebuild is idempotent: entities and edges are upserted, signals and insights deduplicated, memories reinforced rather than duplicated. Safe on a schedule, and safe to press twice when you are not sure the first press worked.
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 is read-only. Everything OnDuty does back to the outside world is an action, and an action goes through the decision gate.
Google Drive
Available- Reads
- Documents and their revision history, and who wrote them.
- Becomes
- Documents as entities, linked to the people who authored and edited them, so an answer can cite the file it came from.
Gmail
Available- Reads
- Threads, participants and timing.
- Becomes
- 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
Available- Reads
- Events and attendees.
- Becomes
- Who met whom and when they last spoke in person, which is context a CRM almost never has.
WhatsApp
Available- Reads
- Conversations on the channel your customers actually use.
- Becomes
- Conversations and the customers in them, and it is also the one action connector: a reply sent here is an action, evaluated before it is sent.
Webchat
Available- Reads
- Conversations on your own site.
- Becomes
- The same conversation and customer records, with full context on a visitor who has been here before.
HubSpot
Needs setup- Reads
- Contacts, companies and deals.
- Becomes
- Companies and people reconciled against everything else, and a deal that has gone quiet as a signal.
The connector is built. It reports itself unconfigured until an app is provisioned, rather than appearing available and failing when you click it.
Salesforce
Roadmap- Reads
- Accounts, contacts and opportunities.
- Becomes
- The same reconciliation as HubSpot, against a different system of record.
Not built. Listed because it is the question every second conversation asks, and a roadmap item said plainly is better than a logo implying otherwise.
How a sync behaves
Reading somebody's whole Drive is not a request, it is a job. Treating it like a request is how an integration becomes a thing people turn off.
- Bounded, then resumed
- A run stops at a record budget, saves its position, and schedules itself to continue. Nothing tries to read everything in one pass and time out at ninety percent.
- A failed run keeps its place
- It saves its cursor too, so recovering from a failure does not mean starting from the beginning and re-reading what already worked.
- A revoked grant stops being retried
- Retrying cannot fix a revoked authorization, and retrying hides the fact that a person has to go and reconnect it. So it stops, and it says so.
- A transient failure backs off
- A rate limit or a blip is a different thing from a revocation and is treated as one: it waits, and tries again.
Where a conclusion came from
Every memory and every insight is traceable to the source it was built from. That is not a reporting feature, it is the thing that makes an insight arguable.
The Brain keeps two separate records about a connected system. One is the live plumbing: the credential, the cursor, the schedule. That is deleted the moment you disconnect. The other is the record of where knowledge came from, and it survives, marked as a source that is no longer connected.
They are separate because deleting the second one along with the first would quietly turn every conclusion built from that system into a conclusion from nowhere. A claim you cannot check is worse than no claim, and it is much worse when it used to be checkable.
Missing the system you run on? Tell us. A new connector is work rather than a switch, and we would rather quote you the work than show you a logo.
Connect one system and see what it already knows.
One source is enough to tell whether this is worth the second one. Start there.