Skip to content

Publish

Fabric Publish defines how a validated agent fabric is deployed onto the Unitt platform, offered through the Unitt Market, or kept for private reuse; and how that same fabric is parameterized so it can be redeployed any number of times against different client setup points without rewriting the runtime. Where Test commits the release gate, the Publish layer commits the deployment, parameterization, versioning, telemetry, and licensing model so that a single validated fabric becomes a reusable enterprise runtime system.

Fabric Publish is informed by the active agent-deployment and marketplace research lineage, including the Anthropic Agent Skills packaging standard, the MCP Registry and MCPB bundle format, the Google A2A protocol (now governed by the Linux Foundation's Agentic AI Foundation), the AWS Bedrock AgentCore managed runtime and Marketplace, Salesforce AgentExchange, Google Vertex AI / Gemini Enterprise Agent Garden, the OpenAI GPT Store and AgentKit, ServiceNow AI Agent Store, the Microsoft Agent Governance Toolkit, OpenTelemetry GenAI semantic conventions, and GitOps-for-agents patterns popularized by OpenChoreo and the agentic-community MCP gateway. Selection criteria for deployment targets are documented in Reference › Research › Fabric Publish.

Publish Pipeline

Publish moves a Test-gated fabric through five stages; package, validate, list, deploy, operate; each with explicit artifacts, signatures, and rollback paths. Every stage emits structured events to the audit trail; no stage is bypassable.

flowchart LR
    DEV[Validated Fabric] --> PKG[Package]
    PKG --> VAL[Publish-Time Validation]
    VAL --> LST[List or Register]
    LST --> DEP[Deploy]
    DEP --> OPS[Operate]
    OPS -. usage signals .-> PKG

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class DEV,PKG,VAL,LST,DEP,OPS stage

Packaging

A Fabric is packaged as a versioned bundle that contains everything required to redeploy the runtime end-to-end. The bundle is self-describing, schema-validated, and cryptographically signed.

Component Contents
fabric.yaml Topology, agents, model pins, budgets, policies, gates, observability.
agents/*/ Per-agent Unitt definitions from Assembly + Emergence.
tools/ Tool declarations and MCP server references.
data/ Inbound binding declarations, RAG corpus references, schema definitions.
prompts/ Templated prompts with declared parameter slots.
skills/ Anthropic-style SKILL.md files and any platform-specific procedural memory.
eval/ Validation suite, regression dataset references, cost-per-success ceiling.
parameters.json Declared tunable knobs (variables, tool allowlists, model tier, BYOK slots).
agent-card.json Signed A2A agent card with domain verification.
sbom.json Software bill of materials for every dependency.
governance.json Policy bundle, OWASP Agentic Top 10 coverage map, audit signing key.
manifest.json Top-level semver, model pins, contract hash, build provenance.

The platform supports three industry packaging shapes simultaneously so a fabric can be deployed across marketplaces without re-authoring: the Anthropic Agent Skills folder layout (adopted across VS Code, GitHub, Cursor, Goose, Amp, OpenCode), the MCPB self-contained bundle format, and the platform-native unitt.yaml manifest. The mpak / MTF supply-chain trust framework provides L1-L4 trust scoring on top of MCPB for enterprise distribution.

Parameterization For Reuse

The single most important Publish-time decision is how the fabric is parameterized so it can be redeployed against many different client setup points. Reusable fabrics expose tunable knobs as declarative parameters, not buried prompt strings.

flowchart LR
    PKG[Packaged Fabric] --> PARAM[parameters.json]
    PARAM --> PV[Prompt Variables]
    PARAM --> TC[Tool Config]
    PARAM --> MT[Model Tier]
    PARAM --> FF[Feature Flags]
    PARAM --> MN[Manifest Workspace]
    PARAM --> BYK[BYOK Slots]

    PV --> CL[Client Deployment]
    TC --> CL
    MT --> CL
    FF --> CL
    MN --> CL
    BYK --> CL

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class PKG,PARAM,PV,TC,MT,FF,MN,BYK,CL stage
Knob Examples
Prompt variables Brand name, tone, locale, target audience, hard rules.
Tool config Per-client allowlist, connector endpoints, vault references.
Model tier tier:premium, tier:standard, tier:fast; cost / latency trade.
Feature flags Optional sub-flows (escalation channel, approval policy, fallback model).
Manifest workspace Per-client storage backend (S3, GCS, Azure, R2).
BYOK slots Client-provided model keys, connector tokens, signing keys.

Every redeployment commits a client.yaml overlay that supplies values for the declared knobs. The fabric runtime composes client.yaml over parameters.json defaults to produce the runnable configuration. A single validated fabric supports an unbounded number of client.yaml overlays.

Publish-Time Validation

Publish-time validation is an explicit governance gate that runs after Test signs off the candidate fabric. It enforces controls that are about the artifact, not the runtime behavior: provenance, supply chain, secrets hygiene, governance coverage, and regulatory obligations.

Check Tool / Standard
OWASP Agentic Top 10 coverage Microsoft Agent Governance Toolkit, platform-native scanner.
Cost-per-success eval threshold Inherited from Test.
Sandbox attestation Reproducible build with isolated network and signed runtime.
Signed agent card A2A signed card with cryptographic domain verification.
SBOM CycloneDX or SPDX bill of materials.
Secret scan No hard-coded credentials, tokens, or BYOK material in the bundle.
License scan Every dependency license is compatible with the declared license model.
Regulatory obligations EU AI Act high-risk obligations (Aug 2026), Colorado AI Act (Jun 2026) when applicable.

A bundle that fails any check is blocked from listing or deployment. Failed checks produce a structured PublishBlocker event with remediation guidance.

Listing And Distribution

The platform supports four distribution targets for a packaged fabric. The target is selected per fabric; a single fabric may be listed across multiple targets simultaneously.

Unitt Market

The Unitt Market is the platform-native marketplace where validated fabrics are listed for purchase, license, or hosted use. Listings include the operational metrics surfaced from Test; objective success rate, execution consistency, infrastructure requirements, estimated token cost; plus the licensing model. Discovery is built around verified outcomes rather than star ratings.

Private Reuse

Fabrics may be kept fully private and deployed only inside the developer's own environment. Private fabrics still emit telemetry, still version, still validate at publish-time, but never appear in the Unitt Market or any external marketplace. Private fabrics integrate with internal MCP Gateway and Registry deployments for tool discovery, and with GitOps reconciliation for cluster-resident fabrics.

External Marketplaces

Where a client environment requires cross-platform listing, the platform can re-package and submit to external marketplaces; Salesforce AgentExchange, AWS Bedrock AgentCore + Marketplace, Google Vertex AI Agent Garden, OpenAI GPT Store, ServiceNow AI Agent Store, Microsoft Copilot Agent Store, Hugging Face Spaces; via the corresponding packaging shape. The platform maintains adapters so the same fabric maps cleanly to each marketplace's distribution requirements.

Hosted Runtime

For developers without their own infrastructure, the platform offers a hosted runtime where the fabric runs as a managed service. Hosted runtime includes platform-managed observability, audit, secrets vault, scaling, and incident response. Hosted billing is metered per successful run, per token, or per seat per the configured licensing model.

flowchart LR
    BUN[Signed Bundle] --> CHO{Distribution Target}
    CHO --> UM[Unitt Market]
    CHO --> PR[Private Registry]
    CHO --> EX[External Marketplaces]
    CHO --> HR[Hosted Runtime]

    UM -. metered .-> OPS[Operate]
    PR --> OPS
    EX --> OPS
    HR --> OPS

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class BUN,CHO,UM,PR,EX,HR,OPS stage

Deployment

The deployment surface supports four runtime targets so the same packaged fabric can run anywhere a client requires.

Target When To Use
Hosted managed Zero-infra clients; rapid time-to-value; platform SLAs.
Container / Kubernetes Long-running multi-agent fabrics; tenant isolation; GitOps reconciliation.
Serverless Sporadic, stateless tools or sub-agents; burst workloads.
Edge Latency-sensitive client-side agents; on-device privacy.

Container deployments use a namespace-per-tenant pattern with RBAC, NetworkPolicies, and ResourceQuotas, with Vault Agent injection annotations for tenant-scoped secrets. RAG retrieval uses physical vector-store namespace isolation, not metadata filtering, to architecturally prevent cross-tenant retrieval; the OWASP LLM08:2025 requirement.

Multi-Tenant Reuse

The reusability promise is operationalized through three patterns that compose:

flowchart LR
    F[Validated Fabric] --> CY1[client-a.yaml]
    F --> CY2[client-b.yaml]
    F --> CY3[client-c.yaml]
    CY1 --> NS1[Namespace A]
    CY2 --> NS2[Namespace B]
    CY3 --> NS3[Namespace C]
    NS1 --> VA[Vault A]
    NS2 --> VB[Vault B]
    NS3 --> VC[Vault C]
    NS1 --> VS1[Vector NS A]
    NS2 --> VS2[Vector NS B]
    NS3 --> VS3[Vector NS C]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class F,CY1,CY2,CY3,NS1,NS2,NS3,VA,VB,VC,VS1,VS2,VS3 stage
  • Parameter overlay; client.yaml supplies values for declared knobs without touching the fabric bundle.
  • Tenant-scoped vaults; credentials, BYOK material, and signing keys never cross tenant boundaries.
  • Physical namespace isolation; per-tenant namespaces in compute, storage, and vector stores.

Versioning And Rollback

Versioning applies semver to behavior, not just code:

Bump Meaning
Major Breaking prompt or tool contract change.
Minor Additive capability with backward-compatible defaults.
Patch Wording or eval-neutral fix.

Model versions are pinned explicitly (claude-opus-4-7, gpt-5.1-2026-04-01); tool versions are pinned with contract tests; the full execution context; prompt, model, parameters, retrieval configuration; is versioned as a single unit. Tool-version churn causes roughly 60% of production agent failures in published research, so contract tests are mandatory at publish time.

Rollouts use canary (5-10% traffic) and blue / green behind feature flags; rollback is instant and atomic against the full execution context. Feature-flag rollouts and canary gates are wired automatically from Setup and Test defaults.

Licensing Models

The Unitt Market supports the licensing shapes that the agent-marketplace ecosystem has converged on:

Model Description
Per-seat subscription Flat fee per active user.
Per-run / per-action Metered per successful task.
Per-token passthrough Direct provider billing forwarded to the licensee.
Revenue share Platform takes a percentage of license fees.
Flat transaction fee Platform takes a fixed percentage per transaction.
BYOK Licensee provides their own model and connector credentials.
Outcome / value pricing Pricing tied to a contracted operational outcome.
Fully transferable license One-time payment for unrestricted private operation.

Licensing is declared at publish time and surfaces directly in the Unitt Market listing. Multiple licensing tiers per fabric are permitted.

Telemetry And Continuous Improvement

Every deployed fabric emits OpenTelemetry GenAI traces, structured event logs, audit-trail entries, and aggregated metrics. Telemetry feeds three improvement loops:

flowchart LR
    OPS[Operating Fabric] --> OT[OTel Spans]
    OPS --> EV[Audit Events]
    OPS --> MR[Marketplace Ratings]

    OT --> EVAL[Eval Datasets]
    EV --> EVAL
    OT --> AB[Champion / Challenger A/B]
    MR --> RNK[Marketplace Ranking]

    EVAL --> CAND[Next Candidate Fabric]
    AB --> CAND
    RNK --> CAND
    CAND --> PUB[New Publish]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class OPS,OT,EV,MR,EVAL,AB,RNK,CAND,PUB stage
  • Eval datasets; production traces (PII-scrubbed, consented) flow back into the regression suite in Test.
  • Champion / challenger A/B; production traffic routes a slice to a candidate fabric behind version routing.
  • Marketplace ranking; usage data, install retention, and uninstall reasons feed the Unitt Market listing rank.

Redeployment Without Re-Authoring

The reusability promise is operational: a validated fabric can be redeployed any number of times against new client setup points by composing a new client.yaml overlay. The fabric bundle is immutable; only the overlay changes. Redeployments inherit the parent fabric's audit trail, governance scope, and validation history, while their telemetry is scoped to the new client namespace.

flowchart LR
    UB[Unchanged Bundle vX.Y.Z] --> OV1[Overlay: Client A]
    UB --> OV2[Overlay: Client B]
    UB --> OV3[Overlay: Client N]
    OV1 --> DA[Deploy A]
    OV2 --> DB[Deploy B]
    OV3 --> DN[Deploy N]

    DA -. telemetry .-> CA[Client A Audit]
    DB -. telemetry .-> CB[Client B Audit]
    DN -. telemetry .-> CN[Client N Audit]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class UB,OV1,OV2,OV3,DA,DB,DN,CA,CB,CN stage

Governance Of Publish

Publish is the boundary between platform-internal validation and external operation. Every Publish decision is recorded.

Publish Governance Requirements

  • Every bundle is signed and immutable in the audit trail.
  • Every parameter is declared; no implicit knobs in prompts or code.
  • Every redeployment composes an explicit client.yaml overlay.
  • OWASP Agentic Top 10 coverage and cost-per-success thresholds are enforced.
  • Per-tenant vaults, namespaces, and vector-store isolation are non-negotiable for multi-tenant deployments.
  • Versioning, rollback, and canary are mandatory for any production-tier listing.
  • Telemetry conforms to OpenTelemetry GenAI semantic conventions.

Cross-References