A connector list is not a rollout plan for a local-first AI assistant

The local-first assistant demo does not usually break on the model.

It breaks on setup.

Someone connects the obvious folder. Then the shared inbox. Then calendar. Then the ticket queue. Then CRM. Then the personal notes that "just help it understand context." The tool may still run close to your machine, but the installation has quietly become an integration project.

That is where teams need a connector manifest.

Not because local-first tools are bad. The current crop is interesting precisely because it brings private search, local storage, and work context closer to the people who own the work. But a connector list is still only a list of possible doors. It does not tell you which doors belong in the first room.

The new assistants are built around reach

The projects getting attention this week are not simple chat windows.

Khoj calls itself "Your AI second brain. Self-hostable." Its README says it can chat with local or online LLMs, answer from the web and documents, work with PDFs, Markdown, Word, and Notion, run through browser, Obsidian, Emacs, desktop, phone, and WhatsApp surfaces, and create agents with custom knowledge, persona, model, and tools.

Onyx is an open-source AI platform with more than 50 indexing connectors out of the box or through MCP. Its README describes self-hosted and proprietary model support, plus Docker, Kubernetes, Helm, and Terraform deployment paths. It also separates a Lite mode under 1GB of memory from a Standard mode with vector and keyword index, workers, and inference servers.

OpenLoomi describes "open-source proactive AI mates" that remember work details. Its README claims local-first storage with IndexedDB and SQLite, AES-256 encryption, no data leaving the machine, and auditable access logs. It lists connectors across messaging, email, calendars, docs, social accounts, Jira, HubSpot, Asana, iMessage, QQ, and RSS.

Cortex, a newer local memory project that appeared on Hacker News this week, narrows the category to on-device memory for agents. Its README says there are no third-party servers in the data path, telemetry is zero, encrypted sync is opt-in, privacy levels exist, MCP capabilities are deny-by-default, and query budgets are bounded.

The direction is clear: local-first assistants are moving closer to operational systems. That makes the setup step more important than the launch announcement.

The second connector is the real decision point

A single approved source is easy to reason about.

A support-policy folder answers support-policy questions. A handbook folder answers handbook questions. A project folder answers project questions. Scope, ownership, and failure modes are visible.

The second connector adds a different kind of material.

A calendar adds attendees and customer context. A shared inbox adds outside writers. A CRM adds relationship history. A task tool adds status changes. A chat archive adds shorthand, jokes, frustration, and stale decisions. A personal notes folder adds context that may be useful to one person and wrong for the team.

Those are not interchangeable sources. They should not enter a pilot under the same sentence: "connect company knowledge."

Each connector needs a job.

The manifest is the setup sheet

A connector manifest is the one-page setup sheet for the pilot. It says what is connected, why it is connected, how narrow the scope is, which test proves it works, and what causes removal.

Start with this shape.

This is not paperwork for its own sake. It changes the implementation conversation.

Instead of asking, "Does the assistant connect to HubSpot?" you ask, "Which HubSpot fields does this pilot need, which test proves it did not use private notes, and who removes the connector if the test fails?"

Run the connector tests before rollout

Most teams test assistants by asking impressive questions.

That is backwards.

Test the connectors with boring questions you already know the answer to. Use resolved tickets, old meetings, approved docs, and dummy CRM records. The goal is not to prove the assistant is clever. The goal is to prove it can stay inside the installation you intended.

A good connector test has four parts:

1. A known input.
2. The exact sources the assistant is allowed to use.
3. The output format you expect.
4. The failure that would make you disconnect the source.

For a support-doc connector, the test might be: answer these three policy questions, cite only the current policy folder, and fail if an archived page appears.

For a CRM connector, the test might be: summarize these two accounts using company, plan, renewal date, and open ticket count only. Fail if private notes, payment details, or internal sales commentary appear.

For a calendar connector, the test might be: prepare a meeting brief using title, attendees, linked account, and approved notes. Fail if personal calendar events appear in any output.

These tests are small. That is the point. If a team cannot test a connector in a narrow pilot, it will not understand the behavior after six connectors are live.

Local-first changes what you inspect

A hosted assistant pushes the review toward vendor controls: account permissions, data-retention terms, admin settings, and contract language.

A local-first assistant brings more of the inspection home.

Now the important objects may be folder mounts, local indexes, SQLite files, container settings, sync folders, model routes, MCP permissions, and logs. That is good if an operator can inspect them. It is bad if the tool becomes a private integration stack nobody owns.

Local does not mean ownerless.

For every connector, name the person who can approve a scope change, run the setup test, read the logs, and remove the integration. If the owner is "whoever installed it," the manifest is not finished.

Make removal part of the plan

Connector setup gets attention. Connector removal usually does not.

That is a problem because assistant pilots change fast. A folder gets reorganized. A ticket label changes. A CRM field gets repurposed. A memory that helped during onboarding becomes stale after the process changes. A source that seemed safe during read-only testing becomes risky once write actions are added.

The manifest should say what causes a connector to come out.

Examples:

• A deleted document still appears in answers.
• A personal event appears in a meeting brief.
• A CRM private note appears in output.
• A task status changes without review.
• A local memory has no source or expiry date.
• A connector owner cannot explain what the assistant used.

A removal trigger is not a sign the pilot failed. It is how the pilot stays small enough to learn from.

Do not skip receipts

The connector manifest says what the installation is supposed to do. The receipt shows what happened.

For a low-risk documentation assistant, a receipt can be simple: question, source document, cited section, answer, timestamp. For customer-facing drafts, keep the source records, assistant draft, reviewer decision, edits, and final action. For proposed updates to CRM, tickets, or task tools, keep the proposed field change before it becomes real.

That is the same pattern behind an agent receipts log. The receipt should be lightweight enough to use and specific enough to answer the question that always comes later: "Why did the assistant say that?"

If the connector cannot leave usable evidence, keep it out of the first pilot.

Buying questions for local-first assistants

The manifest also makes tool evaluation less fuzzy.

Ask whether source inclusion can be limited below the account level. Ask where local indexes live. Ask how deleted content leaves the assistant. Ask whether retrieval is separate from persistent memory. Ask whether MCP capabilities are deny-by-default or broadly available. Ask how logs can be exported. Ask whether a non-engineer owner can tell which connector produced an answer.

For broad platforms such as Onyx or Khoj, the useful question is not "How many systems can it connect to?" It is "Can we connect only what this workflow needs?"

For local memory projects such as OpenLoomi or Cortex, the useful question is not only "Does memory stay local?" It is "Can we see what became memory, where it came from, and when it should disappear?"

Those questions make the tool easier to buy, not harder. They turn a feature list into an implementation plan.

Start with one connector too few

A local-first AI assistant can be a smart choice for a small team. It can make private knowledge easier to search, reduce repeated questions, and keep more work close to the machines and people who own it.

It can also become a dense connector hub before anyone notices how many systems now feed it.

Start with one connector too few.

Name one workflow. Add only the sources that workflow needs. Write the setup test. Assign an owner. Define the removal trigger. Keep the receipt. Revisit the manifest after two weeks, before the assistant gets more reach.

If you want help turning a local-first assistant idea into a bounded workflow, BaristaLabs can help you scope the pilot, write the connector manifest, design the review points, and connect the first use case without letting the tool sprawl. Our process automation work focuses on useful automation with clear boundaries and evidence. If you want a second set of eyes on an assistant rollout, start here.