Connectors

What nicoolAI can use on your behalf, what is live today, and which connectors are planned next.

Connectors are what let nicoolAI move from conversation into bounded action.

They answer a different question than channels:

channels are where you talk to nicoolAI
connectors are what nicoolAI can touch on your behalf

Without a connector, the agent can still advise, draft, and organize. With a connector, it can read, send, sync, or act in another system under explicit limits.

What matters most about a connector

Every connector should make one thing obvious:

What am I allowing nicoolAI to do?

Good connector docs should let a user answer that in plain language before they connect anything.

Current connector surface

Connector	Current shape	Use it for	Important limit
Google Drive	live now	reading linked Docs, Slides, and PDFs	read-only and file-type-limited
GitHub	planned	repository, issue, PR, and content workflows	not available to end users yet
Obsidian	planned	note and sync-oriented workflows	not available to end users yet
Personal email	planned	managing a user's own email account and inbox workflows	separate from the live `[email protected]` channel

This page is product-facing. It describes what nicoolAI should be understood to support, not every adapter definition that exists in the repo.

Google Drive

Google Drive is the clearest example of the connector model.

Use it when:

someone shares a Google Doc, Slide deck, or Drive PDF
the agent should read the file instead of asking for pasted text
you need separate named Google accounts such as personal and work

What it gives you:

user-scoped OAuth connections
read access to a narrow, documented set of supported file types
fail-closed resolution when the wrong account or no account is available

See Google Drive for the detailed behavior.

GitHub

Use it when:

the work belongs in repositories, issues, pull requests, or content changes
the user wants nicoolAI to act in GitHub with explicit account and installation boundaries

What to expect:

a GitHub App based connection model
named connections such as personal or work
explicit installation boundaries for org and repo access
refreshable user-scoped credentials
fail-closed behavior when installation or permission coverage is missing

See GitHub integration for the planned behavior.

Obsidian

Obsidian is planned as the notes and knowledge-work connector.

The role of that connector is straightforward:

connect a user's notes environment
keep note-linked workflows explicit
avoid turning private note state into invisible ambient access

Personal email

Personal email is planned as a connector, not a channel.

That distinction matters:

the email channel is about emailing [email protected]
the Personal email connector is about helping manage a user's own email account and inbox

How connector trust should feel

The connector model should stay legible:

the connection should be explicit
the scope should be understandable
missing or ambiguous access should default to deny
nicoolAI should never imply action capability that the connector setup does not actually grant

What comes next

The roadmap here is intentionally narrow and concrete:

GitHub for repository work
Obsidian for notes
Personal email for inbox and account-level email workflows

The standard should stay the same for each one: explicit connection, bounded scope, and plain-language expectations.