The launch story for ConnectAI starts with a simple frustration: most business software waits.
It waits for someone to open a dashboard, remember the follow-up, search the CRM, check the inbox, compare the calendar, and decide what matters. Then it asks that same person to do the work.
ConnectAI is built from a different premise. A company already produces everything it needs to understand itself. The missing piece is infrastructure that turns that scattered activity into a durable, queryable company brain the business actually owns.
That is what ConnectAI is. Two self-hostable parts:
- **The database.** A governed-raw, per-workspace company brain in Postgres with vector search. Connect the tools a business already uses, and ConnectAI ingests, synthesizes, and serves retrieval over the full substrate.
- **The read-only MCP server.** An OAuth-authenticated Model Context Protocol endpoint that lets the workspace owner point their own agent (Claude, Cursor, a CLI, an app) at that brain, scoped to their workspace.
Self-host is the primary modality. A business runs ConnectAI on its own infrastructure by default, where the most sensitive intelligence it owns stays under its control. Managed cloud is the second option, a convenience, not the only or default way to run it.
The substrate, and the loop on top of it
ConnectAI connects to the tools a business already uses: Gmail, Calendar, Slack, meeting notes, CRM, accounting, scheduling, and more as coverage grows.
From those sources, it derives a durable company brain. That brain is not a static dashboard. It is the operating memory of the company: people, customers, policies, decisions, voice, playbooks, histories, and source-backed context. It is the database, and it is the product.
On top of that substrate, you can build. The reference proof-of-concept ConnectAI ships is a continuous agent loop, the original "self-improving company OS":
- Ingest the work already happening across connected tools.
- Make the company queryable.
- Surface signals when something needs attention.
- Draft the proposed action.
- Let the owner approve, edit, reject, or snooze.
- Record the decision in the ledger.
- Propose learning back into the brain.
That loop is the reference proof-of-concept that runs on the substrate, and it is the live hosted demo. It is not the product. The product is the brain and the MCP surface over it: durable infrastructure any agent or app can build on, the loop being one such build.
The product is not a chatbot with a company name on it. It is not another task manager. It is not a workflow builder that asks the owner to design the system before seeing value.
The first meaningful action is much simpler: connect your tools, ask your company a real question over the brain (in the product, or through your own agent over MCP), and see a grounded, cited answer.
Why the old model breaks
Small companies do not lack tools. They lack connective tissue.
Email knows one part of the story. The calendar knows another. Meeting notes carry commitments. Slack holds decisions that never made it into a doc. The CRM remembers a slice of sales motion. Accounting tools know what was paid or overdue.
The owner is usually the only place where all of that context comes together.
That creates a quiet tax on every founder and owner-operator: the mental work of reconstructing the company from fragments before doing anything useful.
ConnectAI exists to reduce that tax. Not by replacing the owner's judgment, but by bringing the right context to the moment where judgment is needed.
The company should tell you what changed. It should show you what it knows. It should draft the routine reply. It should notice the lead that went quiet, the customer question that repeated, the invoice that is stale, or the meeting commitment that has no follow-up.
Then it should ask before it acts.
The owner stays at the edge
The most important design choice in ConnectAI is restraint.
The product does not pretend relationship-heavy work can be safely automated away. A bad message, a wrong refund, or an overconfident record update can damage trust quickly. For small businesses, the relationship is often the business.
So ConnectAI proposes. The owner approves.
That approval is not only a safety feature. It is also the learning channel. When the owner edits a draft before approving it, the edit is a clean signal: this is how the business speaks, this is the nuance that was missing, this is the policy that should govern next time.
Over time, the system should need less correction because the company brain has absorbed more of the owner's preferences, voice, and operating rules.
That is the difference between a tool that helps once and a system that improves.
Make the company queryable first
Before a system can safely propose action, it has to answer questions with evidence.
What changed this week? What do we know about this customer? What did we agree to in the last review? Which sources are fresh, and which are still backfilling?
A confident answer without citations is just a new kind of mess. ConnectAI is designed to show citations, freshness, coverage, and source status so the owner can understand what the answer is based on.
That is why the first product surface centers the brain. Ask from real company context. See where the answer came from. Notice when the system declines because it lacks grounding.
The refusal is part of the trust model. Declining to answer is better than fabricating.
The difference
The market is filling with assistants, copilots, and agent suites. Many can draft text. Some can call tools. A few can take actions across a workflow.
ConnectAI's bet is narrower and deeper: the durable asset is the company brain, the database itself, and the value compounds as the business runs. The brain is yours, self-hosted, and any agent you trust can read it over MCP.
That means the important questions are not "Can an AI write an email?" or "Can an agent click a button?"
The important questions are:
- Does it understand this company specifically?
- Can it explain what evidence it used?
- Does it know when the source data is stale?
- Can the owner run it on their own infrastructure and keep the data?
- Can the owner point their own agent at it over MCP?
- Is every read and action auditable?
Those are the questions ConnectAI is built around.
The series
This launch article is the umbrella. The rest of the series explains the principles behind the substrate and the reference loop that proves it: why your company should be queryable, why ConnectAI starts with the tools you already use, why approvals beat autopilot, why the company brain is the durable asset, why citations and freshness matter, why edit-driven learning is the moat, and why owner-hours are the real metric.
Each piece is a different answer to the same question: why ConnectAI?
Because the next generation of business software should not be another place to manage work, and it should not lock the company's intelligence inside someone else's cloud. It should be infrastructure the company owns: a brain derived from its own tools, self-hostable, queryable by any agent over MCP.
ConnectAI is being built as that substrate. The self-improving loop is the reference proof-of-concept that shows what it makes possible.
Self-host the company brain on your own infrastructure, or run it on managed cloud. Either way, point your own agent at it over MCP.