Skip to main content

Group articles into modules

A module is a reusable selection of published articles - "Returns & shipping", say - that an Agent or App binds as one unit. Bind the module, and the Agent receives every article in it; add an article to the module later and every binding picks it up. That indirection is the point: curate once, and the agents that depend on the topic stay current without editing each one.

The Modules tab: a domain module and an org-wide module, each with its availability and descriptionThe Modules tab: a domain module and an org-wide module, each with its availability and description

Domain and org modules​

  • A domain module belongs to one domain and is what agents in that domain pick under Specific modules.
  • An org-wide module is curated by an organization admin and available across domains.
A module's page: the articles it carries, its availability, and the agents bound to itA module's page: the articles it carries, its availability, and the agents bound to it

Only published articles can join a module - a module can never smuggle someone's draft into an agent's context.

Curate deliberately​

A module is a promise about scope: an agent bound to Returns & shipping answers from returns and shipping material, not from whatever happened to be in the base. Keep modules topical and small; prefer two focused modules over one catch-all. When an article stops belonging, remove it from the module - every binding updates at once.

Tips​

If an article won't add to a module, it isn't live yet - an uploaded document must reach Active, a written article must be published. If an agent bound to a module doesn't see a new article, confirm the article was added to the module (base membership alone is not a binding). See Using knowledge in Agents.