We don't have one AI strategy. We have three, and they only work because they don't compete.

This article is about how the trifecta divides labor on top of the Notion substrate we described in Parts 1 and 2 — what Notion AI and Notion's custom agents are good at, what Claude and Claude Code are good at, what NanoClaw is good at, and how all of them stay out of each other's way.

Three strategies, one division of labor

The simplest mental model:

• Notion AI and Notion's custom agents live where the data lives. They're the right tool for any task whose primary work is reading or writing the workspace. CRUD on the CRM, lookups in the sidebar, autofill on a database, agentic Q&A against pages. They have native access to Notion's structure, and they don't pay a network round-trip to use it.
• Claude and Claude Code are every employee's daily leverage layer. Long-form thinking. Code. Ad-hoc analysis on a CSV. Drafts that don't fit a database. Anything that's primarily unstructured — primarily a conversation with a smart collaborator — happens here.
• NanoClaw is the persistent fleet. Anything that needs to run on a schedule, watch a queue, monitor a Slack channel, ship code, or coordinate across systems happens here. NanoClaw's superpower is that it doesn't need a human to start it.

The connective tissue is MCP — the Model Context Protocol. Notion exposes the workspace via its native MCP server. NanoClaw consumes Notion via that MCP server and via its local SQLite Notion cache. Claude and Claude Code consume both. None of these tools needs to know about the others; they just need to speak MCP.

The thing that prevents these layers from competing is being precise about what each isn't good at. Notion AI is not the right place to do a long, multi-step research task — you'll be happier in Claude. Claude doesn't run on a schedule — that's what NanoClaw is for. NanoClaw isn't the right place to do quick CRM lookups — Notion's Slack agent is faster and lives where the data lives.

We re-litigate this every few weeks. It's worth it.

flowchart TB
    NAI["Notion AI + custom agents<br>live where the data lives<br>CRUD · lookups · autofill · agentic Q&A"]
    CC["Claude + Claude Code<br>the daily leverage layer<br>long-form thinking · code · ad-hoc analysis"]
    NCW["NanoClaw<br>the persistent fleet<br>schedules · queues · monitoring · shipping"]
    MCP["MCP — the connective tissue"]
    NAI --- MCP
    CC --- MCP
    NCW --- MCP
    MCP --- WS["The Notion substrate — structured, queryable, schema-locked"]
    style WS fill:#F4652F,color:#fff

Custom agents living inside Notion

We run a small fleet of custom agents inside Notion itself. Each one owns one entity and one verb.

The CRM Capture Agent is the headline one. It surfaces in three places — a Slack channel (#bd-ai-crm), the Notion AI sidebar, and traditional Notion forms — and it does one job: it turns a natural-language description ("New lead: Temple Digital, met at Canton Summit, interested in CBTC") into a properly structured record in the right database. It infers the record type, asks the right follow-up questions based on what's required, and files the row. The same agent handles updates ("set Temple Digital partnership status to Qualified") and lookups ("what's our pipeline in Commit?").

Companies CRM Enricher is an autofill agent. It runs against existing Companies rows and fills in the metadata that's painful to capture by hand — Region, Company Size, AUM/Revenue Band, ICP Segment, BitSafe Products of Interest. It works because the Companies schema is frozen. It can't invent new fields; it just fills in known ones from the corpus of source material it has access to.

Canton Apps Classifier is the same pattern, applied to the Canton Ecosystem Apps database. It tags new apps by category, stage, and relationship to BitSafe products.

BitSafe CRM Agent is the read-side counterpart to Capture. It answers natural-language CRM questions in Slack ("show me all open opps for Temple," "who owns the Dreamtech deal," "generate a pipeline summary for this quarter"), and it can create Tasks linked to specific Opportunities, which is how follow-ups from a call land in the right place.

The pattern across all of these: one entity, one verb, frozen schema. That's what makes them safe to run with broad permissions.

AI-powered SOPs

A different category of agent work runs on a schedule, against an SOP we write once.

Meeting prep. The Monday KinCloud sync, the Wednesday marketing meeting, advisory calls. Each has a Notion document SOP that describes how to assemble the prep doc — which databases to pull from, which fields matter, what the agenda template looks like. An hour before each meeting, the SOP runs and produces a draft prep doc. The owner edits it for ten minutes. The meeting starts on time.

Meeting Notes Processing. Every Fathom-recorded meeting gets a post-processing pass that extracts decisions, action items, and entity mentions. Action items become Tasks. Mentioned Companies and Contacts get linked. The summary is short, structured, and actually used.

Salesforce → Notion automation migration. This is its own SOP that's been running for the past two months — every Salesforce automation we still depend on gets analyzed (does it write data, just report on it, or trigger an external workflow?) and either rebuilt in Notion or deprecated. Part 4 goes deep on this.

The principle: humans write the SOP once, agents run it every week. The leverage isn't in the model; it's in the SOP being good enough that the model has nothing to argue about.

Autofill agents as the silent workhorse

Autofill is the most underrated capability in Notion's AI surface. Most users see it as a UX nicety. We treat it as the thing that keeps our most-used databases clean.

The hierarchy we follow:

1. Autofill if the value is derivable from other content (Region, ICP Segment, App Category).
2. Manual fields if the value is a judgment call only a human can make (Partnership Status, Priority).
3. Formula for purely deterministic transformations (display names, score combinations).

Autofill doesn't get credit because nobody sees it work. They just see a CRM that's never half-populated.

Notion ↔ NanoClaw via MCP

NanoClaw and Notion talk to each other in two directions.

NanoClaw → Notion (via Notion's MCP server). NanoClaw uses the native Notion MCP for searching, reading pages, querying databases, creating pages, updating properties, and appending content. We run two integration tokens: a broad read-only token, and a narrow read+write token that explicitly excludes the CRM and finance databases. (This is the dual-token model from the NanoClaw architecture piece — applied here at the Notion boundary.)

NanoClaw → Notion AI (the compilation layer). This is the more interesting direction. Notion AI does its own retrieval — semantic search, BM25, query expansion — across the workspace. For some questions, that retrieval is meaningfully better than NanoClaw's local FTS5 over the cached Notion content. So NanoClaw can call Notion AI as a sub-agent: it sends a question, Notion AI compiles an answer from the workspace, and NanoClaw uses that answer in whatever larger task it's running. Compilation is a different operation than retrieval, and Notion AI is good at it.

This is not a workaround. It's the model. Every layer of the trifecta does what it's best at, and the layers call each other when one of them has the better tool.

Worked example: the CRM Hygiene Monitor

A concrete example of three layers cooperating end-to-end.

The problem. CRMs rot. Stages go stale. Accounts go dormant. Close dates blow past. Required fields get skipped. Most companies "solve" this with a Monday-morning hygiene meeting that nobody enjoys.

The implementation. Four agent skills, each living in our Notion Skills database:

• Stale Stage — flags any Opportunity that has been in the same stage for more than its expected dwell time.
• Dormant Account — flags any partnered Company with no recent activity.
• Overdue Close Date — flags Opportunities past their close date.
• Missing Required Fields — flags rows that violate the locked capture-layer requirements.

Each runs every weekday at 9 AM ET. Output goes to a #crm-alerts Slack channel.

Cross-layer cooperation.

• The schema (Notion, Architect-owned) defines what "stale" means by setting expected stage dwell times.
• The skills (Notion Skills DB) define how each check is performed.
• NanoClaw runs them on schedule and posts to Slack.
• The BitSafe CRM Agent (Notion-resident) handles the human reply: "fix Temple — set close date to next Tuesday" gets parsed and written back to Notion.

There is no engineer in this loop. To change a check, edit the skill page. To change a routing rule, edit the routing-rules table. The behavior of the system is configured in Notion.

Governance

The most important agent work happens in the design phase, not at runtime.

• Schema lockdown. The databases an agent can write to have closed sets of options on every status, select, and multi-select property. The agent can't introduce new states.
• Master data ownership. Companies, People, Apps, Tags — Architect-owned. The agent can create rows in Companies; it can't mint a new Country or Region.
• Tier-1 vs tier-2 actions. Reads and routine writes flow freely. Destructive actions (deletes, archives, mass updates, anything touching financial data) require explicit human approval — not at the model layer, but at the harness layer where it can't be talked out of it.
• Token scoping. As described above, two tokens with mutually exclusive scopes. Compromise of either has a small, recoverable blast radius.

We did not give every employee an API key. We discussed it. We decided against it. Centralized API access at the top of the page tree, scoped by integration, is what keeps the workspace coherent — and it's what makes the agent layer governable. Per-user keys would create silent silos.

What we'd do differently

1. Build the trifecta in this order on purpose: Notion → Claude → NanoClaw. We sort of did this and sort of didn't. Doing it on purpose would have saved us a quarter.
2. Don't let any layer try to do another's job. When a Notion-native question shows up in NanoClaw, it should call Notion AI. When a long-form thinking task shows up in a Notion sidebar, the right move is to bounce it to Claude. Tools that try to be all three become bad at all three.
3. Budget for the boring middleware. MCP timeouts. Integration tokens. Sync drift. Permission scopes. This is where the project lives or dies, and it's the part nobody writes blog posts about. (We're trying.)

The compounding bet

The deeper thing this trifecta does — the part that's hardest to communicate from the outside — is that it gets better the more you use it.

Every recurring SOP we write becomes a skill the AI layer can run. Every correction we save becomes a memory entry an agent stops repeating. Every new database becomes another structured surface every layer can query without a code change. Every new hire inherits the system's memory on day one — context that previously took months of pattern-matching to absorb is queryable from the first week.

A company running this for twelve months is materially different from a company running this for one. That's the bet, and so far it's playing out.

Part 4 closes the series with the most concrete proof point we have: how we replaced our Salesforce CRM with Notion in under eight weeks.

<aside> 📚

Keep reading

Start with the hub: The Infrastructure Mindset, Turned Inward — How BitSafe Runs on AI

How BitSafe Runs on Notion — the brain:

Part 1: Notion as the Company OS · Part 2: The Architecture · Part 3: Agents, Automations, and the AI Layer (you're reading this) · Part 4: Replacing Salesforce with Notion · Part 5: The Agent Governance Model

The NanoClaw series — the reach:

Part 1: Building a Company-Wide AI Assistant · Part 2: The Architecture · Parts 3–5 coming soon · Companion: Cost Discipline

</aside>