Skip to main content

Agent Suites

Agent Suites is the packaging and distribution surface within Beak AI Studio. It sits under the Studio · Build eyebrow and lets builders compose a group of agents — together with every skill, datasource, and MCP server those agents depend on — into a single versioned artifact called a suite. Once published, a suite is pushed to Hub where tenant administrators can discover, preview, and install it into their workspace.

The page description reads: "Package agents, skills, datasources, and MCP servers into versioned, publishable bundles."

Suites List​

The Suites List is the catalog view at /agent-suites. It shows every draft suite in the workspace as rows in a data table. A New Suite button in the top-right corner of the page header opens the creation flow.

A search box above the table filters visible rows in real time against a suite's name, slug, and description.

Table Columns​

  • Name — Display name of the suite, with the description shown as secondary text beneath it.
  • Slug — URL-safe identifier (customer-support-pack). Lowercase letters, digits, hyphens, and underscores; must start with a letter or digit.
  • Agents — Count of agents currently assigned to the draft.
  • Latest — The highest published semantic version (v1.2.0), or a Draft badge when no version has been published yet.
  • Installs — Number of times the suite has been installed across tenants, sourced from Hub.
  • Updated — Relative timestamp of the last draft save.

Each row is clickable and opens the Suite Editor for that draft. A delete icon at the end of each row removes the draft. Deleting a draft does not affect already-published versions on Hub.

Creating a Suite​

The New Suite page at /agent-suites/new collects the minimum information needed to register a draft.

New Suite Form Fields​

  • Slug — Machine-readable identifier used in the Hub URL and in manifest references. Must match the pattern [a-z0-9][a-z0-9_-]*. This value cannot be changed after creation.
  • Name — Human-readable display name shown in Hub and in the Studio list.
  • Description — Optional free-text summary of what the suite contains, shown to consumers on Hub.

Cancel returns to the Suites List without saving. Create Suite saves the draft and navigates directly to the Suite Editor.

Suite Editor​

The Suite Editor at /agent-suites/:id is the main authoring surface. The page header shows the suite name and slug. Four toolbar buttons control the editing session:

  • Back — Returns to the Suites List.
  • Preview Manifest — Generates and displays a read-only manifest preview in a side drawer without publishing.
  • Save — Persists unsaved changes to the draft. Active only when there are unsaved changes.
  • Publish — Opens the Publish Suite dialog to release a new version to Hub.

Note: Publish requires admin rights on the BeakAI tenant. The button is visible to all editors but disabled for non-admins. Save must be clicked before Publish — the Publish button remains inactive while there are unsaved changes.

Identity Panel​

The Identity panel on the left column holds the editable name and description for the suite draft. Changes here are reflected in the Hub listing after the next publish.

  • Name — Display name of the suite.
  • Description — Optional summary displayed on the Hub marketplace page.

Agents in This Suite​

The Agents panel shows cards for every agent currently assigned to the draft. The panel header reports the number of agents selected. Add Agents opens a searchable multi-select dialog listing all active agents in the workspace.

Each agent card displays the agent icon, name, version, and type (assistant or orchestrator). Two hover actions appear on each card:

  • Open in Studio — navigates to the live agent editor at /agents/:id.
  • Remove from suite — removes the agent from the draft selection.

Note: The suite snapshots each agent at publish time. Changes made to an agent in Studio after a version is published do not affect that published version.

Parameters​

The Parameters panel defines the customer-overridable fields that appear in the install wizard when a consumer installs the suite from Hub. Parameters that are not listed are locked to the values embedded in the manifest.

Two buttons populate the list:

  • Suggest from manifest — Analyses the current manifest and proposes a starter list of parameters derived from the agents' skills, datasources, and configuration fields. A confirmation overlay lists the suggestions; builders select which ones to merge into the schema.
  • Add parameter — Creates a blank parameter entry for manual definition.

Each parameter row shows the type badge, label, and ID. Expanding a row exposes the full parameter fields:

  • Type — Data type that determines how the install wizard renders the field and how the Runtime stores the value. Options: String, URL, Secret, Model name, Virtual key ref, Datasource config, Webhook secret, Prompt variable.
  • ID — Dot-notation key used by the substitutor to locate the parameter at install time (e.g. skill.itsm.url).
  • Label — Human-readable field name shown in the install wizard.
  • Required — Toggle. When on, the consumer must supply a value; when off, the Default value is used as a fallback.
  • Description — Hint text shown beneath the field in the install wizard.
  • Default — Pre-filled value in the wizard (not available for Secret and Webhook secret types).
  • Placeholder token — (Prompt variable type only) The {{slug}} token that the substitutor replaces in bound text fields.
  • Connector type — (Datasource config type only) Connector identifier that the customer's connection config must conform to (e.g. postgres, sharepoint, web_crawl).
  • Bindings — One JSONPath expression per line. Each path tells the substitutor exactly where in the manifest the customer's value should land. Multiple bindings let a single parameter populate several fields simultaneously.

Visibility Panel​

The Visibility panel on the right column controls which tenants can discover and install the suite from Hub.

  • Visibility — Dropdown with two options: Public (all tenants) makes the suite visible to every Hub tenant; Tenant allowlist restricts visibility to a specific set of tenants.
  • Visible tenant IDs — Shown only when Tenant allowlist is selected. Accepts a comma-separated list of numeric tenant IDs.
  • Suite preview — Toggle. When enabled, consumers on Hub can preview the suite manifest before committing to an install.

Published Versions Panel​

The Published Versions panel lists every version that has been released to Hub, newest first. Each entry shows the semantic version number, the publication timestamp, and the changelog text entered at publish time. Clicking a version row opens the Version View page for that release.

Manifest Preview Drawer​

Clicking Preview Manifest in the editor toolbar opens a side drawer that renders a read-only snapshot of the manifest that would be sent to Hub if the suite were published now. The preview is generated from the last saved draft state and does not create a new version.

If the manifest has any configuration warnings — such as agents with missing skills or datasources — the drawer displays a warnings list before the manifest content.

The manifest body is structured into four sections mirroring what Hub consumers see:

  • Agents — Cards for each agent in the manifest, showing name, type, model, skill count, datasource count, and MCP server count.
  • Skills — Cards for each skill resolved from the agents, showing display name, tool ID, type badge, and category.
  • Datasources — Cards for each datasource, showing name and datasource type.
  • MCP Servers — Cards for each MCP server, showing name, transport protocol, and the list of available tool names.

Publish Suite Dialog​

Publish opens a dialog that commits the current draft as a new immutable version on Hub. The dialog shows a closure summary of what the publish will include — counts of agents, skills, datasources, and MCP servers drawn from the most recent manifest preview. Any warnings from the manifest are also displayed.

Publish Fields​

  • Version (semver) — Semantic version string in major.minor.patch format (e.g. 1.0.0, 2.1.3-beta.1). The dialog pre-fills a suggested patch bump from the latest published version, or 1.0.0 for a first publish. Each version must be unique; re-using an existing version is blocked.
  • Changelog — Optional release notes describing what changed in this version. The text is stored with the version and displayed in the Published Versions panel and in Hub.

Cancel closes the dialog without publishing. Publish submits the request. Once published, a version cannot be modified or deleted.

Version View​

The Version View page at /agent-suites/:id/versions/:ver shows the manifest content for a specific published version. The page header displays the suite name and version number alongside the publication timestamp. If a changelog was entered at publish time, it appears in a card above the manifest.

The manifest body renders using the same four-section layout as the Manifest Preview Drawer — Agents, Skills, Datasources, and MCP Servers — providing a read-only record of what was shipped in that release.

Best Practices​

  • Assign all agents to the draft before clicking Suggest from manifest — the suggestion engine analyses the full agent closure and will miss skills or datasources belonging to agents that have not been added yet.
  • Use Save frequently during editing; Publish is disabled while unsaved changes are present, so a save is always required before releasing a version.
  • Set Suite preview on during the review cycle so stakeholders on Hub can inspect the manifest before it is installed in a production workspace.
  • Use the Tenant allowlist visibility mode when piloting a new suite with a specific customer before making it available to all tenants.
  • Write a meaningful changelog for every publish — it is the only record consumers and support teams have of what changed between versions.
  • Preview the manifest before each publish to review the closure counts and catch any configuration warnings early.
  • Core Features — Overview of the Beak AI Studio workspace and all major surfaces.
  • Agent Lifecycle Management — Drafting, versioning, publishing, and deactivating individual agents.
  • Creating Agents — Step-by-step walkthrough for creating a new agent in Studio.
  • Skill Lifecycle Management — Creating, versioning, and managing skills that agents use inside suites.
  • Prompt Management — Building and versioning the prompt templates referenced by agents in a suite.
  • Playground — Interactive test bench for validating agents before including them in a suite.