Capability status
Every capability this manual names carries a status and a piece of evidence. Ninety are registered. Eighty-one are available to both audiences, three are platform administration for the operator, four are foundation — real code with a deliberately narrower usable capability, labelled IN DEVELOPMENT — and two are designed and not built, labelled PLANNED. Nothing is released as a beta. The machine-readable copy is at /docs-data/status.json.
How to read an entry#
| Word | What it means for you |
|---|---|
| Available | Running in production, reachable by both the operator's workspace and a customer's. |
| Available (operator) | Running, and deliberately for the platform operator — administering the business rather than using Connect. |
| Foundation | The model, service and tests exist; what you can use is narrower, and the page says how. |
| Not yet | Designed, not implemented. Nothing written about it describes behaviour you have today. |
| Reference | Background on a standard. Connect's own use of it, if any, is stated separately. |
Each entry also names its evidence — the module, the setting or the provider capability that makes the claim checkable. An entry that cannot be proved is excluded rather than softened.
The nine entries that carry a caveat#
This is the part of the register worth reading closely: nine of the ninety are places where an assumption would be wrong.
| Capability | Status | What that means for you |
|---|---|---|
| Password sign-in | Not yet | No password login and no third-party single sign-on. Google is the only route in. |
| Outbound webhooks | Not yet | Connect does not send events to your own URL today. The event document on the developer pages describes the design and says it is not delivered. |
| Call recording | Foundation | Asked of the provider rather than assumed, and not enabled on the live carrier. |
| Transfer of a live call | Foundation | An escalation queues a transfer and a supervisor can act on a call in progress; completing the handover to a colleague needs a provider capability that is not enabled. |
| SMS sending | Foundation | Provider-dependent. The live carrier carries no SMS, and the Phone screen says so rather than offering a thread that cannot send. |
| DLT registration data | Foundation | India's commercial-SMS register exists here; it does not by itself make sending work. |
| Payment verification | Available (operator) | Matching a payment notification against an expected reference. Platform administration. |
| JBRH's own pricing | Available (operator) | The operator's own commercial settings. |
| Website enquiries | Available (operator) | Enquiries sent to JBRH through the public site sit outside every workspace by design. |
The other eighty-one entries run in production for both audiences.
Account and access#
Six entries; five live, the sixth being the password row above.
| Capability | What that means for you |
|---|---|
| Google sign-in | The way in. OAuth with state, nonce and a verified identity token. |
| Workspace resolution | Which workspace you are in is decided before anything reads a setting. |
| Operator and customer routing | Both audiences reach the same implementation by their own paths. |
| Session replacement | Signing in as somebody else ends the session it replaced, in this browser. |
| Runtime on and off | New work stops at once, per channel, changing no setting. |
Email#
Twelve entries, all of them live. The ones a business notices:
| Capability | What that means for you |
|---|---|
| Gmail, Microsoft and IMAP or SMTP connection | Connect the mailbox you already have; it stays where it is. |
| Mailbox roles and health | Each mailbox has a purpose and a verdict; connected is not treated as healthy. |
| Drafting, holding and approval | A reply written from Knowledge, Memory and the thread, held where a gate stops it, editable before it goes. |
| Proof of sending, and writing back | Sent means the provider acknowledged it; answered threads are labelled and marked read in the mailbox itself. |
| Allowance, suppression and do-not-contact | The day's allowance holds work rather than dropping it; suppression is checked before every send and fails closed. |
Phone and voice#
Eighteen entries, the largest group. Sixteen are live; recording and the completed transfer are the two above.
| Capability | What that means for you |
|---|---|
| Answering an inbound call | Calls are answered, understood, and written down as a call record. |
| Placing an outbound call | Subject to consent, memory blocks, autonomy, budget and business hours. |
| Realtime speech-to-speech voice | The engine a workspace opts into, with its own worker fleet and capacity rules. |
| Voice Lab, speaking style and voice profiles | Where the voice is tuned, reviewed and given a regional speaking style. |
| Transcript and summary | Written from the call; a summary is refused where there was no conversation. |
| Live supervision and the softphone | Watch a call and intervene, or take your own line in the browser. |
WhatsApp and SMS#
Six entries. Four are live — WhatsApp inbound and reply, SMS inbound, and STOP handling, which honours an opt-out at once and records it as suppression. Sending an SMS and the DLT register are the two foundation rows above.
The work itself#
Thirty-two entries cover prospecting, relationships and sales, follow-ups and autonomy, knowledge and memory, and the Assistant with files and the Data grid. All thirty-two are live for both audiences:
| Capability | What that means for you |
|---|---|
| Prospect discovery, evidence and qualification | Research with the evidence kept, so a verdict can be checked rather than trusted. |
| No guessed email addresses | A rule rather than a default. A prospect with no discoverable address stays research. |
| One person across channels | Identities on phone, email and WhatsApp resolve to one relationship and one timeline. |
| Follow-ups, autonomy, approvals and the decision log | Dated commitments, per-channel rules, one queue, and every decision with its reasons. |
| Knowledge, facts and the four memory tiers | Source material, grounded statements, and what Connect has learned — each correctable. |
| Assistant, files and the Data grid | Sixty-six tools, files read and produced as versions, and thirteen record sheets. |
Platform and machine surfaces#
Fifteen entries; the three operator rows above are the platform administering itself. The other twelve are billing and usage, the three isolation layers, integration keys scoped to one workspace, and the published machine surfaces — this manual, its manifests, llms.txt, the MCP server, the agent card and the API descriptions.
The machine-readable copy#
The whole register is published as JSON at /docs-data/status.json, generated from the source this page is written from and carrying the generation date and product version beside each entry's word and evidence. A client deciding whether something is usable should read that rather than parse this page.
The truth map, capability by capability#
All 90 registered capabilities under the four public labels. Generated from the same register that every page is checked against, so it changes only when a capability's status does.
| Label | Register word | Capabilities | Meaning |
|---|---|---|---|
| AVAILABLE | Available, Available (operator) | 84 | Running in production. Includes the three operator-only entries. |
| BETA | — | 0 | None. Connect does not release a partial capability under a beta label. |
| IN DEVELOPMENT | Foundation | 4 | Real code and tests; what you can use is narrower, and the page says how. |
| PLANNED | Not yet | 2 | Designed and written down, not built. Nothing describes behaviour you have today. |
| Capability | Label | Evidence |
|---|---|---|
| A2a agent card | AVAILABLE | backend/app/a2a_server.py, webapp/.well-known/ |
| Approvals | AVAILABLE | backend/app/autonomy.py, autonomy_api.py |
| Arazzo | AVAILABLE | webapp/developers/workflows.arazzo.yaml |
| Assistant | AVAILABLE | backend/app/manager.py, manager_tools.py |
| Assistant tabs | AVAILABLE | webapp/src/features/connect-bubble/ |
| Assistant tools | AVAILABLE | 66 tools in backend/app/manager_tools.py |
| Asyncapi | AVAILABLE | webapp/developers/asyncapi.yaml — the description |
| Audit trail | AVAILABLE | backend/app/audit.py, audit_api.py |
| Autonomy modes | AVAILABLE | backend/app/autonomy.py |
| Barge in | AVAILABLE | backend/voice_worker/conversation.py |
| Billing usage | AVAILABLE | backend/app/metering.py, tenant_entitlements.py |
| Block directive | AVAILABLE | backend/app/connect_memory.py directives() |
| Call summary | AVAILABLE | backend/app/voice.py |
| Call transcript | AVAILABLE | backend/app/voice.py |
| Commercial pricing | AVAILABLE | backend/app/commercial.py |
| Conversation layer | AVAILABLE | backend/voice_worker/conversation.py |
| Cross channel identity | AVAILABLE | backend/app/identity.py, crm.py |
| Customer 360 | AVAILABLE | backend/app/relationship_console.py |
| Daily quota refusal | AVAILABLE | backend/app/metering.py, tenant_inbox.py |
| Data workspace | AVAILABLE | backend/app/data_workspace.py, workspace_data_api.py |
| Docs manifests | AVAILABLE | webapp/docs-data/ |
| Draft generation | AVAILABLE | backend/app/agent.py |
| Duplicate merge | AVAILABLE | backend/app/relationship_console.py |
| Facts editor | AVAILABLE | backend/app/knowledge.py |
| File versions | AVAILABLE | backend/app/file_workspace.py |
| File workspace | AVAILABLE | backend/app/file_workspace.py, file_formats.py |
| Followups | AVAILABLE | backend/app/followups.py |
| Gmail history sync | AVAILABLE | backend/app/tenant_inbox.py |
| Gmail oauth | AVAILABLE | backend/app/oauth.py, google_scopes.py |
| Gmail writeback | AVAILABLE | backend/app/gmail_writeback.py |
| Google sign in | AVAILABLE | backend/app/oauth.py, app_auth.py |
| Held draft approval | AVAILABLE | backend/app/autonomy.py, outbound.py |
| Html mail render | AVAILABLE | backend/app/mail_render.py |
| Human voice profiles | AVAILABLE | backend/app/voice_profiles.py |
| Imap smtp | AVAILABLE | backend/app/providers.py |
| Inbound call | AVAILABLE | backend/app/voice.py, voice_carriers.py |
| Indexnow | AVAILABLE | tools/docs_indexnow.py |
| Integration keys | AVAILABLE | backend/app/integration_auth.py, integration_api.py |
| Knowledge sources | AVAILABLE | backend/app/knowledge_bank.py |
| Lifecycle stage | AVAILABLE | backend/app/journey.py |
| Line health | AVAILABLE | backend/app/voice_engine.py line_health |
| Live supervisor | AVAILABLE | backend/app/supervisor.py |
| Llms txt | AVAILABLE | webapp/llms.txt |
| Mailbox health | AVAILABLE | backend/app/mailbox_console.py |
| Mailbox roles | AVAILABLE | backend/app/mailboxes.py, mailbox_console.py |
| Mcp server | AVAILABLE | backend/app/mcp_server.py |
| Memory editing | AVAILABLE | webapp/src/features/memory/viewer.js |
| Memory tiers | AVAILABLE | backend/app/connect_memory.py |
| Needs you | AVAILABLE | backend/app/operator_ui.py, needs-you feature |
| No guessed email | AVAILABLE | backend/app/prospect_contacts.py |
| Onboarding | AVAILABLE | backend/app/crm.py |
| Opportunities | AVAILABLE | backend/app/sales.py, sales_api.py |
| Outbound call | AVAILABLE | backend/app/voice_engine.py, comms_providers.py |
| Own tts voice | AVAILABLE | backend/app/voice_tts.py |
| Owner tenant routing | AVAILABLE | webapp/src/services/tenant-adapt.js, main.py |
| Payment verification | AVAILABLE | backend/app/platform_payments.py |
| Person company records | AVAILABLE | backend/app/people.py, companies.py |
| Phone followup drain | AVAILABLE | backend/app/runner.py chase_phone |
| Prospect discovery | AVAILABLE | backend/app/prospecting.py, prospect_discovery_query.py |
| Prospect evidence | AVAILABLE | backend/app/prospect_evidence.py |
| Prospect outreach | AVAILABLE | backend/app/sales_outreach.py |
| Prospect qualification | AVAILABLE | backend/app/prospect_scoring.py |
| Prospect upload | AVAILABLE | backend/app/prospect_upload.py |
| Public docs | AVAILABLE | webapp/docs/, tools/docs_build.py |
| Public openapi | AVAILABLE | webapp/developers/openapi.yaml |
| Realtime voice | AVAILABLE | backend/app/voice_engine.py, backend/voice_worker/ |
| Regional speech style | AVAILABLE | backend/app/voice_region.py |
| Rls isolation | AVAILABLE | backend/app/workspace_kernel.py + PostgreSQL RLS |
| Runtime on off | AVAILABLE | webapp/src/layout/power-control.js |
| Safe sales | AVAILABLE | backend/app/safe_sales.py |
| Send evidence | AVAILABLE | backend/app/outbound.py |
| Session replacement | AVAILABLE | backend/app/main.py |
| Sms inbound | AVAILABLE | backend/app/sms.py |
| Sms stop | AVAILABLE | backend/app/sms.py |
| Softphone | AVAILABLE | backend/app/softphone.py |
| Support cases | AVAILABLE | backend/app/crm.py |
| Suppression dnc | AVAILABLE | backend/app/prospect_compliance.py, comms.py |
| Timeline | AVAILABLE | backend/app/timeline.py |
| Voice cost metering | AVAILABLE | backend/app/voice_cost.py, ai_quota.py |
| Voice lab | AVAILABLE | backend/app/voice_style.py, voice_quality.py |
| Website enquiries | AVAILABLE | backend/app/connect_intake.py |
| Whatsapp inbound | AVAILABLE | backend/app/whatsapp.py |
| Whatsapp reply | AVAILABLE | backend/app/whatsapp.py, comms_providers.py |
| Workspace resolution | AVAILABLE | backend/app/workspace_kernel.py |
| Call recording | IN DEVELOPMENT | telephony.CAPABILITIES; not enabled on the live carrier |
| Call transfer | IN DEVELOPMENT | supervisor.py queues a transfer; provider capability gated |
| Dlt | IN DEVELOPMENT | backend/app/dlt.py — registration data, India |
| Sms outbound | IN DEVELOPMENT | provider-dependent; the live carrier carries no SMS |
| Outbound webhooks | PLANNED | described by asyncapi.yaml; no delivery implementation exists in the backend |
| Password sign in | PLANNED | deliberately off; Google OAuth only |
Questions#
Why is something listed as Foundation instead of simply missing?
Because the distinction matters when you are planning. Foundation means the model, service and tests exist and the usable capability is narrower, usually because a provider does not offer it. Missing would suggest nothing had been built.
Does a live entry mean it will work for my workspace?
It means the capability is running and reachable by both audiences. Whether it does anything for you also depends on what you have connected and what your plan allows — allowance questions rather than capability ones.
How current is this?
Each page carries the date its claims were last checked, and the JSON carries the date it was generated. Where the two disagree, trust the JSON: it is produced by the build rather than written by hand.