Connecting Project and Knowledge Tools

The project tools

Asana, ClickUp, Monday.com and Jira all connect from the Integrations tab. Once connected, the agent gains tools for that provider — reading items, creating and updating them.

That means requests like 'what's assigned to me in Jira this sprint' and 'create a ticket for this' work without leaving Kavanah, and it means a report or a digest can include work that does not live here.

Writing to these tools falls into the external-write action category, so under the default policy those writes park for approval. That is worth knowing before you conclude a write did not happen.

Per-user sync is not a team mirror

This is the limitation that most often surprises people, and it is worth stating plainly.

An ongoing sync generally reflects the connecting USER's view — typically what is assigned to them — rather than mirroring an entire team's workspace. Connecting Asana does not import your company's whole Asana into Kavanah.

That is the right default for a personal integration and the wrong assumption for someone expecting a migration tool. If your goal is 'see everything my team has in Asana inside Kavanah', a per-user connection will not produce it, and discovering that after telling your team it would is an avoidable conversation.

What the connection is genuinely good for: giving each person's agent visibility of that person's work in the other tool, so answers about 'what do I have on' are complete.

Notion

Notion connects similarly and is a knowledge source rather than a task source for most teams.

The value is that the agent can search and read your Notion content, which matters if that is where your documentation lives. It can also write, under the same external-write governance.

If you are choosing where documentation should live going forward, note that Kavanah's own knowledge base is what the agent retrieves from most directly, and what the decision detector scans. Connecting Notion is the right answer for content that is already there; new content is worth putting where the machinery is.

ClearBooks

ClearBooks is the finance and bookkeeping connection: invoices, transactions, the general ledger, cap table, metrics, banking.

Connecting it gives the agent finance capability, which is what makes a finance-scoped persona worth creating. It is also the connection with the tightest governance implications — the finance action category covers payments and transfers, the invoice and bill lifecycle, and ledger entries, and it defaults to requiring approval for good reason.

Note the category boundary from Lesson 8.2: reference data like customers, vendors and GL codes is governed as an ordinary external write, while anything that changes what the business owes or is owed is finance. That distinction is deliberate and worth knowing when you set the policies.

Using a connection as a transition

The pattern that works: connect the old tool, do new work in Kavanah, and let the old tool drain.

What does not work is dual-running with both as sources of truth. Every team that tries it spends more effort on reconciliation than the migration would have cost, and the reconciliation never ends.

So set a date. Until then, the old tool is the source and Kavanah reads it. After it, Kavanah is the source and the old tool is read-only history. Say which side of the date you are on, out loud, to everyone.