Comparisons and concepts
Two kinds of page live here. One kind puts Connect next to a software category you already buy — a CRM, a helpdesk, a call centre — and says which of the two you actually need, including what the other does better. The other kind separates two Connect ideas that are constantly confused, and says what breaks when somebody confuses them.
How to read a comparison here#
None of these pages is a scorecard. A category comparison answers one question — *which of these two things is the answer to the problem you have* — and it can only answer it by being straight about where the other category is stronger. A business that buys Connect expecting it to replace a reporting tool has been sold something, not helped.
No competing product is named on any of these pages, and no claim is made about a competitor's behaviour. Categories are compared, because a category is a thing a reader can recognise and a vendor's current feature list is not something this documentation can verify.
Connect beside a category you already buy#
| Page | The question it settles |
|---|---|
| Connect and a CRM | Which system owns the customer record, and what a CRM still does better |
| Connect and a chatbot | Scope, memory across conversations, and who is accountable for an action |
| Connect and a helpdesk | Tickets, queues and SLAs against a worker that answers before a queue forms |
| Connect and workflow automation | When a deterministic rule is right and judgement is wrong |
| Connect and a call centre | Capacity and consistency against the things only a person can do |
| Connect and email marketing tools | Two consent models that must not be mixed |
| Connect and sales engagement tools | Sequences and cadence against evidence and refusal |
Distinctions inside Connect#
The second group is not competitive at all. Each page takes two ideas that appear next to each other in the product and are treated as synonyms in conversation, and separates them — because the cost of confusing them is a setting that does not do what somebody thought it did.
- Digital employee and AI agent — permanence and responsibility, not model capability.
- Agent and assistant — who starts the work.
- Memory and context window — one survives the conversation, one does not.
- Knowledge and memory — supplied truth against learned truth.
- Rules and instructions — what is enforced against what is asked for.
- Autonomy and approval — a standing rule against one held decision.
- Realtime and turn-based voice — two engines with different failure surfaces.
- MCP and A2A and MCP and a plain API — three ways of being called by software.
- Gmail API and IMAP — what each mailbox connection can and cannot know.
- llms.txt and a sitemap and structured data and content — publishing for machines without lying to them.
Several more distinctions live in this section and are written up elsewhere in the corpus: evidence and inference, drafting and sending, suppression and blocking, workspace and account, and operator and customer as a design idea.
What a comparison cannot tell you#
Fit. These pages describe mechanisms; whether a mechanism suits your business depends on volume, on how much of your work arrives as a message, and on how much of an answer your team can write down. A workspace whose knowledge is entirely in people's heads gets less from any of this than one that has written its answers down, and no comparison page changes that.
The use-case pages are the other half of the answer: they start from a situation rather than from a category.
Everything in this section#
27 pages, each with its own status and the date it was last checked against the running system.
| Page | What it covers |
|---|---|
| A record and a transcript | A transcript says what was said once. A record says what is true across everything that happened. Each answers questions the other cannot. |
| Agent and assistant | The engine starts work on its own and is governed by autonomy. The Connect Assistant answers a person and has narrower rights than they do. |
| Autonomy and approval | Autonomy is the standing rule for what Connect may do unasked. An approval is one held action waiting on a person. Changing one does not do the other's job. |
| Connect and a call centre | What answering every call the same way is worth, what it costs, and the three things on a live Connect line that a call centre still does and it does not. |
| Connect and a chatbot | A chatbot answers the person in front of it. Connect works a business's whole mail across channels, remembers, acts, and records who decided what. |
| Connect and a CRM | Connect keeps people, companies and deals as a by-product of work it does; a CRM keeps them as the thing itself. Which record belongs where. |
| Connect and a helpdesk | A helpdesk organises work into tickets and queues. Connect tries to finish the work before a queue exists, and keeps cases for what it cannot. |
| Connect and email marketing tools | A broadcast tool sends one message to a list that agreed to hear from you. Connect writes one message to one person. The consent models are not the same. |
| Connect and sales engagement tools | Sequence tools optimise cadence and volume. Connect optimises whether the message should be sent at all, and refuses to guess an address or a price. |
| Connect and workflow automation | Automation runs a path you drew in advance. Connect decides what a message needs. Where each belongs, and what happens when you pick the wrong one. |
| Digital employee and AI agent | An AI agent is a technical pattern. A Digital Business Employee is a commitment to permanence, responsibility and oversight. Confusing them costs money. |
| Drafting and sending | Writing a reply and sending it are two acts with very different consequences. Why the approval gate sits exactly between them and nowhere else. |
| Evidence and inference | Something observed and something concluded are not the same claim. Where Connect draws the line, and what each kind of statement lets you act on. |
| Gmail API and IMAP | Two ways to connect a mailbox to Connect. One knows about labels and history; the other works with any mail server in the world. What each costs you. |
| Knowledge and memory | Knowledge is what you told Connect is true about your business. Memory is what it worked out about a person. Putting a fact in the wrong one has consequences. |
| llms.txt and a sitemap | A sitemap is a protocol search engines actually read. llms.txt is a community proposal. Publishing one instead of the other costs you discovery. |
| MCP and a plain API | MCP exists so a model can discover what it may call at runtime. An HTTP API exists so your code can call exactly what it already knows it wants. |
| MCP and A2A | MCP hands tools and data to a model. A2A lets one agent give another agent a task. Connect publishes both, and they answer different questions. |
| Memory and context window | A context window is what the model can see during one call. Memory is what survives it. Enlarging the first will never produce the second. |
| Operator and customer, as a design idea | One codebase serving the platform operator and its customers: what the pattern costs on every change, and the class of defect it makes impossible. |
| Public documentation and private help | Some of what Connect knows is written for anybody to read, and some can only be answered inside your workspace. The line between them, and why it is drawn there. |
| Realtime and turn-based voice | Two voice engines with different physics: one speaks straight from the model, the other produces a sentence code can inspect before the caller hears it. |
| Rules and instructions | A rule is enforced in code whatever the model concludes. An instruction is text the model is asked to follow. One prevents; the other, at best, detects. |
| Scheduled work and triggered work | Work that starts because something happened, and work that starts because a time arrived. Two clocks in one system, and what happens where they meet. |
| Structured data and content | Markup describes a page; it is not a second page. When the two disagree the markup is the thing that is wrong, and the cost is not theoretical. |
| Suppression and blocking | Two ways of telling Connect not to contact somebody, enforced in different places. Which one you need depends on whether you mean an address or a relationship. |
| Workspace and account | Your account is who you are; a workspace is where the business lives. Which one owns what, and what happens when a person and a business part company. |
Questions#
Why are no competitors named?
Because a claim about a named product ages badly and cannot be verified from inside this documentation. A category is stable enough to compare honestly: what a helpdesk is for has not changed in a decade, while any particular helpdesk's feature list changes every quarter.
Do I have to choose one?
Usually not. Connect works alongside a CRM, a helpdesk or a marketing tool, and the practical decision is which system is the source of truth for which record. Each category page names that boundary explicitly instead of assuming you will drop what you already run.
Where do I check what Connect can actually do?
Every page in this corpus carries a status — available, foundation, not yet, operator-only or reference — taken from the capability registry rather than from prose. If a comparison page seems to promise something, check the status line and the section page it links to.