Hubs & distribution

In one line. Package what you built, publish it to a Hub, and install it into another project — so a solution you build once can run for many teams or tenants. You’ll be able to. Publish an agent (or a whole project) to a Hub, and install a published item into a different project, resolving its dependencies correctly. Where this lives. The Hubs chip on the top bar while you are in Studio (next to Exit Studio) — two entries, Solutions and Agents. Plus an agent’s own ⋮ ▸ Publish. If the chip isn’t there, it has been hidden for your workspace.

Structure travels, data doesn’t

You’ve built something that works. The next team wants it. The next tenant wants it. You do not rebuild it by hand each time — you package it once and install it everywhere.

The single load-bearing idea of this whole page:

Structure travels; data doesn’t.

A package carries the shape of your solution — agent instructions, schemas, flow steps, guard rails, pages. It deliberately leaves behind everything that is local, private, or specific to where it was built: your documents, your search index, your model credentials, and anything that identifies your workspace. Those are either re-created empty at the destination, required to already exist there, or wired up at install time to the destination’s own objects.

That is what makes a package safe to share across teams and tenants: nothing sensitive ships. A published item is a recipe, not a copy of your data. The rest of this page is the three verbs that make this real: package, publish, install.

The Hubs surface

Hubs is not one of the four Studio pillars. It is a labelled chip on the top bar, shown only while you are in Studio, next to Exit Studio. If you scan the four pillar names — Agents, Data, Experience, Governance — you won’t find it there. If the chip isn’t on your top bar, it has been hidden for your workspace; ask your administrator.

Hubs has exactly two entries:

Hubs entry	What it’s a registry of
Solutions	Whole solutions. Publish this project as a signed Solution, and install Solutions others have published.
Agents	Individual agents, published one at a time.

Both use the same browse-and-install screen, so you learn it once.

Watch out — two name collisions. “Agents” is both a Studio pillar (Studio ▸ Agents) and a Hubs entry (Hubs ▸ Agents). Whenever both could be meant, this page writes the full path. Likewise, a Solution on the Hub is a packaged, installable listing — not the same thing as “the solution you built”, which is just your project.

The browse-and-install screen — layout

Both Hubs entries render a two-pane layout:

List rail (left): a search box; a card per published item showing its logo (or generated initials on a gradient when there’s no logo), name, tags, and “Created At”. As a consumer you simply see the items available to you.
Detail pane (right): the selected item’s title, logo, a facts grid (name, tags), a Suggested Prompts section, and the full rich-text description the publisher wrote.
Empty states: “No Results” in the rail, “No Selection — please select an item” in the detail pane.

The single action you’ll use as a builder is the Import button in the detail pane.

The status model — Active, Approved, Rejected, Inhouse

A published item carries a status, and Hubs ▸ Agents (and the matching per-item hubs for guard rails, XFlows and the rest) only ever shows a consumer the Approved items — this browse screen does not merge in Inhouse items; that’s a separate, curated picker reached from Studio’s own Agents / Guard Rails lists.

Say so plainly: publishing does not put an item on the shelf. A single agent (or guard rail, or any other per-item publish) saves as Active the moment you publish it, which means waiting for approval — a platform administrator decides, on the screen below, and until they do the item is invisible to anyone browsing the catalog.

Status	Means	Set by
Active	Waiting for approval — published, and not yet decided on. (The label says “Active”; read it as “waiting”.)	The server, on every publish.
Approved	Cleared for use — this is the catalog everyone imports from.	An administrator.
Rejected	Turned down. You can change the item and publish it again.	An administrator.
Inhouse	Curated / featured, with suggested prompts attached.	An administrator.

The status is the server’s, not yours. You never set it. Publishing marks an item waiting; re-publishing something that was Rejected marks it waiting again (a rejection cannot be published over); and changing what an Approved item says or ships — its name, description, tags, logo, configurable tabs, suggested prompts or declared dependencies — marks it waiting again too, because what the administrator approved is no longer what would be installed. A re-publish that changes none of those keeps the status it had.

Only approved items can be read or installed. The import catalog serves you Approved and Inhouse items and nothing else; asking it for the waiting or rejected ones is refused unless you are an administrator, and so is opening what is behind one. Installing something that is still waiting, or was turned down, is refused with a reason — a waiting item becomes installable the moment an administrator approves it.

Role-gated. As an ordinary builder you publish and import; an administrator decides. The decision is Approve or Reject, and it is made on the screen below.

Where an administrator approves

An administrator opens Account menu ▸ Administration ▸ Admin ▸ Extensions ▸ Hub Servers and chooses the Waiting for Approval tab. It lists everything published to this hub and still waiting for a decision — agents, agent teams, guard rails, XFlows and libraries — with who published it and when. Approve puts it in Hubs, where every workspace on this environment can install it; Reject leaves it out, and the publisher can change it and publish again. The tab is restricted to administrators; anyone else sees a notice saying so, never an empty list.

Publishing

Two ways to start a publish

You can publish at two granularities:

A single agent — open the agent at Studio ▸ Agents ▸ Agents, use its ⋮ menu, choose Publish. This puts one agent into Hubs ▸ Agents.
A whole project — Hubs ▸ Solutions ▸ Publish to Hub. This packages the entire project as a signed Solution (see “The Solutions marketplace” below).

Both open a publish dialog. The single-agent dialog is shown here; the Solution publish modal is covered below. The idea is identical: describe the package and confirm what ships.

┌─ Publish Your Agent - Contract Reviewer ───────────────────[×]┐
│ Choose a Template or Upload                                    │
│ [ Upload ] [img] [img] [img] [img]     (≤ 2 MB, ≤ 1024×1024)  │
│ Name *            [______________________________]            │
│ Description *     [ rich-text editor ..................... ]   │
│ Tags              [ legal × ] [ nlp × ] [ + add ]  (max 10)    │
│ Publisher Name    [______________________________]            │
│ Template Setup Tabs  [ Data Sheet ▾ ]   (Data Sheet / Drive)  │
│ ── shown ONLY if this agent needs them ──                     │
│ LLM Model Description *   [ "any general-purpose chat model" ] │
│ View Description *        [ "the invoices view" ]              │
│ Datasheet Description *   [ "the line-items sheet" ]           │
│                                          [ Publish ]          │
└───────────────────────────────────────────────────────────────┘

What every control does

Control	What it does	Notes
Logo	Upload an image or pick one of 4 defaults.	Upload ≤ 2 MB, ≤ 1024×1024 px (checked in-browser).
Name *	The published name.	Required; letters/numbers/`_`, must not start with `_`; max 100 chars.
Description *	Rich-text explainer for importers.	Required. This is what someone reads before importing.
Tags	Searchable labels.	Up to 10. For a whole-project Solution, at least 1 tag is required to publish.
Publisher Name	Your name / org.	Max 100 chars.
Template Setup Tabs	Which extra surfaces ship — Data Sheet, Drive.
Dependent-description fields	One required textarea per unresolved dependency the agent references.	Appear only when the agent actually has that dependency — see next.
Publish	Publishes the package.	Enabled only when the form is valid (and, for a Solution, has at least 1 tag). For an item that already exists this button reads Update.

What travels, what must already exist, what you point at

When you publish, the platform walks everything the agent needs to run and sorts it into three buckets. This is the heart of “structure travels, data doesn’t”, and it’s why some dependency fields appear in the dialog and others don’t.

Bucket	What happens	Ships in the package?	Example
Travels inside the package	Pure configuration, carried along and re-created fresh at the destination.	Yes.	The agent’s sub-agents, its skills, its guard rails.
Must already exist where you install	A capability the destination has to provide. Checked at install; never shipped.	No.	A language model; an MCP server and its credentials.
You point at something local	A project-local data dependency. The package carries a description of what it needs, and you wire it to one of your objects during install.	No — the wiring travels, not the data.	A knowledge collection; a View or a datasheet the agent reads.

Concretely, for the Contract Reviewer agent above: its sub-agents and guard rails travel inside the package and are re-created in the destination project. Its language model must already exist there — the package says “I need a general-purpose chat model”; it does not carry your model connection or its key. Its knowledge collection, view and datasheet are pointed at something local — the package carries a plain-language description, and the importer maps each one to their own object at install.

This is why the dialog grows extra textareas: for each dependency the agent actually has, you write a one-line description so the importer knows what to pick. “LLM Model Description: any general-purpose chat model.” “Datasheet Description: a table of contract line-items with a clause column and a risk column.” Those descriptions are shown to the importer at the exact moment they choose the local object to bind.

Tip. Good dependency descriptions are the difference between an install that just works and one that confuses the next team. Write them for someone who has never seen your project.

Exporting a project to install it somewhere else

A whole project travels in two ways. Both carry its shape — agents, fields, flows, pages — and leave its documents and credentials behind (a Hub package carries sample files only if you add them); you connect those where it lands.

Through the Hub — in the project, open the Hubs chip on the Studio top bar ▸ Solutions ▸ Publish to Hub, describe the package and confirm what ships. Then, where you want it, open Hubs ▸ Solutions, pick it and install it as a new project or into a project you already use (Installing into a project you already use). Choose this when other teams should find it and receive its updates.
As a file — Studio ▸ Governance ▸ Versioning ▸ Snapshots ▸ Export Compact downloads the project as one portable file. In the project where you want it, open the same page and drop the file on its Import zone; it is reviewed before anything is installed.

Installing

Importing a published item into your project is the mirror image of publishing. Open the Hubs entry, select the item, read its description, and click Import.

The import / install flow

Browse & select. Open Hubs ▸ Agents, find the item, read its description and suggested prompts. The catalog you see is the Approved set: a published item appears here once an administrator approves it on Hub Servers ▸ Waiting for Approval (see above).
Import. Click Import. If the item has no unresolved dependencies, it imports straight away — you’ll get a “<Name> imported successfully” toast and it appears in your project.

Point each dependency at a local object. If the item does have dependencies, a configuration dialog opens. For each one you pick something in your project:

┌─ Import: Contract Reviewer ────────────────────────────────[×]┐
│ This agent needs you to map the following to your project:     │
│ LLM Model *   [ Select a model ▾ ]                             │
│   "any general-purpose chat model"    ← the publisher's note   │
│ View *        [ Select a view ▾ ]                              │
│   "the contracts view"                                         │
│ Datasheet *   [ Select a datasheet ▾ ]                         │
│   "contract line-items table"                                  │
│                                          [ Import ]            │
└────────────────────────────────────────────────────────────────┘

An agent always needs a language model, plus a View and/or datasheet if it referenced one, and a collection if it reads knowledge. Each field shows the description the publisher wrote so you know exactly what to pick. You map each dependency yourself at import.

Execute. Confirm. The platform re-creates the embedded pieces in your project and wires the rest to the local objects you chose.

The Solutions marketplace

Hubs ▸ Agents imports from your own environment’s catalog. Hubs ▸ Solutions is different: a marketplace browser over signed whole-project packages that travel between installs.

The page opens on a collapsible Featured rail (the top-installed Solutions), then a split master–detail browser: a master list on the left (search box, category facet, sort by Most installed or Name) and a detail pane on the right for the selected Solution — its icon, a Signed pill, a version picker, the install buttons (Install here into the current project, or Install as new which names and creates a project), and a ⋯ menu (promote this version to the next environment, request a production release, roll back, remove from Hub). Stat tiles show installs, module/model counts and the current version, above four inline tabs:

Detail tab	What it shows
Overview	Summary, the environment promotion ladder (which version is live in each environment), the signature & compatibility check, and adoption stats.
Setup guide	The publisher’s markdown guide, rendered inline.
Version history	Every published version with its summary, publisher and date.
Samples	Sample/demo files shipped with the Solution, downloadable.

Publishing here is the header’s Publish to Hub modal: name, version, category, summary, a listing icon, the setup-guide markdown, optional sample files and a demo entry point (where “Run demo” lands after install). The receipt shows exactly what shipped — asset count, bytes, content hash — with secrets redacted.

Because these packages cross environments, the marketplace layers on trust + preflight + approval:

Verify — the package is signed; the signature is checked before anything installs.
Preflight — Check install compatibility in the Overview tab lists each requirement as met or missing before you commit. A Solution is stamped with the platform version of the environment it was built on, so installing onto an older one fails the compatibility check up front instead of failing later.
Credentials preview — the same check tells you “you’ll need to configure N credentials” (counts and where — connection keys, script secrets — never values), so the key-configuration work is known before install, not a surprise wall after.
Approval — some installs are approval-required and offer a one-click Approve & install. A production release is a request that lands in the Release Approvals queue on Account menu ▸ Administration ▸ Admin ▸ Extensions ▸ Hub Servers, where a Super Admin signs it off; the target hub is fixed at the moment you request, so if the destination changes before approval the approval is refused. The Hub servers your install trusts — which hubs you publish to and install from — are managed by a Platform Admin on that same page. See Access & roles for who those seats are.
Upgrades & rollback — an installed project shows an update banner when a newer version is published: upgrade in place (keeps documents, queues and history; auto-saves a rollback snapshot) or install side-by-side. Roll back returns the project to a prior published version.

What an installed object looks like afterwards

This is the reassuring part: an installed object is just a normal project object. An imported agent shows up in your Studio ▸ Agents ▸ Agents list like any agent you built by hand. There’s no special “imported” mode to learn — once its dependencies are wired, it’s yours, editable in the usual builders, picked from the usual pickers.

A whole Solution, or just one agent?

There are two grains of packaging. Choosing the right one is mostly about where the result lands.

	Solution (whole project)	A single agent
You publish	An entire project	One agent
Where it installs	Creates a NEW project (Install as new) or into the current one (Install here)	Drops into an EXISTING project
Use when	Standing up a complete, repeatable solution for a new team/tenant (“the whole Invoice Processing app”)	Adding one reusable piece to a project you already have (“just the Contract Reviewer agent”)

When in doubt, ship a Solution — it carries the collections, flows and pages the agent depends on, so there is far less to wire up at the other end.

Try it yourself

Publish an agent, and follow it through the approval that puts it on the shelf.

Part A — publish (in Project A):

Open an agent you’ve built — ideally the one from A3 · Your first agent — at Studio ▸ Agents ▸ Agents.
Open its ⋮ menu and choose Publish.
In the dialog: pick a logo, give it a clear Name and Description, add a couple of Tags (e.g. demo, extractor).
Fill in any dependency-description textareas that appear — note which ones appear, and which bucket each falls into: the model must already exist at the destination; the knowledge collection, view and datasheet are things the importer points at locally.
Click Publish. Your item saves as Active — waiting for approval.
Switch to a different project, open the Hubs chip, then Hubs ▸ Agents. Your agent is not there yet: the catalog shows what an administrator has approved. Ask one to open Hub Servers ▸ Waiting for Approval and approve it — or do it yourself, if you are one — then look again. That round trip is the thing to feel here.

Part B — publish the whole project instead:

Back in Project A, open the Hubs chip ▸ Solutions ▸ Publish to Hub. Name it, type a Category (free text, e.g. Lending), write a one-line summary.
Click Publish. The receipt shows what shipped — asset count, bytes, content hash.
Switch to Project B (or Install as new to create one), open Hubs ▸ Solutions, find your Solution by name, and click Install here (or Install as new). It appears straight away: Solutions use their own signed-package flow, not the status above.

Structure travelled; data didn’t — and you’ve now seen both publish paths end to end: one that waits for an administrator, and one that ships as a signed package.

Where to go next

Package & ship a solution — the full publish-and-install walkthrough on a real solution.
A3 · Your first agent — build the agent you’ll publish.
D1 · Collections & schema — the data dependencies you point a package at.
R0 · Glossary — Solution, Hub, Import definitions.