Modules

A module is a bundle of related tools that the agent can use. Modules are turned on per project — so your GitHub project might have the GitHub module on, while your CRM project has HubSpot on. You control what the agent has access to, project by project.

Built-in modules

ModuleWhat it does
NotesCreate, search, read, update, and delete notes inside the project. Perfect for a running scratchpad, decisions, research.
ContactsA lightweight CRM shared across your whole org — people, orgs, tags. Enable it in any project to give that project's agent access to the org-wide contact book.
GitHubRepos, issues, pull requests, files in a repo.
HubSpotFull CRM access via your HubSpot account.
FreshdeskTicket management.
MongoDBRead and write operations on your MongoDB clusters.
SpreadsheetRead and write Google Sheets.

Custom modules

On top of the built-ins, you can build your own — they're called custom modules, and the CLI makes it straightforward. The Google suite (Gmail, Calendar, Contacts, Drive) is actually a custom module in the Avi repo, not a built-in — you can install it the same way you'd install any other custom module.

Enabling a module

In a project's settings, toggle the modules you want on. Enabling a module:

  • Makes its tools available to the agent.
  • May open a sidebar panel in the project (e.g. the Notes module adds a Notes panel).
  • May require you to connect an account (e.g. linking GitHub or HubSpot via OAuth).

Tool-level control

Even when a module is enabled, you can disable individual tools inside it — useful if you want the agent to read from a service but not write or delete. Look for the tool permissions panel inside the project's settings.

What modules the agent can actually use

For a tool to be callable, two things must be true:

  1. The module it belongs to is enabled in this project.
  2. The specific tool is permitted in this project.

Both gates matter. Turning off a single tool is a quick way to keep the rest of a module's capabilities while blocking one risky one.