Skip to content

Sharing and reuse

You have built a support assistant for one customer: an agent, its prompt, two skills and a toolset. Your next customer wants the same assistant. Organisations share nothing by themselves, so copying by hand would mean making every improvement again at every customer. That is what publications are for: you build something once, publish it, and install it at every customer that needs it.

How it works

flowchart LR
    lib["Your library<br/>agents, prompts, skills, tools, knowledge"] -->|"publish a version"| pub["Publication"]
    pub -->|"subscription"| a["Customer A<br/>copies"]
    pub -->|"subscription"| b["Customer B<br/>copies"]
    pub -.->|"new version: sync"| a
    pub -.->|"new version: sync"| b
Term What it is
Publication a named bundle, in your organisation. You choose what is in it and who may see it
Version what the bundle holds at one moment. A publication without a version shares nothing
Subscription the installation of a publication in one organisation. It is listed there under Installed
Copy what the subscription puts in the subscriber's library. Every copy states which publication it came from (Shared through)

A subscriber gets copies, not references. An installed agent is an ordinary agent of the subscriber: it sits in their library, falls under their key policy and is booked to their usage.

A copy carries what the member defines, not how you classified it. Labels never travel, so every copy arrives unclassified. Metadata does travel, for a prompt, an agent or a connector alike, and every sync that updates the copy replaces it with the publisher's metadata.

What you can share

Prompts, skills, agents, workflows, toolsets, API connectors, SQL connectors, MCP servers, collections, pipelines, indexes, search tools, evaluations, aliases and scripts. A knowledge graph and a mail connector cannot go into a publication.

For an API connector or an MCP server you choose what happens to the credentials: do not send them, the subscriber fills them in, or send your own. The last is possible only towards organisations below you.

Who may see a publication

Visibility Who can subscribe For
Organisations below every organisation beneath yours your own customers
Named organisations only the organisations you name a limited group
Marketplace every organisation, after Artific, as the operator of the platform, has reviewed it a product you offer widely

With Install automatically, for Organisations below, every new organisation beneath yours subscribes straight away. That way a new customer starts with your standard setup without you installing anything.

Different per customer

Customers differ: another company name in the instruction, another model, their own CRM. A version can therefore have parameters the installer fills in:

  • a text, such as the company name, filled into an agent's instructions;
  • a model, a number or a choice;
  • an MCP server or API connector of the subscriber's own, so that your agent works with the customer's system;
  • credentials, or a collection, index or key of the subscriber.

A member can also be installed only for a certain choice. A bundle with an agent for HubSpot and one for Salesforce then installs only the agent that fits the customer's choice.

Updating: sync and detach

When you publish a new version, every subscription that follows the latest version gets it automatically: Core syncs the copies. A subscription can also stay on one version.

While a copy is linked, the subscriber cannot change it. When a customer wants to adapt a member themselves, they detach it: from then on it is theirs and follows no new versions. Detaching cannot be undone.

As the publisher you set terms per version: whether detaching is allowed, whether the content of the copies stays hidden from the subscriber, whether the subscriber may redistribute the members, whether only the agents in your bundle may use its prompts and skills, and a licence text. Hidden content and detaching exclude each other.

Content installed hidden stays hidden, and a subscriber can never publish a hidden copy in a bundle of their own, whatever the redistribution term says. A later version with other terms shows what that version brings, not what earlier versions installed, and a copy that gets detached keeps hiding what it was installed with. When only your own agents may use a prompt or a skill, a subscriber's own agent, or a copy of your agent the subscriber detached, is refused when it tries. That term decides who may run a prompt or a skill, not who may read it: hide the content as well if the subscriber should not be able to copy the text.

For a prompt, hidden content means its template, its variables and its install values. Its role, its version numbers and its metadata stay readable.

When to use this

  • You serve several customers with the same or nearly the same solution.
  • You want to make an improvement in one place and roll it out everywhere.
  • You want every new customer organisation to start with a base set.
  • You offer a solution to organisations outside your own tree, through the marketplace.

For one customer with a unique setup you need no publication: build directly in that customer's organisation.

How it fits together

  • Publishing follows the tree of organisations: by default from the top down.
  • A copy falls under the subscriber's policy. A prefix at installation, such as acme-, makes it easy to match all copies with one rule.
  • The Artific Connect bundles are installed from the marketplace in the same way.
  • A bundle on the marketplace can require an entitlement; payment for it happens outside Core.

Read on

Tutorial: Build one solution as a partner that you can use at several customer organisations.