Publish and install in the console¶

The concept behind publications is explained in Sharing and reuse.

Publications and Installed are how you share what you have built with other organisations. You bundle prompts, skills, agents, connectors or knowledge into a publication; whoever subscribes gets copies in their own environment, with every row saying where it came from.

Copies, not pointers. An installed prompt is an ordinary prompt of the subscriber's: it sits in their own library, falls under their own key policy, and is metered against their own usage. What the copy carries beyond an ordinary row is one fact: which publication it came from.

You need an administrator account of the organisation. You do the same with a key that holds management in Publish and install through the API.

Creating a publication¶

Open Publications and choose New publication.

A bundle for organisations below or for named organisations is open to subscribe to immediately -- there is nothing to install until you publish a version. A marketplace bundle starts as a draft: Artific reviews it before it is offered. See Marketplace.

Publishing a version¶

A publication with no version shares nothing. Choose Publish a new version; the form asks four things, in the order you decide them.

What goes in. One list per kind, over your own library: prompts, skills, agents, toolsets, API connectors, MCP servers, collections, pipelines, indexes, search tools, evaluations, aliases and scripts. Open a kind to pick from it. A row that is itself a copy from somebody else's publication is greyed with the reason: detach it first, or publish it where it is published.

For an API connector or an MCP server you choose at the same time what happens to its credentials: do not send them, the subscriber fills them in, or send your own. The last is only possible on a publication to organisations below -- a bundle that leaves your own tree hands your credential to strangers.

For a script the Scripts list says: The latest version’s files travel; Core copies them when you publish. With Withhold content (the term below), whoever installs sees the name, the description and the parameters, not the entrypoint or the files. Packages only you approved must be accepted by the recipient. In the bundle's member list a script says with its files (…), with how many files travel and how large they are together. A library from the sandbox image or one your operator approved travels by name; a package only your organisation approved travels with the bundle, and the subscriber accepts it by installing (Packages in a bundle).

Let the installer choose. Under every row you tick are the fields an installer can fill in themselves, each with its current value beside it (Now: …). For an agent these include model, instructions and temperature; for an index, embedding_model. Switch a field on and a parameter is added under Parameters, with your current value as the installer's default. If the field has no value now, the installer has to choose one. Switch the field off again and the parameter goes as soon as nothing else uses it.

Where the row names a tool of one of your own MCP servers or API connectors, in an agent's tools, a toolset's patterns or an alias's target, you also see Let the installer choose an MCP server or Let the installer choose an API connector. Switch it on and the installer picks a server or connector of their own organisation at install, and their copy uses it instead of yours. The server or connector itself then does not need to be in the bundle. For an MCP server, the parameter lists under Tools the server must offer which tools the bundle calls; if the chosen server lacks one, Check tells the installer so, as advice. Two references to the same server share one parameter.

Only install when. A chosen row can come along with one of the installer's choices and not with another. First add a parameter of type Choice under Parameters, then pick that parameter on the row and the values the row installs with. Always means no condition. A member that uses another member with a condition must carry the same condition, or Core refuses the version. An agent that calls the bundle's HubSpot server therefore comes along only when the installer chooses HubSpot.

Parameters. What the bundle asks every subscriber at install: a model, a text, a choice, a number, a URL, credentials, or a collection, index, key, MCP server or API connector of the subscriber's own. The fields you left to the installer above are already here; you can add your own with Add parameter. Per parameter you set whether it is required, what the default is and the explanation the subscriber is shown, and every parameter says where it is used. A parameter a member uses must be required or have a default, or Core refuses the version.

Terms. Five rules that hold while this version is installed:

Withholding the content and allowing a detach rule each other out: whoever detaches gets exactly the content you are withholding. Tick the first and the second goes off by itself.

What changed. The changelog a subscriber reads before accepting the new version.

Every subscription that follows the latest version gets this one automatically.

Example: a sales kit using the installer's CRM¶

Your sales assistant looks customers up in HubSpot, through your own MCP server hubspot. Whoever installs the kit may use Salesforce. There are two ways to handle that.

The installer connects their own CRM. You publish one agent that works with any server offering the tools it needs:

1. Under Agents, tick your sales assistant.
2. Under it, switch on Let the installer choose an MCP server at mcp__hubspot__search. A parameter of type MCP server appears under Parameters, with search under Tools the server must offer.
3. Give the parameter a name and explanation an installer understands, for example crm and "The MCP server of your CRM".

At install, the installer picks one of their own MCP servers, and their copy of the agent calls search on that server.

The installer picks one of your connectors. You ship a server for HubSpot and one for Salesforce yourself, and each subscriber installs only the side they choose:

1. Under Parameters, add a required parameter crm of type Choice, with hubspot, salesforce under Allowed values.
2. Under MCP servers, tick both servers, and for each choose that the subscriber fills in the credentials.
3. Tick the agent for HubSpot and the agent for Salesforce.
4. Set Only install when to crm with the value hubspot on the HubSpot server and the HubSpot agent, and to crm with salesforce on the two for Salesforce.

At install, the crm choice says which members it chooses, and the members of the other side are greyed out.

Text the installer fills in¶

Some text belongs to the organisation using a prompt: a company name, a product name, a sign-off. Put such a spot in a prompt's template or an agent's instructions as {{ $company }}:

You are the sales assistant of {{ $company }}. Answer questions about our products.

As soon as the text holds a {{ $name }}, Install values appears under the field, with one row per name. Fill in your own value there, such as Acme; your own prompt or agent uses it, so it keeps working as before. Take the spot out of the text and the row goes too. A row also says the value's Type -- Text, Number or Choice, with its Allowed values -- and a Description the installer sees beside their own value (Install values). A name consists of lowercase letters, digits and underscores, and starts with a letter or a digit. A value may not be empty and may not contain {{ or }}.

An API connector has the same rows for every {$name} in its URL or request (Values you set once).

When you publish the prompt, agent or API connector, every install value becomes a parameter of the bundle, of the same type as the install value -- text, a number or a choice -- with your value as its default and your description. A connector's secret install value is the exception: it becomes a credential parameter without a default, unless you send the connector's credential with it, in which case your secret travels along, sealed, and the installer may replace it. Under Parameters it says From your own install values. Whoever installs fills in their own value, and their copy holds that text literally where {{ $company }} stood.

A variable such as {{ ticket }} is something else: the caller fills it in on every call, and Core labels the value untrusted, and tells the model it is data when the calling key holds trust_envelope. An install value is set once and from then on is part of the instructions themselves; a name cannot be both.

Withdrawing a publication¶

Withdraw takes the bundle out of the offer. Existing copies are detached where the terms allow detaching, and deleted where they do not. What a subscriber detached themselves stays theirs.

Installing¶

Open Installed and go to Available. That is what your organisation may install: publications of the organisations above you, publications that name you, and everything on the marketplace. The Asks for column says how many values a bundle asks of you at install and how many of them are required, for example 2 (1 required). Underneath you can search the marketplace by name and description.

Click a bundle. Under the title it says how much the bundle asks for, and the first card is What you fill in: one field per parameter, required ones first, each with the publisher's explanation under it. Leave a field with a default empty and the default applies. Which field you get depends on what the bundle asks for:

If your organisation has no MCP server or API connector yet, the field says so, with a button to MCP servers or API connectors to add one first.

Below that are what the bundle is and what is in it, the licence and the terms. Above the list of members is how many of each kind it holds, for example Workflows · 1 and Agents · 2. A member with a condition shows it (Only when crm = hubspot); what your current choices leave out is greyed out. Advanced, folded, holds two choices you usually leave as they are:

• New versions: follow the latest version, or stay on the version you are installing now.
• Prefix: put in front of every name, so a policy rule can match all of them with acme-*.

Some bundles do not show you their content. The members' names and kinds are still there, with a lock beside them, and the page says why: the publisher withholds the content, or a live entitlement is needed that this organisation has not got (see Marketplace). What the bundle asks of you is still shown: you supply that, so it is never withheld.

Check tells you what installing with these values would mean before anything happens: which capabilities the bundle needs and which are off, which models this deployment has no entry for, which hosts would be reached, which names are already taken, what is still missing, and per key what its policy would refuse. Two sections are about your choices:

• Tools the chosen server does not offer: the server you connected did not have every tool the bundle uses at its last sync. Choose a server that offers them, or install anyway if you know the server has them by now: its tool list is refreshed at its next sync.
• Not installed with these choices: the members your choice leaves out. The rest of the check does not count them.

A bundle with scripts adds two things:

• Packages the bundle brings: Only the publisher approved these. Installing accepts them for the installed scripts alone; they do not join your own list. Each shows its name, version and file, marked publisher. On the installed script's page they keep that mark.
• A script needs the computer capability. When your organisation is not permitted it, the check says: Without the Computer capability no key of this organisation can call scripts. Ask the operator to add Computer; then you can install.

Only missing capabilities block; everything else is advice you can install around. A recommended key policy is the publisher's recommendation; Core never applies it itself.

Accept the terms and choose Install. The install itself happens in the background. If a required value is still missing, nothing is installed and the subscription reads Needs configuration. Its page then starts with what is missing (This install is waiting for: …); fill it in there and choose Save configuration, or fill in missing credentials under Credentials. The bundle is then installed after all.

Following a subscription¶

A subscription's page says where the install stands.

When a new version brings a script package the version you accepted did not, the subscription waits at Accept the terms too, and your copies keep running what they ran. The New terms notice then lists the packages that version brings, each marked publisher, and Accept the terms accepts both.

Under Configuration you supply what was missing; under Credentials you see which parameters have a value -- never the value itself, which is returned by nothing.

Sync now¶

A sync writes the publication into your copies again. Core starts one itself for a new version your subscription follows, and when you save Configuration or Credentials. Sync now, beside Remove on the subscription's page, starts one yourself, for example after you removed the cause of Stuck.

The button works for Linked, Partly detached and Stuck. After a click the page says Sync started., the subscription reads Installing, and the page refreshes itself until the work is done. For the other statuses the button is disabled, with the reason beside it, because each already has its own next step:

Outside the console, you ask for a sync with the token of an administrator of the organisation: POST /tenants/{id}/subscriptions/{sid}/sync. Core answers 202 with {"queued": true} for linked, diverged or stale, and otherwise 409 with a detail of sync_not_now: followed by the status, for example sync_not_now:needs_configuration. An API key with the management capability does the same with POST /subscriptions/{sid}/sync (Publish and install through the API).

Changing a choice later¶

What you filled in at install can be changed later on the subscription's page: another CRM server, another company name, another model. Change the value under Configuration and choose Save configuration. The copies follow after the sync that saving starts. New credentials go under Credentials; a changed password or token also reaches your copies that way by itself, without anything else having to change.

If your new choice changes which members are installed, Core installs the members that now come along and removes the copies of the members that drop out. A member you had detached stays. If one of your own agents still uses a copy that would drop out, it is not removed: the subscription reads Stuck with that member as the reason. Take the reference out of your agent and choose Sync now; that sync then removes the copy.

Detaching¶

Detach takes one member out of the publication's grip: from then on it is yours and follows no new versions. This cannot be undone. On a bundle whose publisher withholds the content it is not possible: whoever detached would get exactly that content.

A shared collection holds the publisher's documents: the sync copies them into your organisation, and your own index processes them there. While the collection is linked you cannot add documents of your own; an upload answers 409 naming the publication. Detach the collection to put your own documents in it.

Where a copy came from¶

Every row of your library that came from a publication says Shared through name. Click it to reach the subscription. While a copy is linked you cannot change it -- the page says so, naming the publication. Where the publisher withholds the content, you see that it is withheld rather than an empty field; a turn uses it unchanged.

A linked script copy offers no New version and cannot be deleted. A sealed one shows the name, the description and the parameters, but not the entrypoint or the files; you can still try it, and in a turn it runs on a computer of its own, which the model's shell tools cannot reach.

A sealed prompt copy lists each version's number and date; open a version to see its role. Where the template would be it says The publisher withholds this content., and it lists no variables and no install values.