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

Every published item carries a status. As a builder, what you mainly care about is whether an item is available to import; the other statuses are the moderation lifecycle behind it.

Status	Means	Who sees it
Active	Pending review — published but not yet approved. (The label says “Active”; read it as “pending”.)	Admins, in moderation.
Approved	Cleared for use — this is the catalog everyone imports from.	Everyone.
Rejected	Turned down in review.	Admins.
Inhouse	Curated / featured, with suggested prompts attached.	Everyone (merged into the import catalog).

Tip. As a consumer the rail only ever shows you Approved items (with Inhouse merged in). The [All] [Approved] [Active] [Rejected] [Inhouse] filter chips and the status pills belong to the admin view — if you don’t see them, that’s expected.

Role-gated. The moderation buttons (Approve / Reject / Inhouse / Remove, plus Edit and Delete) only appear on the admin view. As an ordinary builder you publish and import; an admin approves.

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.

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 + Inhouse set.
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, then install it into a different project.

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. (If an admin approval workflow is in place, your item starts as Active / pending until an admin approves it.)

Part B — install (in Project B):

Switch to a different project, open the Hubs chip, then Hubs ▸ Agents.
Find your agent (it must be Approved to appear), select it, read the description.
Click Import. When the configuration dialog opens, map each dependency to a local object — pick this project’s model, and its view/datasheet/collection as prompted.
Confirm. Then open Studio ▸ Agents ▸ Agents in Project B — your imported agent is there as a plain project agent. Open it; everything resolved to this project’s objects.

You just moved a solution between projects without copying a single document. Structure travelled; data didn’t.

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.